diff --git a/wiki/concepts/AIFinOps.md b/wiki/concepts/AIFinOps.md new file mode 100644 index 00000000..103fe4ca --- /dev/null +++ b/wiki/concepts/AIFinOps.md @@ -0,0 +1,32 @@ +--- +title: "AIFinOps" +type: concept +tags: ["finops", "cost-optimization", "cloud-economics"] +sources: ["engineering-autonomous-optimization-architect"] +last_updated: 2026-04-26 +--- + +## Aliases +- AI FinOps +- AI Financial Operations +- LLM Cost Management + +## Definition +AI FinOps（Financial Operations）是 [[AutonomousOptimizationArchitect]] 的成本管理框架——持续追踪每个 LLM Provider 的 Token 消耗、成本、延迟和输出质量，建立历史性能数据库，为 [[SemanticRouting]] 提供成本感知的决策依据。目标是实现 AI 运营成本的可预测性和可控性。 + +## Mechanism +1. **遥测数据收集**：每次 API 调用记录 Token 数量、响应时间、错误率、成本 +2. **成本建模**：按 Provider、模型、任务类型建立成本分解模型 +3. **异常检测**：检测异常流量模式（如 500% 流量突增，可能为 bot 攻击） +4. **预算告警**：当成本接近阈值时触发告警 +5. **优化建议**：基于历史数据生成成本优化建议（如切换到 Gemini Flash） + +## Key Properties +- **成本透明**：每百万 Token 成本精确追踪 +- **可预测性**：基于历史趋势预测未来成本 +- **与治理对齐**：为 [[CircuitBreaker]] 提供成本异常检测数据 + +## Connections +- [[AutonomousOptimizationArchitect]] — AIFinOps 是成本管理的核心框架 +- [[SemanticRouting]] — 成本数据是路由决策的关键输入 +- [[CircuitBreaker]] — 异常成本流量触发熔断保护 diff --git a/wiki/concepts/CircuitBreaker.md b/wiki/concepts/CircuitBreaker.md new file mode 100644 index 00000000..caee3ca0 --- /dev/null +++ b/wiki/concepts/CircuitBreaker.md @@ -0,0 +1,31 @@ +--- +title: "CircuitBreaker" +type: concept +tags: ["reliability", "fault-tolerance", "llm-ops"] +sources: ["engineering-autonomous-optimization-architect"] +last_updated: 2026-04-26 +--- + +## Aliases +- Circuit Breaker +- 熔断器 +- Circuit Breaker Pattern + +## Definition +熔断器模式是 [[AutonomousOptimizationArchitect]] 的核心安全机制——当某个 LLM Provider 的失败频率超过阈值（如 HTTP 402/429 错误、响应超时）时，自动切断该 Provider 并切换至廉价兜底方案，同时触发告警通知人工介入。 + +## Mechanism +1. **监测**：追踪每个 Provider 的失败计数和失败率 +2. **触发**：当失败次数超过 `maxRetries` 阈值，或检测到 HTTP 402/429 错误流时，立即 trip 熔断器 +3. **降级**：所有请求切换到预配置的廉价兜底 Provider（如 Gemini Flash） +4. **恢复**：人工确认问题解决后手动重置，或经过冷却期后自动尝试恢复 + +## Key Properties +- **防止成本失控**：阻止 Token 消耗攻击（如恶意 bot 短时间内大量请求） +- **防止无限重试**：每个 Provider 配置最大重试次数 `maxRetries` +- **分级降级**：逐级切换到更便宜的备用 Provider，直到找到可用路径 + +## Connections +- [[AutonomousOptimizationArchitect]] — 使用 CircuitBreaker 作为金融护栏的核心实现 +- [[LLMasJudge]] — 评估 Provider 降级后输出质量是否可接受 +- [[ShadowTraffic]] — 熔断触发后可异步在影子流量中测试备用 Provider diff --git a/wiki/concepts/DarkLaunching.md b/wiki/concepts/DarkLaunching.md new file mode 100644 index 00000000..a4c1d797 --- /dev/null +++ b/wiki/concepts/DarkLaunching.md @@ -0,0 +1,31 @@ +--- +title: "DarkLaunching" +type: concept +tags: ["deployment", "release-management", "feature-rollout"] +sources: ["engineering-autonomous-optimization-architect"] +last_updated: 2026-04-26 +--- + +## Aliases +- Dark Launch +- 暗启动 +- 灰度发布 +- Feature Flag Deployment + +## Definition +暗启动是 [[AutonomousOptimizationArchitect]] 的模型引入策略——在不完全暴露给用户的前提下，将新模型部署到生产环境，通过 [[ShadowTraffic]] 验证其性能。分为三个阶段：影子测试（不返回用户）→ 灰度流量（5% 用户）→ 全量切换。 + +## Mechanism +1. **Phase 1 - Shadow Deployment**：新模型接收影子流量，完全不影响用户 +2. **Phase 2 - Canary**：5% 真实流量切换到新模型，监控错误率和用户满意度 +3. **Phase 3 - Full Rollout**：新模型通过所有检查后，全量替换旧模型 + +## Key Properties +- **风险可控**：任何阶段发现问题均可立即回滚 +- **数据驱动**：每个阶段都有明确的量化指标门槛 +- **与 CI/CD 集成**：暗启动可作为自动化发布流水线的组成部分 + +## Connections +- [[AutonomousOptimizationArchitect]] — 使用暗启动作为新模型引入框架 +- [[ShadowTraffic]] — 暗启动 Phase 1 的核心实现方式 +- [[CircuitBreaker]] — 提供暗启动失败时的自动保护机制 diff --git a/wiki/concepts/LLMasJudge.md b/wiki/concepts/LLMasJudge.md new file mode 100644 index 00000000..fc9cb217 --- /dev/null +++ b/wiki/concepts/LLMasJudge.md @@ -0,0 +1,31 @@ +--- +title: "LLMasJudge" +type: concept +tags: ["evaluation", "llm-evaluation", "quality-assurance"] +sources: ["engineering-autonomous-optimization-architect"] +last_updated: 2026-04-26 +--- + +## Aliases +- LLM as a Judge +- LLM-as-Judge +- LLM-as-a-Judge Grading + +## Definition +LLM-as-a-Judge 是 [[AutonomousOptimizationArchitect]] 的评分机制——使用一个独立的 LLM（如 Claude Opus）作为"裁判"，对实验模型和生产模型的输出进行客观评分，避免人工评审的主观偏差。评分维度包括：JSON 格式正确性（5分）、延迟（3分）、幻觉检测（-10分）等。 + +## Mechanism +1. **评分标准预先建立**：在 [[ShadowTraffic]] 测试前，[[AutonomousOptimizationArchitect]] 明确建立数学评分标准 +2. **异步评估**：实验模型和生产模型同时处理任务，裁判 LLM 盲评两者输出 +3. **统计分析**：累积足够样本后进行统计显著性检验 +4. **自主决策**：实验模型显著优于基准时，更新路由权重 + +## Key Properties +- **客观性**：消除人工评分的主观偏差 +- **可扩展**：可同时评估多个 Provider 的输出 +- **数据驱动**：评分结果直接驱动 [[SemanticRouting]] 决策 + +## Connections +- [[AutonomousOptimizationArchitect]] — LLM-as-Judge 是核心评估工具 +- [[ShadowTraffic]] — 提供实验与基准并行执行的流量环境 +- [[SemanticRouting]] — 评分结果更新路由权重 diff --git a/wiki/concepts/SemanticRouting.md b/wiki/concepts/SemanticRouting.md new file mode 100644 index 00000000..f177a79f --- /dev/null +++ b/wiki/concepts/SemanticRouting.md @@ -0,0 +1,32 @@ +--- +title: "SemanticRouting" +type: concept +tags: ["routing", "llm-ops", "intelligent-routing"] +sources: ["engineering-autonomous-optimization-architect"] +last_updated: 2026-04-26 +--- + +## Aliases +- Semantic Routing +- 语义路由 +- Intent Routing +- Task-Aware Routing + +## Definition +语义路由是 [[AutonomousOptimizationArchitect]] 的决策核心——根据任务类型、历史性能评分和当前 Provider 状态，动态选择最优的 LLM Provider。Provider 按"优化分数"（Speed + Cost + Accuracy 综合排名）排序，优先尝试排名最高的可用 Provider。 + +## Mechanism +1. **任务分析**：理解用户请求的类型和复杂度（如代码生成 vs. 闲聊） +2. **Provider 排名**：按历史优化分数对所有 Provider 排序 +3. **动态选择**：从最高排名 Provider 开始尝试，直到找到可用且在成本限制内的 Provider +4. **持续学习**：[[LLMasJudge]] 评分结果更新各 Provider 在特定任务类型上的排名 + +## Key Properties +- **成本感知**：始终追踪每百万 Token 成本，优先使用低成本模型 +- **性能自适应**：根据 [[ShadowTraffic]] 数据动态调整排名 +- **故障感知**：熔断器切断的 Provider 自动跳过 + +## Connections +- [[AutonomousOptimizationArchitect]] — 语义路由是核心路由决策逻辑 +- [[CircuitBreaker]] — 提供故障感知的 Provider 过滤 +- [[LLMasJudge]] — 提供更新路由权重的数据 diff --git a/wiki/concepts/ShadowTraffic.md b/wiki/concepts/ShadowTraffic.md new file mode 100644 index 00000000..b25eaea5 --- /dev/null +++ b/wiki/concepts/ShadowTraffic.md @@ -0,0 +1,32 @@ +--- +title: "ShadowTraffic" +type: concept +tags: ["testing", "a-b-testing", "dark-launch"] +sources: ["engineering-autonomous-optimization-architect"] +last_updated: 2026-04-26 +--- + +## Aliases +- Shadow Traffic +- 影子流量 +- Shadow Testing +- 暗测试 + +## Definition +影子流量是 [[AutonomousOptimizationArchitect]] 的核心测试机制——将一小部分真实用户请求（通常 5%）异步复制到实验模型，与生产模型并行执行，但不返回给用户。实验结果通过 [[LLMasJudge]] 自动评分，用于决定是否将实验模型提升为生产模型。 + +## Mechanism +1. **流量复制**：用户请求同时发送至生产模型和实验模型 +2. **异步评估**：实验模型结果不阻塞用户响应，通过 [[LLMasJudge]] 异步评分 +3. **统计分析**：累积 N 次（如 1000 次）执行后评估性能差距 +4. **自主升级**：实验模型统计显著优于基准时，自动更新路由权重 + +## Key Properties +- **零用户影响**：实验在后台进行，用户永远获得生产模型响应 +- **真实数据**：使用真实用户请求，而非人工构造的测试用例 +- **持续运行**：可 24/7 不间断运行，持续监控新模型发布 + +## Connections +- [[AutonomousOptimizationArchitect]] — 影子流量是核心测试基础设施 +- [[LLMasJudge]] — 对影子流量结果进行自动评分 +- [[DarkLaunching]] — 影子流量是暗启动的测试阶段 diff --git a/wiki/entities/Anthropic.md b/wiki/entities/Anthropic.md index 967c79bf..a221b978 100644 --- a/wiki/entities/Anthropic.md +++ b/wiki/entities/Anthropic.md @@ -1,30 +1,28 @@ ---- -title: "Anthropic" -type: entity -tags: [AI, Claude, Anthropic] -sources: [google-5个agent-skill设计模式-2026-03-19] -last_updated: 2026-03-19 ---- - -## Overview -Anthropic 是一家 AI 安全公司，开发了 Claude 系列大语言模型和 Claude Code CLI Agent。其在 Skill 设计方面的实践经验（9 类分类、3 条铁律）被 Google ADK 指南引用。 - -## Key Contributions -- **Claude Code**：Anthropic 的 CLI Agent，支持 SKILL.md 格式标准化 -- **9 类 Skill 分类**：从参考手册到故障排查，每类有明确场景 -- **3 条铁律**： - 1. 只写 Agent 不知道的东西 - 2. 重点写踩坑清单 - 3. 给工具不给指令 - -## Key Insight -> "最好的 Skill 不是写得好的提示词，而是一个「工具箱」。" — Anthropic - -## Related Entities -- [[GoogleCloud]]：引用了 Anthropic 的 Skill 实践经验 -- [[ClaudeCode]]：Anthropic 开发的 CLI Agent -- [[ADK]]：Google Cloud 的 Agent 开发工具包 - -## Connections -- [[AnthropicSkill实践]] ← authored_by ← [[Anthropic]] -- [[Google5个AgentSkill设计模式]] ← extends ← [[AnthropicSkill实践]] +--- +title: "Anthropic" +type: entity +tags: ["llm-provider", "anthropic"] +sources: ["engineering-autonomous-optimization-architect"] +last_updated: 2026-04-26 +--- + +## Aliases +- Anthropic +- Anthropic PBC + +## Definition +Anthropic 是主要的 LLM Provider，提供 Claude 系列模型（Claude Opus、Claude Sonnet、Claude Haiku 等）。在 [[AutonomousOptimizationArchitect]] 系统中作为高精度基准模型，其输出常被用作 [[LLMasJudge]] 评估其他模型时的参照标准。 + +## Role in LLM Routing +- Claude Opus 常作为高精度基准——如果其他模型要替代 Claude，必须达到其 98%+ 精度 +- Claude Sonnet/Haiku 提供性价比选项，供 [[AutonomousOptimizationArchitect]] 按任务难度分配 +- Anthropic API 不可用时触发 [[CircuitBreaker]] 切换至 [[OpenAI]] 或 [[GoogleGemini]] + +## Key Properties +- **Token 成本**：$3-15 / 1M tokens +- **延迟**：低至中等 +- **常见用途**：复杂推理、长文本分析、安全敏感任务 + +## Connections +- [[OpenAI]] — 同为 LLM Provider，共同参与 [[SemanticRouting]] +- [[GoogleGemini]] — 在成本优化场景中与 Gemini Flash 形成对比 diff --git a/wiki/entities/GoogleGemini.md b/wiki/entities/GoogleGemini.md new file mode 100644 index 00000000..eb8f7771 --- /dev/null +++ b/wiki/entities/GoogleGemini.md @@ -0,0 +1,30 @@ +--- +title: "GoogleGemini" +type: entity +tags: ["llm-provider", "google", "gemini"] +sources: ["engineering-autonomous-optimization-architect"] +last_updated: 2026-04-26 +--- + +## Aliases +- Gemini +- Google Gemini +- Gemini Flash +- Gemini Pro + +## Definition +Google Gemini 是 Google 的 LLM 系列模型，涵盖从高性价比到高性能的多种版本。在 [[AutonomousOptimizationArchitect]] 系统中，Gemini Flash 因其极高的性价比（成本约为 Claude Opus 的 1/10）而被列为重要的路由目标。 + +## Role in LLM Routing +- **Gemini Flash**：低成本高速度模型，如果精度达到基准的 98% 且成本远低于竞品，[[AutonomousOptimizationArchitect]] 会将流量自动路由至 Gemini +- **Gemini Pro**：中端定位，提供能力与成本的平衡 +- 与 [[OpenAI]] 和 [[Anthropic]] 共同构成三足鼎立的 Provider 生态 + +## Key Properties +- **Token 成本**：$0.075-0.5 / 1M tokens（Gemini Flash 极低） +- **延迟**：低（Gemini Flash） +- **优势**：极高的性价比，特别适合大规模、低成本推理 + +## Connections +- [[OpenAI]] — 同为 LLM Provider +- [[Anthropic]] — 高精度基准 Provider diff --git a/wiki/entities/OpenAI.md b/wiki/entities/OpenAI.md index f68cebc9..b8b65740 100644 --- a/wiki/entities/OpenAI.md +++ b/wiki/entities/OpenAI.md @@ -1,32 +1,27 @@ ---- -title: "OpenAI" -type: entity -tags: [ai, company, llm] -last_updated: 2026-04-23 ---- - -# OpenAI - -## Type -Company - -## Aliases -- OpenAI LLC -- OpenAI LP（盈利主体） - -## Description -OpenAI 是美国人工智能研究公司，开发了 GPT 系列大语言模型、ChatGPT 产品、API 接口及 DALL·E 图像生成模型。 - -## Key Products -- **ChatGPT**：对话式 AI 助手，支持自定义指令（Custom Instructions）功能 -- **GPT-4 / GPT-4o / GPT-4.5**：最新大语言模型系列 -- **OpenAI API**：为开发者提供 LLM 调用接口 -- **DALL·E**：文本生成图像模型 -- **Whisper**：开源语音识别模型 -- **Sora**：视频生成模型 - -## Relevance to This Wiki -OpenAI 是本 Wiki 中多个 AI 工具和方案的底层技术提供商：[[ChatGPT]] 是用户自定义配置的主体；[[OpenClaw]] 可接入 OpenAI API；n8n、Claude 等工具均支持 OpenAI 模型集成。 - -## Sources -- [[openai-chatgpt-个性化定义]] +--- +title: "OpenAI" +type: entity +tags: ["llm-provider", "openai"] +sources: ["engineering-autonomous-optimization-architect"] +last_updated: 2026-04-26 +--- + +## Aliases +- OpenAI +- OpenAI Inc. + +## Definition +OpenAI 是主要的 LLM Provider 之一，提供 GPT 系列模型（GPT-4、GPT-4o、GPT-3.5 Turbo 等）。在 [[AutonomousOptimizationArchitect]] 系统中作为主要候选 Provider 之一参与性能排名和流量路由竞争。 + +## Role in LLM Routing +- 提供多种规模的模型供 [[AutonomousOptimizationArchitect]] 按任务类型分配 +- 模型历史性能（token 延迟、幻觉率、成本）被 [[AutonomousOptimizationArchitect]] 持续追踪并纳入 Provider 排名 + +## Key Properties +- **Token 成本**：$2.5-15 / 1M tokens（因模型而异） +- **延迟**：中等至高（取决于模型规模） +- **常见用途**：代码生成、复杂推理、长文档处理 + +## Connections +- [[Anthropic]] — 同为 LLM Provider，竞争关系，共同参与 [[SemanticRouting]] +- [[GoogleGemini]] — 同为 LLM Provider，在性价比上与 Gemini Flash 形成竞争 diff --git a/wiki/index.md b/wiki/index.md index 3f1450db..1343a14f 100644 --- a/wiki/index.md +++ b/wiki/index.md @@ -1,1505 +1,1670 @@ -# Wiki Index - -## Overview -- [Overview](overview.md) — living synthesis - -## Sources -- [2026-04-25] [Tool Evaluator Agent Personality](sources/testing-tool-evaluator.md) -- [2026-04-25] [Testing Evidence Collector Agent Personality](sources/testing-evidence-collector.md) -- [2026-04-25] [Test Results Analyzer Agent Personality](sources/testing-test-results-analyzer.md) -- [2026-04-25] [Performance Benchmarker Agent Personality](sources/testing-performance-benchmarker.md) -- [2026-04-25] [Testing Reality Checker](sources/testing-reality-checker.md) -- [2026-04-25] [Workflow Optimizer Agent Personality](sources/testing-workflow-optimizer.md) -- [2026-04-25] [API Tester Agent Personality](sources/testing-api-tester.md) -- [2026-04-25] [OpenCode Integration](sources/readme.md) -- [2026-04-25] [OpenCode Integration](sources/readme.md) -- [2026-04-25] [OpenCode Integration](sources/readme.md) -- [2026-04-25] [OpenCode Integration](sources/readme.md) -- [2026-04-25] [OpenCode Integration](sources/readme.md) -- [2026-04-25] [OpenCode Integration](sources/readme.md) -- [2026-04-25] [OpenCode Integration](sources/readme.md) -- [2026-04-25] [OpenCode Integration](sources/readme.md) -- [2026-04-25] [Backend Architect with Memory](sources/backend-architect-with-memory.md) -- [2026-04-25] [OpenCode Integration](sources/readme.md) -- [2026-04-25] [OpenCode Integration](sources/readme.md) -- [2026-04-25] [OpenCode Integration](sources/readme.md) -- [2026-04-25] [OpenCode Integration](sources/readme.md) -- [2026-04-25] [Historian Agent Personality](sources/academic-historian.md) -- [2026-04-25] [Academic Geographer](sources/academic-geographer.md) -- [2026-04-25] [Academic Narratologist](sources/academic-narratologist.md) -- [2026-04-25] [Academic Anthropologist](sources/academic-anthropologist.md) -- [2026-04-25] [Academic Psychologist](sources/academic-psychologist.md) -- [2026-04-25] [Behavioral Nudge Engine](sources/product-behavioral-nudge-engine.md) -- [2026-04-25] [Product Sprint Prioritizer Agent](sources/product-sprint-prioritizer.md) -- [2026-04-25] [Product Trend Researcher Agent](sources/product-trend-researcher.md) -- [2026-04-25] [Product Manager Agent](sources/product-manager.md) -- [2026-04-25] [Product Feedback Synthesizer Agent](sources/product-feedback-synthesizer.md) -- [2026-04-25] [Specialized Developer Advocate](sources/specialized-developer-advocate.md) -- [2026-04-25] [Automation Governance Architect](sources/automation-governance-architect.md) -- [2026-04-25] [Report Distribution Agent](sources/report-distribution-agent.md) -- [2026-04-25] [Data Consolidation Agent](sources/data-consolidation-agent.md) -- [2026-04-25] [Supply Chain Strategist Agent](sources/supply-chain-strategist.md) -- [2026-04-25] [ZK Steward Agent](sources/zk-steward.md) -- [2026-04-25] [Korean Business Navigator](sources/specialized-korean-business-navigator.md) -- [2026-04-25] [French Consulting Market Navigator](sources/specialized-french-consulting-market.md) -- [2026-04-25] [Blockchain Security Auditor](sources/blockchain-security-auditor.md) -- [2026-04-25] [Sales Data Extraction Agent](sources/sales-data-extraction-agent.md) -- [2026-04-25] [Study Abroad Advisor](sources/study-abroad-advisor.md) -- [2026-04-25] [Agents Orchestrator](sources/agents-orchestrator.md) -- [2026-04-25] [MCP Builder Agent](sources/specialized-mcp-builder.md) -- [2026-04-25] [Compliance Auditor Agent](sources/compliance-auditor.md) -- [2026-04-25] [Specialized Salesforce Architect](sources/specialized-salesforce-architect.md) -- [2026-04-25] [LSP/Index Engineer Agent Personality](sources/lsp-index-engineer.md) -- [2026-04-25] [Model QA Specialist](sources/specialized-model-qa.md) -- [2026-04-25] [Corporate Training Designer](sources/corporate-training-designer.md) -- [2026-04-25] [Cultural Intelligence Strategist](sources/specialized-cultural-intelligence-strategist.md) -- [2026-04-25] [Healthcare Marketing Compliance Specialist](sources/healthcare-marketing-compliance.md) -- [2026-04-24] [Workflow Architect Agent Personality](sources/specialized-workflow-architect.md) -- [2026-04-24] [Government Digital Presales Consultant](sources/government-digital-presales-consultant.md) -- [2026-04-24] [Agentic Identity & Trust Architect](sources/agentic-identity-trust.md) -- [2026-04-24] [Document Generator Agent](sources/specialized-document-generator.md) -- [2026-04-24] [Identity Graph Operator](sources/identity-graph-operator.md) -- [2026-04-24] [Accounts Payable Agent Personality](sources/accounts-payable-agent.md) -- [2026-04-24] [Recruitment Specialist Agent](sources/recruitment-specialist.md) -- [2026-04-24] [Specialized Civil Engineer Agent](sources/specialized-civil-engineer.md) -- [2026-04-24] [Experiment Tracker Agent Personality](sources/project-management-experiment-tracker.md) -- [2026-04-24] [Studio Operations Agent Personality](sources/project-management-studio-operations.md) -- [2026-04-24] [Senior Project Manager Agent Personality](sources/project-manager-senior.md) -- [2026-04-24] [Jira Workflow Steward Agent Personality](sources/project-management-jira-workflow-steward.md) -- [2026-04-24] [Project Shepherd Agent Personality](sources/project-management-project-shepherd.md) -- [2026-04-24] [Studio Producer Agent Personality](sources/project-management-studio-producer.md) -- [2026-04-24] [visionOS Spatial Engineer](sources/visionos-spatial-engineer.md) -- [2026-04-24] [XR Interface Architect Agent Personality](sources/xr-interface-architect.md) -- [2026-04-24] [macOS Spatial/Metal Engineer Agent Personality](sources/macos-spatial-metal-engineer.md) -- [2026-04-24] [Terminal Integration Specialist](sources/terminal-integration-specialist.md) -- [2026-04-24] [XR Immersive Developer Agent Personality](sources/xr-immersive-developer.md) -- [2026-04-24] [XR Cockpit Interaction Specialist Agent](sources/xr-cockpit-interaction-specialist.md) -- [2026-04-24] [Sales Engineer Agent](sources/sales-engineer.md) -- [2026-04-24] [Pipeline Analyst Agent](sources/sales-pipeline-analyst.md) -- [2026-04-24] [Outbound Strategist Agent](sources/sales-outbound-strategist.md) -- [2026-04-24] [Deal Strategist Agent](sources/sales-deal-strategist.md) -- [2026-04-24] [Account Strategist Agent](sources/sales-account-strategist.md) -- [2026-04-24] [Sales Proposal Strategist](sources/sales-proposal-strategist.md) -- [2026-04-24] [Sales Coach Agent](sources/sales-coach.md) -- [2026-04-24] [Discovery Coach Agent](sources/sales-discovery-coach.md) -- [2026-04-24] [Paid Media Tracking & Measurement Specialist Agent](sources/paid-media-tracking-specialist.md) -- [2026-04-24] [Paid Media Ad Creative Strategist Agent](sources/paid-media-creative-strategist.md) -- [2026-04-24] [Paid Social Strategist](sources/paid-media-paid-social-strategist.md) -- [2026-04-24] [Paid Media Search Query Analyst Agent](sources/paid-media-search-query-analyst.md) -- [2026-04-24] [Paid Media Auditor Agent](sources/paid-media-auditor.md) -- [2026-04-24] [Paid Media PPC Campaign Strategist Agent](sources/paid-media-ppc-strategist.md) -- [2026-04-24] [Paid Media Programmatic & Display Buyer Agent](sources/paid-media-programmatic-buyer.md) -- [2026-04-24] [Visual Storyteller Agent](sources/design-visual-storyteller.md) -- [2026-04-24] [Inclusive Visuals Specialist](sources/design-inclusive-visuals-specialist.md) -- [2026-04-24] [Image Prompt Engineer Agent](sources/design-image-prompt-engineer.md) -- [2026-04-24] [UI Designer Agent Personality](sources/design-ui-designer.md) -- [2026-04-24] [Design Brand Guardian](sources/design-brand-guardian.md) -- [2026-04-24] [UX Researcher Agent Personality](sources/design-ux-researcher.md) -- [2026-04-24] [Design Whimsy Injector](sources/design-whimsy-injector.md) -- [2026-04-24] [ArchitectUX Agent Personality](sources/design-ux-architect.md) -- [2026-04-24] [Contributing to The Agency](sources/contributing.md) -- [2026-04-24] [为 The Agency 贡献代码](sources/contributing_zh-cn.md) -- [2026-04-24] [CTP Topic 12 Using SES SMTP service terraform module](sources/ctp-topic-12-using-ses-smtp-service-terraform-module.md) -- [2026-04-24] [Learning Sessions Cloud Transformation Programme-Deploying RDS via Terraform](sources/learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform.md) -- [2026-04-24] [Learning Sessions Cloud Transformation Programme-20230808 183322-Meeting Recording](sources/learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi.md) -- [2026-04-24] [CTP Topic 16 Cross-account Terraform modules](sources/ctp-topic-16-cross-account-terraform-modules.md) -- [2026-04-24] [Learning Sessions ECS Deployment using IAC - 20230808](sources/learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording.md) -- [2026-04-24] [CTP Topic 48 Terraform vs Terragrunt](sources/ctp-topic-48-terraform-vs-terragrunt.md) -- [2026-04-24] [Public Cloud Learning Sessions (OpenText) - AI Use Cases - 20241126 160106](sources/public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec.md) -- [2026-04-24] [Public Cloud Learning Sessions (OpenText) - Event Driven Architecture Part 2](sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091.md) -- [2026-04-24] [Public Cloud Learning Sessions (OpenText) - Generative AI & Prompt Engineering - 20241112](sources/public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111.md) -- [2026-04-24] [Public Cloud Learning Sessions (OpenText) - Event Driven Architecture Part 1](sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091.md) -- [2026-04-24] [Public Cloud Learning Sessions - Serverless Computing - 20240903](sources/public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee.md) -- [2026-04-24] [Public Cloud Learning Sessions - Introduction to AI/ML with AWS](sources/public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin.md) -- [2026-04-24] [Cloud Learning Master Index](sources/cloud-learning-master-index.md) -- [2026-04-24] [CTP Topic 27 AWS Instance Scheduler](sources/ctp-topic-27-aws-instance-scheduler.md) -- [2026-04-24] [Public Cloud Learning Sessions - Budget Control - 20240319](sources/public-cloud-learning-sessions-budget-control-20240319-160204-meeting-recording.md) -- [2026-04-24] [CTP Topic 63 Optimise resource cost using automation](sources/ctp-topic-63-optimise-resource-cost-using-automation.md) -- [2026-04-24] [Public Cloud Learning Sessions - Storage Cost Optimization - 20240305](sources/public-cloud-learning-sessions-storage-cost-optimization-20240305-160037-meeting.md) -- [2026-04-24] [CTP Topic 71 PCG's guide to RightSizing, why, how when](sources/ctp-topic-71-pcgs-guide-to-rightsizing-why-how-when.md) -- [2026-04-24] [Public Cloud Learning Sessions - Best practices for EC2 cost optimization in AWS - 20240529](sources/public-cloud-learning-sessions-best-practices-for-ec2-cost-optimization-in-aws-2.md) -- [2026-04-24] [Public Cloud Learning Sessions - Reducing Cloud Costs - 20250318](sources/public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco.md) -- [2026-04-24] [CTP Topic 13 Cloud FinOps Micro Focus Policies best practices to optimize the costs](sources/ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co.md) -- [2026-04-24] [CTP Topic 15 Working with Renovatebot](sources/ctp-topic-15-working-with-renovatebot.md) -- [2026-04-24] [CTP Topic 56 Automated Infrastructure Testing](sources/ctp-topic-56-automated-infrastructure-testing.md) -- [2026-04-24] [Public Cloud Learning Sessions - Ollie Workflow and The Demand Process - 20240416](sources/public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16.md) -- [2026-04-24] [CTP Topic 33 An Introduction to GitOps](sources/ctp-topic-33-an-introduction-to-gitops.md) -- [2026-04-24] [CTP Topic 3 Deploy and maintain infrastructure](sources/ctp-topic-3-deploy-and-maintain-infrastructure.md) -- [2026-04-24] [CTP Topic 9 CI CD with Gruntwork](sources/ctp-topic-9-ci-cd-with-gruntwork.md) -- [2026-04-24] [CTP Topic 32 Using Atlantis CICD for Infrastructure Deployments](sources/ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments.md) -- [2026-04-24] [CTP Topic 2 Git](sources/ctp-topic-2-git.md) -- [2026-04-24] [CTP Topic 24 Micro Focus Product Privacy Framework](sources/ctp-topic-24-micro-focus-product-privacy-framework.md) -- [2026-04-24] [CTP Topic 49 Container Lifecycle Hardening Standards](sources/ctp-topic-49-container-lifecycle-hardening-standards.md) -- [2026-04-24] [CTP Topic 21 Supply Chain Security in Micro Focus](sources/ctp-topic-21-supply-chain-security-in-micro-focus.md) -- [2026-04-24] [CTP Topic 52 3 Lines of Defence (3LoD) framework Cloud Security Posture Management (CSPM)](sources/ctp-topic-52-3-lines-of-defence-3lod-framework-cloud-security-posture-management.md) -- [2026-04-24] [CTP Topic 55 AWS Firewall Manager](sources/ctp-topic-55-aws-firewall-manager.md) -- [2026-04-24] [CTP Topic 37 Secrets Certificates Management](sources/ctp-topic-37-secrets-certificates-management.md) -- [2026-04-24] [CTP Topic 62 AWS Secrets Manager](sources/ctp-topic-62-aws-secrets-manager.md) -- [2026-04-24] [Public Cloud Learning Sessions - OpenText GIS Security Policies - 20241015](sources/public-cloud-learning-sessions-opentext-gis-security-policies-20241015-160257-me.md) -- [2026-04-24] [CTP Topic 64 Scaling out with Amazon EKS](sources/ctp-topic-64-scaling-out-with-amazon-eks.md) -- [2026-04-24] [CTP Topic 67 Cloud native observability using OpenTelemetry](sources/ctp-topic-67-cloud-native-observability-using-opentelemetry.md) -- [2026-04-24] [Public Cloud Learning Sessions - EKS Optimization Part 2 of 3 - Running Containers with Bottlerocket OS](sources/public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w.md) -- [2026-04-24] [CTP Topic 42 Grafana Observability Dashboard](sources/ctp-topic-42-grafana-observability-dashboard.md) -- [2026-04-24] [Public Cloud Learning Sessions - Observability with OpenTelemetry - 20240402](sources/public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113.md) -- [2026-04-24] [CTP Topic 54 ESM SaaS Log Analytics](sources/ctp-topic-54-esm-saas-log-analytics.md) -- [2026-04-24] [CTP Topic 59 Achieving reliability with Amazon EKS](sources/ctp-topic-59-achieving-reliability-with-amazon-eks.md) -- [2026-04-24] [CTP Topic 29 Cloud Monitoring – SaaS LZ accounts](sources/ctp-topic-29-cloud-monitoring-saas-lz-accounts.md) -- [2026-04-24] [CTP Topic 39 Implementing EKS in the AWS Lab Landing Zone](sources/ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone.md) -- [2026-04-24] [Public Cloud Learning Sessions - EKS Optimization Part 1 of 3 - Compute Optimization with Karpenter](sources/public-cloud-learning-sessions-eks-optimization-part-1-of-3-compute-optimization.md) -- [2026-04-24] [CTP Topic 70 EKS deployment using IAC](sources/ctp-topic-70-eks-deployment-using-iac.md) -- [2026-04-24] [CTP Topic 60 - Monitor AWS using Hyperscale Observability with Grafana](sources/ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana.md) -- [2026-04-24] [Public Cloud Learning Sessions - EKS Optimization Part 3 of 3 - Introduction to EKS Auto Mode](sources/public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks.md) -- [2026-04-24] [CTP Topic 8 - Implementation of Cloud Monitoring using Micro Focus Operations Bridge Manager](sources/ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid.md) -- [2026-04-23] [CTP Topic 11 AD Integration and Login using AD Accounts](sources/ctp-topic-11-ad-integration-and-login-using-ad-accounts.md) -- [2026-04-23] [CTP Topic 5 - AWS Identity and Access Management (IAM)](sources/ctp-topic-5-aws-identity-and-access-management-iam.md) -- [2026-04-23] [Learning Sessions Identity Governance VSM Replacement - 20231128](sources/learning-sessions-identity-governance-vsm-replacement-20231128-160326-meeting-re.md) -- [2026-04-23] [Public Cloud Learning Sessions - AWS End User Compute Services - 20240430](sources/public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee.md) -- [2026-04-23] [Public Cloud Learning Sessions- Applicable Business Analysis Techniques - 20240109](sources/public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109.md) -- [2026-04-23] [Public Cloud Learning Sessions (OpenText) - Product Hub (PHT) Overview and Q&A - 20240806](sources/public-cloud-learning-sessions-opentext-product-hub-pht-overview-and-qa-20240806.md) -- [2026-04-23] [Public Cloud Learning Sessions - Tagging Standards for All Hyperscalers - 20240123](sources/public-cloud-learning-sessions-tagging-standards-for-all-hyperscalers-20240123-1.md) -- [2026-04-23] [CTP Topic 23 Introduction to the Technical Architecture Team and Function](sources/ctp-topic-23-introduction-to-the-technical-architecture-team-and-function.md) -- [2026-04-23] [CTP Topic 57 Product backlog managing demand](sources/ctp-topic-57-product-backlog-managing-demand.md) -- [2026-04-23] [Public Cloud Learning Sessions (OpenText) - Thor Platform & Flows](sources/public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet.md) -- [2026-04-23] [CTP Topic 6 AWS Workspaces Demo](sources/ctp-topic-6-aws-workspaces-demo.md) -- [2026-04-23] [CTP Topic 53 Why bother with Cloud](sources/ctp-topic-53-why-bother-with-cloud.md) -- [2026-04-23] [Public Cloud Learning Sessions (OpenText) - GitHub Enterprise to GitLab Migration](sources/public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20.md) -- [2026-04-23] [Public Cloud Learning Sessions - OpenText Tagging Standard v2 - 20250429](sources/public-cloud-learning-sessions-opentext-tagging-standard-v2-20250429-170111-meet.md) -- [2026-04-23] [CTP Topic 41 NFR's and Error Budgets](sources/ctp-topic-41-nfrs-and-error-budgets.md) -- [2026-04-23] [CTP Topic 10 AWS Landing Zone (LZ) Data Collection, Tagging Related Security](sources/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md) -- [2026-04-23] [CTP Topic 20 Program demand process flow and PoC onboarding](sources/ctp-topic-20-program-demand-process-flow-and-poc-onboarding.md) -- [2026-04-23] [CTP Topic 4 Using Agile to Run the Cloud Transformation Programme](sources/ctp-topic-4-using-agile-to-run-the-cloud-transformation-program.md) -- [2026-04-23] [CTP Topic 65 Tracing the Value Delivered in Cloud Transformation](sources/ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation.md) -- [2026-04-23] [Public Cloud Learning Sessions (OpenText) - Evolving from DR to Recovery Assurance - 20240723](sources/public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2.md) -- [2026-04-23] [CTP Topic 30 Managing Change](sources/ctp-topic-30-managing-change.md) -- [2026-04-23] [CTP Topic 69 Best Practices for Migrating On-Premises (IOD) Virtual Machines to VMware Cloud on AWS](sources/ctp-topic-69-best-practices-for-migrating-on-premises-iod-virtual-machines-to-vm.md) -- [2026-04-23] [CTP Topic 31 Network Segregation and Secure Access to the New AWS Landing Zones](sources/ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones.md) -- [2026-04-23] [CTP Topic 18 Wide Area Networking in AWS Cloud](sources/ctp-topic-18-wide-area-networking-in-aws-cloud.md) -- [2026-04-23] [CTP Topic 43 VMware Cloud on AWS](sources/ctp-topic-43-vmware-cloud-on-aws.md) -- [2026-04-23] [CTP Topic 61 Workload VPC provision with IPAM Automation](sources/ctp-topic-61-workload-vpc-provision-with-ipam-automation.md) -- [2026-04-23] [CTP Topic 45 Automatic IP address allocation with IPAM](sources/ctp-topic-45-automatic-ip-address-allocation-with-ipam.md) -- [2026-04-23] [CTP Topic 19 Configuring DNS within AWS LZs](sources/ctp-topic-19-configuring-dns-within-aws-lzs.md) -- [2026-04-23] [CTP Topic 36 SendGrid as an Email Service](sources/ctp-topic-36-sendgrid-as-an-email-service.md) -- [2026-04-23] [CTP Topic 22 Global DNS service offerings](sources/ctp-topic-22-global-dns-service-offerings.md) -- [2026-04-23] [CTP Topic 50 AMI Roadmap for AWS AMIs](sources/ctp-topic-50-ami-roadmap-for-aws-amis.md) -- [2026-04-23] [CTP Topic 40 SaaS Database Architecture On AWS Cloud](sources/ctp-topic-40-saas-database-architecture-on-aws-cloud.md) -- [2026-04-23] [CTP Topic 26 Standard AMI – build, publish, share processes](sources/ctp-topic-26-standard-ami-build-publish-share-processes.md) -- [2026-04-23] [CTP Topic 68 Introduction to Redshift](sources/ctp-topic-68-introduction-to-redshift.md) -- [2026-04-23] [CTP Topic 58 AWS EC2 Image Builder](sources/ctp-topic-58-aws-ec2-image-builder.md) -- [2026-04-23] [CTP Topic 25 Labs Landing Zone Overview - ITOM Teams](sources/ctp-topic-25-labs-landing-zone-overview-itom-teams.md) -- [2026-04-23] [Learning Sessions: Standard AMI Updates 20231205](sources/learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2.md) -- [2026-04-23] [CTP Topic 7 SaaS Landing Zone Design](sources/ctp-topic-7-saas-landing-zone-design.md) -- [2026-04-23] [CTP Topic 34 Azure Landing Zone Architecture Overview](sources/ctp-topic-34-azure-landing-zone-architecture-overview.md) -- [2026-04-23] [CTP Topic 35 AWS Landing Zone Design Refresher (SaaS Labs)](sources/ctp-topic-35-aws-landing-zone-design-refresher-saas-labs.md) -- [2026-04-23] [CTP Topic 10 AWS Landing Zone (LZ) Data Collection, Tagging Related Security](sources/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md) -- [2026-04-23] [CTP Topic 73 AWS Backup Implementation of the Cloud Transformation Programme](sources/ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program.md) -- [2026-04-23] [CTP Topic 28 AWS Tag Validation Tool](sources/ctp-topic-28-aws-tag-validation-tool.md) -- [2026-04-23] [CTP Topic 47 Enterprise Architecture Cloud Standards](sources/ctp-topic-47-enterprise-architecture-cloud-standards.md) -- [2026-04-23] [CTP Topic 72 Implementing an Enterprise DR Strategy Using AWS Backup](sources/ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup.md) -- [2026-04-23] [CTP Topic 1 Gruntwork Landing Zone Architecture](sources/ctp-topic-1-gruntwork-landing-zone-architecture.md) -- [2026-04-23] [CTP Topic 51 Architecting with AWS Purpose-Built Databases](sources/ctp-topic-51-architecting-with-aws-purpose-built-databases.md) -- [2026-04-23] [CTP Topic 46 NetApps on AWS](sources/ctp-topic-46-netapps-on-aws.md) -- [2026-04-23] [CTP Topic 17 Active Directory Services in Gruntwork AWS LZs](sources/ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs.md) -- [2026-04-23] [CTP Topic 66 Exposing the differences between PostgreSQL RDS and Aurora](sources/ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora.md) -- [2026-04-23] [CTP Topic 14 Octane Hub on AWS Real Life Experience Moving Production Services](sources/ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services-i.md) -- [2026-04-23] [CTP Topic 44 AWS Backup in Micro Focus](sources/ctp-topic-44-aws-backup-in-micro-focus.md) -- [2026-04-23] [Blogwatcher Daily 技能收藏](sources/blogwatcher-daily收藏.md) -- [2026-04-23] [实战笔记：本地部署 RSSHub 并获取 YouTube 订阅](sources/实战笔记-本地部署-rsshub-并获取-youtube-订阅.md) -- [2026-04-23] [Mac必装软件清单](sources/mac必装软件清单-2026-04-17.md) -- [2026-04-23] [Install WSL](sources/install-wsl.md) -- [2026-04-23] [WSL2 启动与网络配置指南](sources/wsl2-启动与网络配置指南.md) -- [2026-04-23] [fireworks-tech-graph](sources/fireworks-tech-graph.md) -- [2026-04-23] [Obsidian 官方 CLI 命令全景速查表](sources/obsidian-官方-cli-命令全景速查表.md) -- [2026-04-23] [Obsidian CLI](sources/obsidian-cli.md) -- [2026-04-23] [我做了个 Skill：让 AI 帮你生成 Logo 和图标](sources/我做了个-skill-让-ai-帮你生成-logo-和图标.md) -- [2026-04-23] [Obsidian 必装 Skills](sources/obsidian-必装-skills.md) -- [2026-04-23] [在 Ubuntu 安装 Ollama 并运行 Qwen2.5‑Coder 7B](sources/在-ubuntu-安装-ollama-并运行-qwen2-5‑coder-7b.md) -- [2026-04-23] [Learn AI for free directly from top companies](sources/learn-ai-for-free-directly-from-top-companies.md) -- [2026-04-23] [I Went Through Every AI Memory Tool I Could Find. There Are Two Camps.](sources/ai-memory-tools-two-camps.md) -- [2026-04-23] [可自动化、可扩展、AI增强的电商数据采集与处理系统](sources/可自动化-可扩展-ai增强的电商数据采集与处理系统.md) -- [2026-04-23] [Building your Quartz](sources/building-your-quartz.md) -- [2026-04-23] [电商如何选品 - 如何找到爆款选品策略](sources/电商如何选品-如何找到爆款-选品策略.md) -- [2026-04-23] [电商视频Prompt库](sources/电商视频prompt.md) -- [2026-04-23] [TikTok Shop - Apache Superset Dashboard设计思路](sources/tiktok-shop-apache-superset-dashboard设计思路.md) -- [2026-04-23] [做TK跨境思路不对努力白费](sources/做tk跨境思路不对努力白费.md) -- [2026-04-23] [超达物流定价](sources/超达物流定价.md) -- [2026-04-23] [TK美国面单授权及操作流程](sources/tk美国面单授权及操作流程.md) -- [2026-04-23] [Scrapy + Playwright 抓取TikTok Shop Data](sources/scrapy-playwright-抓取tiktok-shop-data.md) -- [2026-04-23] [GOG CLI 安装配置指南](sources/gog-cli-安装配置指南.md) -- [2026-04-23] [Last30Days 使用指南](sources/last30days-使用指南.md) -- [2026-04-23] [如何利用Sora接口实现视频自动化生成工作流](sources/如何利用sora接口实现视频自动化生成工作流.md) -- [2026-04-23] [If You Have Multiple Interests, Do Not Waste the Next 2-3 Years](sources/if-you-have-multiple-interests-do-not-waste-the-next-2-3-years-如果你有多项兴趣爱好-不要浪费接下来的两三年时间.md) -- [2026-04-23] [我用 Gemini 3 一口气做了 10 个应用，附教程](sources/我用-gemini-3-一口气做了-10-个应用-附教程.md) -- [2026-04-23] [Multi-Agent System Reliability](sources/multi-agent-system-reliability.md) -- [2026-04-23] [全网最全！Nano Banana 2 使用指南（2025年12月更新）](sources/全网最全-nano-banana-2-使用指南-2025年12月更新-1.md) -- [2026-04-23] [2025 年 11 个神级 AI 开源平替，GitHub 杀疯了](sources/2025-年-11-个神级-ai-开源平替-github-杀疯了.md) -- [2026-04-23] [AI 解决方案专家培训课程](sources/ai-解决方案专家培训课程.md) -- [2026-04-23] [RAG从入门到精通系列1：基础RAG](sources/rag从入门到精通系列1-基础rag.md) -- [2026-04-23] [固定镜头短视频制作的AI全流程解析](sources/固定镜头短视频制作的ai全流程解析.md) -- [2026-04-23] [大模型相关术语和框架总结｜LLM、MCP、Prompt、RAG、vLLM、Token、数据蒸馏](sources/大模型相关术语和框架总结｜llm-mcp-prompt-rag-vllm-token-数据蒸馏.md) -- [2026-04-23] [Nano Banana Pro 提示词指南与策略（上篇）](sources/nano-banana-pro-prompting-guide-strategies-1.md) -- [2026-04-23] [我的工具集](sources/我的工具集.md) -- [2026-04-23] [3.2 万人收藏的 Claude Skills，才是 AI 这条路上最值得研究的一套范式！](sources/3-2-万人收藏的-claude-skills-才是-ai-这条路上最值得研究的一套范式.md) -- [2026-04-23] [如何写出完美的Prompt（提示词）？](sources/如何写出完美的prompt-提示词.md) -- [2026-04-23] [codecrafters-io/build-your-own-x: Master programming by recreating your favorite technologies from scratch](sources/codecrafters-iobuild-your-own-x-master-programming-by-recreating-your-favorite-technologies-from-scratch.md) -- [2026-04-23] [系统提示词构建原则](sources/系统提示词构建原则.md) -- [2026-04-23] [GitHub 上 5000 人收藏的 Vibe Coding 神级指南](sources/github-上-5000-人收藏的-vibe-coding-神级指南.md) -- [2026-04-23] [How to Get the RSS Feed For Any YouTube Channel](sources/how-to-get-the-rss-feed-for-any-youtube-channel.md) -- [2026-04-23] [3.2 万人收藏的 Claude Skills，才是 AI 这条路上最值得研究的一套范式！](sources/3-2-万人收藏的-claude-skills-才是-ai-这条路上最值得研究的一套范式-1.md) -- [2026-04-22] [不会Gemini的产品经理真的要被淘汰了 | 附保姆级PRD生成指南](sources/不会gemini的产品经理真的要被淘汰了-附保姆级prd生成指南.md) -- [2026-04-22] [7 ways I use NotebookLM to make my life easier](sources/7-ways-i-use-notebooklm-to-make-my-life-easier.md) -- [2026-04-22] [Never write another prompt](sources/never-write-another-prompt.md) -- [2026-04-22] [一语点醒梦中人](sources/一语点醒梦中人.md) -- [2026-04-22] [Best 7 news API data feeds - AI News](sources/best-7-news-api-data-feeds-ai-news.md) -- [2026-04-22] [Claude Prompt Library 汇总表](sources/useful-prompt-lib.md) -- [2026-04-22] [二创视频必不可少！2025年最热门AI工具推荐合集-AI配音、声音克隆](sources/二创视频必不可少-2025年最热门ai工具推荐合集-ai配音-声音克隆.md) -- [2026-04-22] [The Picture They Paint of You](sources/the-picture-they-paint-of-you.md) -- [2026-04-22] [Nano Banana 提示词框架](sources/nano-banana-提示词框架.md) -- [2026-04-22] [谷歌深夜甩出一份【Nano Banana Pro提示词指南】，手把手教你生产专业级内容，实战案例+提示词模版](sources/谷歌深夜甩出一份-nano-banana-pro提示词指南-手把手教你生产专业级内容-实战案例-提示词模版.md) -- [2026-04-22] [详细！离线部署大模型：ollama+deepseek+open-webui安装使用方法及常见问题解决 1](sources/详细-离线部署大模型-ollama-deepseek-open-webui安装使用方法及常见问题解决-1.md) -- [2026-04-22] [OpenAI ChatGPT 个性化定义](sources/openai-chatgpt-个性化定义.md) -- [2026-04-22] [清华出的DeepSeek使用手册，104页，真的是太厉害了！（免费领取）](sources/清华出的deepseek使用手册-104页-真的是太厉害了-免费领取.md) -- [2026-04-22] [LLMs、RAG、AI Agent 三个到底什么区别？](sources/llms-rag-ai-agent-三个到底什么区别.md) -- [2026-04-22] [A Formalization of Recursive Self-Optimizing Generative Systems](sources/a-formalization-of-recursive-self-optimizing-generative-systems.md) -- [2026-04-22] [文字生成视频网站推荐](sources/文字生成视频网站推荐.md) -- [2026-04-22] [Google 神级生产力工具，所有 GitHub 开源平替都找到了。](sources/google-神级生产力工具-所有-github-开源平替都找到了.md) -- [2026-04-22] [教學 ChatGPT 先做知識整理，再讓 Canva、 Gamma AI 輸出簡報](sources/教學-chatgpt-先做知識整理-再讓-canva-gamma-ai-輸出簡報.md) -- [2026-04-22] [Designing for Agentic AI](sources/designing-for-agentic-ai.md) -- [2026-04-22] [14个免费的AI图生视频工具，用AI让图片动起来](sources/14个免费的ai图生视频工具-用ai让图片动起来-ai视频教程-ai自动化工作流定制服务-ai培训学习平台-黑喵大叔.md) -- [2026-04-22] [养虾日记5：深夜与苏轼聊AI，他说：被浪打下去还能爬起来的才叫风流](sources/养虾日记5-深夜与苏轼聊ai-他说-被浪打下去还能爬起来的才叫风流.md) -- [2026-04-22] [养虾日记4：一次「Context Limit Exceeded」错误排查：我以为是小问题，结果踩了大坑](sources/养虾日记4-一次「context-limit-exceeded」错误排查-我以为是小问题-结果踩了大坑.md) -- [2026-04-22] [不谈技术：普通人该怎么在AI时代赚钱？](sources/不谈技术-普通人该怎么在ai时代赚钱.md) -- [2026-04-22] [养虾日记3：用 Obsidian + Gitea 为 AI 助手构建持久化笔记系统](sources/养虾日记3-用-obsidian-gitea-为-ai-助手构建持久化笔记系统.md) -- [2026-04-22] [养龙虾5天血泪史：我的AI Agent为什么总失忆？OpenClaw 记忆调试全记录](sources/养龙虾5天血泪史-我的ai-agent为什么总失忆-openclaw-记忆调试全记录.md) -- [2026-04-22] [养虾日记1：我用 OpenClaw 管了 28 万张照片：一次真实的多设备照片整理实战](sources/养虾日记1-我用-openclaw-管了-28-万张照片-一次真实的多设备照片整理实战.md) -- [2026-04-22] [养虾日记2：让Agent更懂你：OpenClaw + Self-Improving 复盘实战案例分享](sources/养虾日记2-让agent更懂你-openclaw-self-improving-复盘实战案例分享.md) -- [2026-04-22] [X Account Analysis](sources/x-account-analysis.md) -- [2026-04-22] [Phone Call Notifications](sources/phone-call-notifications.md) -- [2026-04-22] [Autonomous Educational Game Development Pipeline](sources/autonomous-game-dev-pipeline.md) -- [2026-04-22] [arXiv Paper Reader](sources/arxiv-paper-reader.md) -- [2026-04-22] [Semantic Memory Search](sources/semantic-memory-search.md) -- [2026-04-22] [OpenClaw as Desktop Cowork (AionUi) — Remote Rescue & Multi-Agent Hub](sources/aionui-cowork-desktop.md) -- [2026-04-22] [Family Calendar Aggregation & Household Assistant](sources/family-calendar-household-assistant.md) -- [2026-04-22] [Multi-Source Tech News Digest](sources/multi-source-tech-news-digest.md) -- [2026-04-22] [X/Twitter Automation from Chat](sources/x-twitter-automation.md) -- [2026-04-22] [Personal Knowledge Base (RAG)](sources/knowledge-base-rag.md) -- [2026-04-22] [Personal CRM with Automatic Contact Discovery](sources/personal-crm.md) -- [2026-04-22] [YouTube Content Pipeline](sources/youtube-content-pipeline.md) -- [2026-04-22] [Polymarket Autopilot](sources/polymarket-autopilot.md) -- [2026-04-22] [Goal-Driven Autonomous Tasks](sources/overnight-mini-app-builder.md) -- [2026-04-22] [Local CRM Framework with DenchClaw](sources/local-crm-framework.md) -- [2026-04-22] [OpenClaw + n8n Workflow Orchestration](sources/n8n-workflow-orchestration.md) -- [2026-04-22] [Multi-Channel AI Customer Service Platform](sources/multi-channel-customer-service.md) -- [2026-04-22] [Second Brain](sources/second-brain.md) -- [2026-04-22] [LaTeX Paper Writing](sources/latex-paper-writing.md) -- [2026-04-22] [Habit Tracker & Accountability Coach](sources/habit-tracker-accountability-coach.md) -- [2026-04-22] [Todoist Task Manager](sources/todoist-task-manager.md) -- [2026-04-22] [Dynamic Dashboard with Sub-agent Spawning](sources/dynamic-dashboard.md) -- [2026-04-22] [Pre-Build Idea Validator](sources/pre-build-idea-validator.md) -- [2026-04-22] [Autonomous Project Management with Subagents](sources/autonomous-project-management.md) -- [2026-04-22] [Daily Reddit Digest](sources/daily-reddit-digest.md) -- [2026-04-22] [Inbox De-clutter](sources/inbox-declutter.md) -- [2026-04-22] [Custom Morning Brief](sources/custom-morning-brief.md) -- [2026-04-22] [Market Research & Product Factory](sources/market-research-product-factory.md) -- [2026-04-22] [Phone-Based Personal Assistant](sources/phone-based-personal-assistant.md) -- [2026-04-22] [Event Guest Confirmation](sources/event-guest-confirmation.md) -- [2026-04-22] [Multi-Channel Personal Assistant](sources/multi-channel-assistant.md) -- [2026-04-22] [AI-Powered Earnings Tracker](sources/earnings-tracker.md) -- [2026-04-22] [Multi-Agent Specialized Team (Solo Founder Setup)](sources/multi-agent-team.md) -- [2026-04-22] [Project State Management System: Event-Driven Alternative to Kanban](sources/project-state-management.md) -- [2026-04-22] [Health & Symptom Tracker](sources/health-symptom-tracker.md) -- [2026-04-22] [Self-Healing Home Server & Infrastructure Management](sources/self-healing-home-server.md) -- [2026-04-22] [Multi-Agent Content Factory](sources/content-factory.md) -- [2026-04-22] [Daily YouTube Digest](sources/daily-youtube-digest.md) -- [2026-04-22] [Automated Meeting Notes & Action Items](sources/meeting-notes-action-items.md) -- [2026-04-22] [Podcast Production Pipeline](sources/podcast-production-pipeline.md) -- [2026-04-22] [Claude Code 调用方法总结](sources/claude-code调用方法总结.md) -- [2026-04-22] [N8N Full Tutorial Building AI Agents in 2025 for Beginners!](sources/n8n-full-tutorial-building-ai-agents-in-2025-for-beginners.md) -- [2026-04-22] [n8n + Claude：通过自然语言自动化工作流](sources/n8n-claude-通过自然语言自动化工作流.md) -- [2026-04-22] [万字保姆级教程，让你90天跑通一人公司模式（附AI提示词）](sources/万字保姆级教程-90天跑通一人公司模式-2026-03-29.md) -- [2026-04-22] [使用Claude自动生成N8N工作流的实操教程](sources/使用claude自动生成n8n工作流的实操教程.md) -- [2026-04-22] [MCP在Cursor中的集成与应用详解](sources/mcp在cursor中的集成与应用详解.md) -- [2026-04-22] [Google 5个 Agent Skill 设计模式](sources/google-5个agent-skill设计模式-2026-03-19.md) -- [2026-04-22] [n8n configure telegram trigger](sources/n8n-configure-telegram-trigger.md) -- [2026-04-22] [n8n Docker 安装与更新](sources/n8n-docker-install-update.md) -- [2026-04-22] [万字讲透OpenClaw Workspace深度解析](sources/万字讲透openclaw-workspace深度解析-2026-03-21.md) -- [2026-04-22] [How to get Youtube Channel ID](sources/how-to-get-youtube-channel-id.md) -- [2026-04-22] [TikTok PM - Python Django 项目](sources/tiktok-pm-python-django-project.md) -- [2026-04-22] [dataview-让我从“笔记黑洞”里逃出来的-obsidian-神器-1](sources/dataview-让我从“笔记黑洞”里逃出来的-obsidian-神器-1.md) — (expected: wiki/sources/dataview-让我从“笔记黑洞”里逃出来的-obsidian-神器-1.md — source missing) -- [2026-04-22] [Obsidian 高效指南：我常用的插件与实用技巧](sources/obsidian-高效指南-我常用的插件与实用技巧.md) -- [2026-04-22] [Obsidian最有必要安装的10款插件是这些](sources/obsidian最有必要安装的10款插件是这些.md) -- [2026-04-22] [Obsidian Tasks 插件：这可能是最适合懒人的任务管理方式](sources/obsidian-tasks-插件-这可能是最适合懒人的任务管理方式.md) -- [2026-04-22] [ChinaTextbook - 41.53 GB，中国小学、初中、高中、大学 PDF 教材](sources/chinatextbook-41-53-gb-中国小学-初中-高中-大学-pdf-教材.md) -- [2026-04-22] [开发经验与项目规范整理文档](sources/开发经验与项目规范整理文档.md) -- [2026-04-22] [在Ubuntu上安装Vibe-Kanban](sources/在ubuntu上安装vibe-kanban.md) -- [2026-04-22] [Vibe-Kanban + OpenCode 在 Ubuntu Server 上安装与管理指南](sources/vibe-kanban-opencode-在-ubuntu-server-上安装与管理指南.md) -- [2026-04-22] [Vibe Coding 经验收集](sources/vibe-coding经验收集.md) -- [2026-04-22] [如何在项目里安装Claude Code Templates Skills](sources/如何在项目里安装claude-code-templates-skills.md) -- [2026-04-22] [Trae远程开发部署指南](sources/trae远程开发部署指南.md) -- [2026-04-22] [Cursor 2.0初学者使用指南](sources/cursor-2-0初学者使用指南.md) -- [2026-04-22] [如何在Ubuntu上安装OpenCode并配置Vibe-Kanban](sources/如何在ubuntu上安装opencode并配置vibe-kanban.md) -- [2026-04-22] [如何传输Docker images 并且在另一个Docker安装](sources/如何传输docker-images-并且在另一个docker安装.md) -- [2026-04-22] [Ubuntu用RustDesk远程登录出现不能使用Wayland登录的错误](sources/ubuntu用rustdesk远程登录出现不能使用wayland登录的错误.md) -- [2026-04-21] [用Docker安装Homarr](sources/用docker安装homarr.md) -- [2026-04-21] [在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透](sources/在ubuntu上通过vps-内网反向代理实现域名访问内网穿透.md) -- [2026-04-21] [如何在Ubuntu Server上通过NFS挂载Synology NAS上的共享文件夹](sources/如何在ubuntu-server上通过nfs挂载synology-nas上的共享文件夹.md) -- [2026-04-21] [用Docker安装Apache Superset](sources/用docker安装apache-superset.md) -- [2026-04-21] [Mac Mini 服务器配置：防止自动锁屏与睡眠](sources/mac-mini-服务器配置-防止自动锁屏与睡眠.md) -- [2026-04-21] [家庭网络环境概览](sources/家庭网络环境概览_2026-04-03.md) -- [2026-04-21] [如何删除旧的废弃的Docker Container + Volume](sources/如何删除旧的废弃的docker-container-volume.md) -- [2026-04-21] [用Docker安装Portainer](sources/用docker安装portainer.md) -- [2026-04-21] [用Docker安装Jellyfin](sources/用docker安装jellyfin.md) -- [2026-04-21] [Ubuntu Server科学上网](sources/ubuntu-server科学上网.md) -- [2026-04-21] [Ubuntu禁用合盖休眠](sources/ubuntu禁用合盖休眠.md) -- [2026-04-21] [安装v2rayN](sources/安装v2rayn.md) -- [2026-04-21] [Install Apache Superset in Docker](sources/install-apache-superset-in-docker.md) -- [2026-04-21] [MinIO + Zipline 自托管图床应用安装教程](sources/minio-zipline-自托管图床应用安装教程.md) -- [2026-04-21] [群晖NAS科学上网方法](sources/群晖nas科学上网方法.md) -- [2026-04-21] [NodeWarden - 把 Bitwarden 搬上 Cloudflare Workers，彻底告别服务器](sources/nodewarden-把-bitwarden-搬上-cloudflare-workers-彻底告别服务器.md) -- [2026-04-21] [macOS 创建与解除 Symbolic Link（OpenClaw 目录映射）](sources/macos-创建与解除-symbolic-link-openclaw-目录映射.md) -- [2026-04-21] [如何在Ubuntu Server安装 Docker & Docker Compose](sources/如何在ubuntu-server安装-docker-docker-compose.md) -- [2026-04-21] [家庭监控方案：Prometheus + Grafana + Node Exporter + cAdvisor + Blackbox](sources/家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox.md) -- [2026-04-21] [Ubuntu 安装 FRP 0.65.0（x86_64）操作笔记](sources/ubuntu-安装-frp-0-65-0-x86_64-操作笔记.md) -- [2026-04-21] [Mac Mini 安装 FRP 0.65.0（ARM64）操作笔记](sources/mac-mini-安装-frp-0-65-0-arm64-操作笔记.md) -- [2026-04-21] [在Synology NAS上安装CloudDrive2](sources/在synology-nas上安装clouddrive2.md) -- [2026-04-21] [如何判别你的Linux 服务器是 x64（也就是 x86_64）还是 ARM64](sources/如何判别你的linux-服务器是-x64-也就是-x86_64-还是-arm64.md) -- [2026-04-21] [如何用指纹浏览器安全注册并订阅Claude Pro会员全攻略](sources/如何用指纹浏览器安全注册并订阅claude-pro会员全攻略.md) -- [2026-04-21] [安装Ubuntu 24.04.2在HP ZBook工作站笔记本上](sources/安装ubuntu-24-04-2在hp-zbook工作站笔记本上.md) -- [2026-04-21] [用Docker安装it-tools](sources/用docker安装it-tools.md) -- [2026-04-21] [通过VPS+内网反向代理实现域名访问内网穿透](sources/通过vps-内网反向代理实现域名访问内网穿透.md) -- [2026-04-21] [Clonezilla对Ubuntu Server进行全盘镜像备份](sources/clonezilla对ubuntu-server进行全盘镜像备份.md) -- [2026-04-21] [3X-UI Xray on BandwagonVPS](sources/3x-ui-xray-on-bandwagonvps.md) -- [2026-04-21] [Ubuntu 24.04 启动 SSH 服务](sources/ubuntu-24-04-enable-ssh.md) -- [2026-04-21] [用Docker安装transmission](sources/用docker安装transmission.md) -- [2026-04-21] [RAX50 路由器更新Merlin Clash订阅](sources/rax50-路由器-更新merlin-clash订阅.md) -- [2026-04-21] [网件RAX50路由器刷梅林固件与科学上网插件安装教程](sources/网件rax50路由器刷梅林固件与科学上网插件安装教程.md) -- [2026-04-21] [MySQL MariaDB 数据库详细信息](sources/mysql-mariadb-数据库详细信息.md) -- [2026-04-21] [Ubuntu服务器通过rsync实现日常增量备份](sources/ubuntu服务器通过rsync实现日常增量备份.md) -- [2026-04-21] [Linux 运维必会的 150 个命令](sources/linux-运维必会的-150-个命令.md) -- [2026-04-21] [用Docker中安装Navidrome](sources/用docker中安装navidrome.md) -- [2026-04-21] [Cloud Operating Model: Key Strategies and Best Practices](sources/cloud-operating-model-key-strategies-and-best-practices.md) -- [2026-04-21] [What is DevSecOps? Best Practices, Benefits, and Tools](sources/what-is-devsecops-best-practices-benefits-and-tools.md) -- [2026-04-21] [Modern ITSM: Driving Efficiency, Security & Resilience](sources/understanding-complete-itsm.md) -- [2026-04-21] [How to Simplify Multi-Account Deployments Monitoring: Centralized Logs for AWS CloudFormation StackSets](sources/how-to-simplify-multi-account-deployments-monitoring-centralized-logs-for-aws-cloudformation-stacksets.md) -- [2026-04-21] [RTO vs RPO: Key Differences for Modern Disaster Recovery](sources/rto-vs-rpo-key-differences-for-modern-disaster-recovery.md) -- [2026-04-21] [These 6 Linux Apps Let You Monitor System Resources in Style](sources/these-6-linux-apps-let-you-monitor-system-resources-in-style.md) -- [2026-04-21] [Public vs Private vs Hybrid Cloud Differences Explained](sources/public-vs-private-vs-hybrid-cloud-differences-explained.md) -- [2026-04-21] [How Agentic AI can help for Cloud DevOps](sources/how-agentic-ai-can-help-for-cloud-devops.md) -- [2026-04-21] [The Myths and Misconceptions About Cloud Computing | LinkedIn](sources/the-myths-and-misconceptions-about-cloud-computing-linkedin.md) -- [2026-04-21] [Cloud Maturity Model - A Detailed Guide For Cloud Adoption](sources/cloud-maturity-model-a-detailed-guide-for-cloud-adoption.md) -- [2026-04-21] [DevOps Maturity Model From Traditional IT to Advanced DevOps](sources/devops-maturity-model-from-traditional-it-to-advanced-devops.md) -- [2026-04-21] [How Can a Multi Cloud Strategy Transform Your Business ROI?](sources/how-can-a-multi-cloud-strategy-transform-your-business-roi.md) -- [2026-04-21] [What I Know About Cloud Service Delivery 1](sources/what-i-know-about-cloud-service-delivery-1.md) -- [2026-04-21] [Cloud DevOp Maturity - Guideline](sources/cloud-devop-maturity-guideline.md) -- [2026-04-21] [DevOps Culture and Transformation: Fostering Collaboration, Agile Practices, and Innovation](sources/devops-culture-and-transformation-fostering-collaboration-agile-practices-and-innovation-linkedin.md) -- [2026-04-21] [marketing-weibo-strategist](sources/marketing-weibo-strategist.md) — (expected: wiki/sources/marketing-weibo-strategist.md — source missing) -- [2026-04-21] [marketing-baidu-seo-specialist](sources/marketing-baidu-seo-specialist.md) — (expected: wiki/sources/marketing-baidu-seo-specialist.md — source missing) -- [2026-04-21] [marketing-carousel-growth-engine](sources/marketing-carousel-growth-engine.md) — (expected: wiki/sources/marketing-carousel-growth-engine.md — source missing) -- [2026-04-21] [marketing-private-domain-operator](sources/marketing-private-domain-operator.md) — (expected: wiki/sources/marketing-private-domain-operator.md — source missing) -- [2026-04-21] [marketing-short-video-editing-coach](sources/marketing-short-video-editing-coach.md) — (expected: wiki/sources/marketing-short-video-editing-coach.md — source missing) -- [2026-04-21] [marketing-social-media-strategist](sources/marketing-social-media-strategist.md) — (expected: wiki/sources/marketing-social-media-strategist.md — source missing) -- [2026-04-21] [marketing-kuaishou-strategist](sources/marketing-kuaishou-strategist.md) — (expected: wiki/sources/marketing-kuaishou-strategist.md — source missing) -- [2026-04-21] [marketing-video-optimization-specialist](sources/marketing-video-optimization-specialist.md) — (expected: wiki/sources/marketing-video-optimization-specialist.md — source missing) -- [2026-04-21] [marketing-instagram-curator](sources/marketing-instagram-curator.md) — (expected: wiki/sources/marketing-instagram-curator.md — source missing) -- [2026-04-21] [marketing-china-ecommerce-operator](sources/marketing-china-ecommerce-operator.md) — (expected: wiki/sources/marketing-china-ecommerce-operator.md — source missing) -- [2026-04-21] [marketing-reddit-community-builder](sources/marketing-reddit-community-builder.md) — (expected: wiki/sources/marketing-reddit-community-builder.md — source missing) -- [2026-04-21] [marketing-cross-border-ecommerce](sources/marketing-cross-border-ecommerce.md) — (expected: wiki/sources/marketing-cross-border-ecommerce.md — source missing) -- [2026-04-21] [marketing-book-co-author](sources/marketing-book-co-author.md) — (expected: wiki/sources/marketing-book-co-author.md — source missing) -- [2026-04-21] [marketing-zhihu-strategist](sources/marketing-zhihu-strategist.md) — (expected: wiki/sources/marketing-zhihu-strategist.md — source missing) -- [2026-04-21] [marketing-douyin-strategist](sources/marketing-douyin-strategist.md) — (expected: wiki/sources/marketing-douyin-strategist.md — source missing) -- [2026-04-21] [nexus-spatial-discovery](sources/nexus-spatial-discovery.md) — (expected: wiki/sources/nexus-spatial-discovery.md — source missing) -- [2026-04-21] [workflow-with-memory](sources/workflow-with-memory.md) — (expected: wiki/sources/workflow-with-memory.md — source missing) -- [2026-04-21] [workflow-landing-page](sources/workflow-landing-page.md) — (expected: wiki/sources/workflow-landing-page.md — source missing) -- [2026-04-21] [workflow-startup-mvp](sources/workflow-startup-mvp.md) — (expected: wiki/sources/workflow-startup-mvp.md — source missing) -- [2026-04-21] [OpenCode Integration](sources/readme.md) -- [2026-04-21] [workflow-book-chapter](sources/workflow-book-chapter.md) — (expected: wiki/sources/workflow-book-chapter.md — source missing) -- [2026-04-21] [support-executive-summary-generator](sources/support-executive-summary-generator.md) — (expected: wiki/sources/support-executive-summary-generator.md — source missing) -- [2026-04-21] [support-finance-tracker](sources/support-finance-tracker.md) — (expected: wiki/sources/support-finance-tracker.md — source missing) -- [2026-04-21] [support-infrastructure-maintainer](sources/support-infrastructure-maintainer.md) — (expected: wiki/sources/support-infrastructure-maintainer.md — source missing) -- [2026-04-21] [support-support-responder](sources/support-support-responder.md) — (expected: wiki/sources/support-support-responder.md — source missing) -- [2026-04-21] [support-analytics-reporter](sources/support-analytics-reporter.md) — (expected: wiki/sources/support-analytics-reporter.md — source missing) -- [2026-04-21] [support-legal-compliance-checker](sources/support-legal-compliance-checker.md) — (expected: wiki/sources/support-legal-compliance-checker.md — source missing) -- [2026-04-21] [testing-accessibility-auditor](sources/testing-accessibility-auditor.md) — (expected: wiki/sources/testing-accessibility-auditor.md — source missing) -- [2026-04-20] [security](sources/security.md) — (expected: wiki/sources/security.md — source missing) -- [2026-04-20] [llm-wiki](sources/llm-wiki.md) — (expected: wiki/sources/llm-wiki.md — source missing) -- [2026-04-20] [baoyu-skills](sources/baoyu-skills.md) — (expected: wiki/sources/baoyu-skills.md — source missing) -- [Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog](sources/Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog.md) — (expected: wiki/sources/Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog.md — source missing) -- [Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend](sources/Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend.md) — (expected: wiki/sources/Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend.md — source missing) -- [n8n-调用openclaw-agents的工作流架构](sources/n8n-调用openclaw-agents的工作流架构.md) — (expected: wiki/sources/n8n-调用openclaw-agents的工作流架构.md — source missing) -- [n8n-docker-配置-telegram-代理-troubleshooting](sources/n8n-docker-配置-telegram-代理-troubleshooting.md) — (expected: wiki/sources/n8n-docker-配置-telegram-代理-troubleshooting.md — source missing) -- [n8n调用hermes-agents的工作流架构](sources/n8n调用hermes-agents的工作流架构.md) — (expected: wiki/sources/n8n调用hermes-agents的工作流架构.md — source missing) -- [open-webui-hermes-agent](sources/open-webui-hermes-agent.md) — (expected: wiki/sources/open-webui-hermes-agent.md — source missing) -- [language-translator](sources/language-translator.md) — (expected: wiki/sources/language-translator.md — source missing) -- [loan-officer-assistant](sources/loan-officer-assistant.md) — (expected: wiki/sources/loan-officer-assistant.md — source missing) -- [real-estate-buyer-seller](sources/real-estate-buyer-seller.md) — (expected: wiki/sources/real-estate-buyer-seller.md — source missing) -- [legal-document-review](sources/legal-document-review.md) — (expected: wiki/sources/legal-document-review.md — source missing) -- [sales-outreach](sources/sales-outreach.md) — (expected: wiki/sources/sales-outreach.md — source missing) -- [retail-customer-returns](sources/retail-customer-returns.md) — (expected: wiki/sources/retail-customer-returns.md — source missing) -- [specialized-chief-of-staff](sources/specialized-chief-of-staff.md) — (expected: wiki/sources/specialized-chief-of-staff.md — source missing) -- [hr-onboarding](sources/hr-onboarding.md) — (expected: wiki/sources/hr-onboarding.md — source missing) -- [customer-service](sources/customer-service.md) — (expected: wiki/sources/customer-service.md — source missing) -- [healthcare-customer-service](sources/healthcare-customer-service.md) — (expected: wiki/sources/healthcare-customer-service.md — source missing) -- [legal-billing-time-tracking](sources/legal-billing-time-tracking.md) — (expected: wiki/sources/legal-billing-time-tracking.md — source missing) -- [legal-client-intake](sources/legal-client-intake.md) — (expected: wiki/sources/legal-client-intake.md — source missing) -- [hospitality-guest-services](sources/hospitality-guest-services.md) — (expected: wiki/sources/hospitality-guest-services.md — source missing) -- [OpenCode Integration](sources/readme.md) -- [marketing-seo-specialist](sources/marketing-seo-specialist.md) — (expected: wiki/sources/marketing-seo-specialist.md — source missing) -- [marketing-agentic-search-optimizer](sources/marketing-agentic-search-optimizer.md) — (expected: wiki/sources/marketing-agentic-search-optimizer.md — source missing) -- [OpenCode Integration](sources/readme.md) -- [finance-bookkeeper-controller](sources/finance-bookkeeper-controller.md) — (expected: wiki/sources/finance-bookkeeper-controller.md — source missing) -- [finance-fpa-analyst](sources/finance-fpa-analyst.md) — (expected: wiki/sources/finance-fpa-analyst.md — source missing) -- [finance-investment-researcher](sources/finance-investment-researcher.md) — (expected: wiki/sources/finance-investment-researcher.md — source missing) -- [finance-financial-analyst](sources/finance-financial-analyst.md) — (expected: wiki/sources/finance-financial-analyst.md — source missing) -- [finance-tax-strategist](sources/finance-tax-strategist.md) — (expected: wiki/sources/finance-tax-strategist.md — source missing) -- [engineering-voice-ai-integration-engineer](sources/engineering-voice-ai-integration-engineer.md) — (expected: wiki/sources/engineering-voice-ai-integration-engineer.md — source missing) -- [engineering-codebase-onboarding-engineer](sources/engineering-codebase-onboarding-engineer.md) — (expected: wiki/sources/engineering-codebase-onboarding-engineer.md — source missing) -- [engineering-minimal-change-engineer](sources/engineering-minimal-change-engineer.md) — (expected: wiki/sources/engineering-minimal-change-engineer.md — source missing) -- [sre-weekly-issue-513](sources/sre-weekly-issue-513.md) — (expected: wiki/sources/sre-weekly-issue-513.md — source missing) -- [karpathy-最新分享-用-llm-搭建个人知识库-告别-rag-的低效循环](sources/karpathy-最新分享-用-llm-搭建个人知识库-告别-rag-的低效循环.md) — (expected: wiki/sources/karpathy-最新分享-用-llm-搭建个人知识库-告别-rag-的低效循环.md — source missing) -- [如何让ai生成风格一致的图片](sources/如何让ai生成风格一致的图片.md) — (expected: wiki/sources/如何让ai生成风格一致的图片.md — source missing) -- [scenario-startup-mvp](sources/scenario-startup-mvp.md) — (expected: wiki/sources/scenario-startup-mvp.md — source missing) -- [scenario-marketing-campaign](sources/scenario-marketing-campaign.md) — (expected: wiki/sources/scenario-marketing-campaign.md — source missing) -- [scenario-incident-response](sources/scenario-incident-response.md) — (expected: wiki/sources/scenario-incident-response.md — source missing) -- [scenario-enterprise-feature](sources/scenario-enterprise-feature.md) — (expected: wiki/sources/scenario-enterprise-feature.md — source missing) -- [phase-6-operate](sources/phase-6-operate.md) — (expected: wiki/sources/phase-6-operate.md — source missing) -- [phase-5-launch](sources/phase-5-launch.md) — (expected: wiki/sources/phase-5-launch.md — source missing) -- [phase-4-hardening](sources/phase-4-hardening.md) — (expected: wiki/sources/phase-4-hardening.md — source missing) -- [phase-3-build](sources/phase-3-build.md) — (expected: wiki/sources/phase-3-build.md — source missing) -- [phase-2-foundation](sources/phase-2-foundation.md) — (expected: wiki/sources/phase-2-foundation.md — source missing) -- [phase-1-strategy](sources/phase-1-strategy.md) — (expected: wiki/sources/phase-1-strategy.md — source missing) -- [phase-0-discovery](sources/phase-0-discovery.md) — (expected: wiki/sources/phase-0-discovery.md — source missing) -- [nexus-strategy](sources/nexus-strategy.md) — (expected: wiki/sources/nexus-strategy.md — source missing) -- [handoff-templates](sources/handoff-templates.md) — (expected: wiki/sources/handoff-templates.md — source missing) -- [agent-activation-prompts](sources/agent-activation-prompts.md) — (expected: wiki/sources/agent-activation-prompts.md — source missing) -- [quickstart](sources/quickstart.md) — (expected: wiki/sources/quickstart.md — source missing) -- [executive-brief](sources/executive-brief.md) — (expected: wiki/sources/executive-brief.md — source missing) -- [marketing-xiaohongshu-specialist](sources/marketing-xiaohongshu-specialist.md) — (expected: wiki/sources/marketing-xiaohongshu-specialist.md — source missing) -- [marketing-wechat-official-account](sources/marketing-wechat-official-account.md) — (expected: wiki/sources/marketing-wechat-official-account.md — source missing) -- [marketing-twitter-engager](sources/marketing-twitter-engager.md) — (expected: wiki/sources/marketing-twitter-engager.md — source missing) -- [marketing-tiktok-strategist](sources/marketing-tiktok-strategist.md) — (expected: wiki/sources/marketing-tiktok-strategist.md — source missing) -- [marketing-podcast-strategist](sources/marketing-podcast-strategist.md) — (expected: wiki/sources/marketing-podcast-strategist.md — source missing) -- [marketing-livestream-commerce-coach](sources/marketing-livestream-commerce-coach.md) — (expected: wiki/sources/marketing-livestream-commerce-coach.md — source missing) -- [marketing-linkedin-content-creator](sources/marketing-linkedin-content-creator.md) — (expected: wiki/sources/marketing-linkedin-content-creator.md — source missing) -- [marketing-growth-hacker](sources/marketing-growth-hacker.md) — (expected: wiki/sources/marketing-growth-hacker.md — source missing) -- [marketing-content-creator](sources/marketing-content-creator.md) — (expected: wiki/sources/marketing-content-creator.md — source missing) -- [marketing-china-market-localization-strategist](sources/marketing-china-market-localization-strategist.md) — (expected: wiki/sources/marketing-china-market-localization-strategist.md — source missing) -- [marketing-bilibili-content-strategist](sources/marketing-bilibili-content-strategist.md) — (expected: wiki/sources/marketing-bilibili-content-strategist.md — source missing) -- [marketing-app-store-optimizer](sources/marketing-app-store-optimizer.md) — (expected: wiki/sources/marketing-app-store-optimizer.md — source missing) -- [marketing-ai-citation-strategist](sources/marketing-ai-citation-strategist.md) — (expected: wiki/sources/marketing-ai-citation-strategist.md — source missing) -- [unreal-world-builder](sources/unreal-world-builder.md) — (expected: wiki/sources/unreal-world-builder.md — source missing) -- [unreal-technical-artist](sources/unreal-technical-artist.md) — (expected: wiki/sources/unreal-technical-artist.md — source missing) -- [unreal-systems-engineer](sources/unreal-systems-engineer.md) — (expected: wiki/sources/unreal-systems-engineer.md — source missing) -- [unreal-multiplayer-architect](sources/unreal-multiplayer-architect.md) — (expected: wiki/sources/unreal-multiplayer-architect.md — source missing) -- [unity-shader-graph-artist](sources/unity-shader-graph-artist.md) — (expected: wiki/sources/unity-shader-graph-artist.md — source missing) -- [unity-multiplayer-engineer](sources/unity-multiplayer-engineer.md) — (expected: wiki/sources/unity-multiplayer-engineer.md — source missing) -- [unity-editor-tool-developer](sources/unity-editor-tool-developer.md) — (expected: wiki/sources/unity-editor-tool-developer.md — source missing) -- [unity-architect](sources/unity-architect.md) — (expected: wiki/sources/unity-architect.md — source missing) -- [technical-artist](sources/technical-artist.md) — (expected: wiki/sources/technical-artist.md — source missing) -- [roblox-systems-scripter](sources/roblox-systems-scripter.md) — (expected: wiki/sources/roblox-systems-scripter.md — source missing) -- [roblox-experience-designer](sources/roblox-experience-designer.md) — (expected: wiki/sources/roblox-experience-designer.md — source missing) -- [roblox-avatar-creator](sources/roblox-avatar-creator.md) — (expected: wiki/sources/roblox-avatar-creator.md — source missing) -- [narrative-designer](sources/narrative-designer.md) — (expected: wiki/sources/narrative-designer.md — source missing) -- [level-designer](sources/level-designer.md) — (expected: wiki/sources/level-designer.md — source missing) -- [godot-shader-developer](sources/godot-shader-developer.md) — (expected: wiki/sources/godot-shader-developer.md — source missing) -- [godot-multiplayer-engineer](sources/godot-multiplayer-engineer.md) — (expected: wiki/sources/godot-multiplayer-engineer.md — source missing) -- [godot-gameplay-scripter](sources/godot-gameplay-scripter.md) — (expected: wiki/sources/godot-gameplay-scripter.md — source missing) -- [game-designer](sources/game-designer.md) — (expected: wiki/sources/game-designer.md — source missing) -- [game-audio-engineer](sources/game-audio-engineer.md) — (expected: wiki/sources/game-audio-engineer.md — source missing) -- [blender-addon-engineer](sources/blender-addon-engineer.md) — (expected: wiki/sources/blender-addon-engineer.md — source missing) -- [engineering-wechat-mini-program-developer](sources/engineering-wechat-mini-program-developer.md) — (expected: wiki/sources/engineering-wechat-mini-program-developer.md — source missing) -- [engineering-threat-detection-engineer](sources/engineering-threat-detection-engineer.md) — (expected: wiki/sources/engineering-threat-detection-engineer.md — source missing) -- [engineering-technical-writer](sources/engineering-technical-writer.md) — (expected: wiki/sources/engineering-technical-writer.md — source missing) -- [engineering-sre](sources/engineering-sre.md) — (expected: wiki/sources/engineering-sre.md — source missing) -- [engineering-solidity-smart-contract-engineer](sources/engineering-solidity-smart-contract-engineer.md) — (expected: wiki/sources/engineering-solidity-smart-contract-engineer.md — source missing) -- [engineering-software-architect](sources/engineering-software-architect.md) — (expected: wiki/sources/engineering-software-architect.md — source missing) -- [engineering-senior-developer](sources/engineering-senior-developer.md) — (expected: wiki/sources/engineering-senior-developer.md — source missing) -- [engineering-security-engineer](sources/engineering-security-engineer.md) — (expected: wiki/sources/engineering-security-engineer.md — source missing) -- [engineering-rapid-prototyper](sources/engineering-rapid-prototyper.md) — (expected: wiki/sources/engineering-rapid-prototyper.md — source missing) -- [engineering-mobile-app-builder](sources/engineering-mobile-app-builder.md) — (expected: wiki/sources/engineering-mobile-app-builder.md — source missing) -- [engineering-incident-response-commander](sources/engineering-incident-response-commander.md) — (expected: wiki/sources/engineering-incident-response-commander.md — source missing) -- [engineering-git-workflow-master](sources/engineering-git-workflow-master.md) — (expected: wiki/sources/engineering-git-workflow-master.md — source missing) -- [engineering-frontend-developer](sources/engineering-frontend-developer.md) — (expected: wiki/sources/engineering-frontend-developer.md — source missing) -- [engineering-filament-optimization-specialist](sources/engineering-filament-optimization-specialist.md) — (expected: wiki/sources/engineering-filament-optimization-specialist.md — source missing) -- [engineering-feishu-integration-developer](sources/engineering-feishu-integration-developer.md) — (expected: wiki/sources/engineering-feishu-integration-developer.md — source missing) -- [engineering-embedded-firmware-engineer](sources/engineering-embedded-firmware-engineer.md) — (expected: wiki/sources/engineering-embedded-firmware-engineer.md — source missing) -- [engineering-email-intelligence-engineer](sources/engineering-email-intelligence-engineer.md) — (expected: wiki/sources/engineering-email-intelligence-engineer.md — source missing) -- [engineering-devops-automator](sources/engineering-devops-automator.md) — (expected: wiki/sources/engineering-devops-automator.md — source missing) -- [engineering-database-optimizer](sources/engineering-database-optimizer.md) — (expected: wiki/sources/engineering-database-optimizer.md — source missing) -- [engineering-data-engineer](sources/engineering-data-engineer.md) — (expected: wiki/sources/engineering-data-engineer.md — source missing) -- [engineering-code-reviewer](sources/engineering-code-reviewer.md) — (expected: wiki/sources/engineering-code-reviewer.md — source missing) -- [engineering-cms-developer](sources/engineering-cms-developer.md) — (expected: wiki/sources/engineering-cms-developer.md — source missing) -- [engineering-backend-architect](sources/engineering-backend-architect.md) — (expected: wiki/sources/engineering-backend-architect.md — source missing) -- [engineering-autonomous-optimization-architect](sources/engineering-autonomous-optimization-architect.md) — (expected: wiki/sources/engineering-autonomous-optimization-architect.md — source missing) -- [engineering-ai-engineer](sources/engineering-ai-engineer.md) — (expected: wiki/sources/engineering-ai-engineer.md — source missing) -- [engineering-ai-data-remediation-engineer](sources/engineering-ai-data-remediation-engineer.md) — (expected: wiki/sources/engineering-ai-data-remediation-engineer.md — source missing) - -## Entities -- [Acemoglu](entities/Acemoglu.md) -- [ACI-318](entities/ACI-318.md) -- [Acronis](entities/Acronis.md) -- [AdamSmith](entities/AdamSmith.md) -- [ADK](entities/ADK.md) -- [AdsPower](entities/AdsPower.md) -- [Agentic-AI](entities/Agentic-AI.md) -- [AionUi](entities/AionUi.md) -- [AISC-360](entities/AISC-360.md) -- [aitmpl.com](entities/aitmpl.com.md) -- [Alertmanager](entities/Alertmanager.md) -- [Alex-Ewerlof](entities/Alex-Ewerlof.md) -- [Alex-Finn](entities/Alex-Finn.md) -- [Amazon-API-Gateway](entities/Amazon-API-Gateway.md) -- [Amazon-Aurora](entities/Amazon-Aurora.md) -- [Amazon-CloudWatch-Logs](entities/Amazon-CloudWatch-Logs.md) -- [Amazon-DocumentDB](entities/Amazon-DocumentDB.md) -- [Amazon-DynamoDB](entities/Amazon-DynamoDB.md) -- [Amazon-ElastiCache](entities/Amazon-ElastiCache.md) -- [Amazon-EventBridge](entities/Amazon-EventBridge.md) -- [Amazon-Keyspaces](entities/Amazon-Keyspaces.md) -- [Amazon-Neptune](entities/Amazon-Neptune.md) -- [Amazon-RDS](entities/Amazon-RDS.md) -- [Amazon-Redshift](entities/Amazon-Redshift.md) -- [Amazon-Timestream](entities/Amazon-Timestream.md) -- [AmazonAds](entities/AmazonAds.md) -- [Andrej-Karpathy](entities/Andrej-Karpathy.md) -- [Anthropic](entities/Anthropic.md) -- [Apache-Superset](entities/Apache-Superset.md) -- [Asana](entities/Asana.md) -- [ASCE-7](entities/ASCE-7.md) -- [Ashish](entities/Ashish.md) -- [Atlantis](entities/Atlantis.md) -- [AWS](entities/AWS.md) -- [AWS-CloudFormation-StackSets](entities/AWS-CloudFormation-StackSets.md) -- [AWS-Lambda](entities/AWS-Lambda.md) -- [AWS-OpenSearch](entities/AWS-OpenSearch.md) -- [AWS-Organizations](entities/AWS-Organizations.md) -- [AWS-Step-Functions](entities/AWS-Step-Functions.md) -- [Axton](entities/Axton.md) -- [Azure](entities/Azure.md) -- [BackendArchitect](entities/BackendArchitect.md) -- [baoyu](entities/baoyu.md) -- [BehavioralNudgeEngine](entities/BehavioralNudgeEngine.md) -- [bitwarden](entities/bitwarden.md) -- [blackbox-exporter](entities/blackbox-exporter.md) -- [BMC](entities/BMC.md) -- [BossZhipin](entities/BossZhipin.md) -- [Bottlerocket](entities/Bottlerocket.md) -- [bottom](entities/bottom.md) -- [Brendan-Starnig](entities/Brendan-Starnig.md) -- [btop++](entities/btop++.md) -- [Caddy](entities/Caddy.md) -- [cAdvisor](entities/cAdvisor.md) -- [Calibre](entities/Calibre.md) -- [Canva](entities/Canva.md) -- [ChatGPT](entities/ChatGPT.md) -- [Checkpoint](entities/Checkpoint.md) -- [Choi-Wontak](entities/Choi-Wontak.md) -- [Claude-Desktop](entities/Claude-Desktop.md) -- [Claude-Pro](entities/Claude-Pro.md) -- [ClawdTalk](entities/ClawdTalk.md) -- [ClawHub](entities/ClawHub.md) -- [clawr.ing](entities/clawr.ing.md) -- [Cline](entities/Cline.md) -- [Clonezilla](entities/Clonezilla.md) -- [cloud-computing](entities/cloud-computing.md) -- [Cloud-Maturity-Model](entities/Cloud-Maturity-Model.md) -- [Cloud-Provider](entities/Cloud-Provider.md) -- [clouddrive2](entities/clouddrive2.md) -- [CodeCrafters](entities/CodeCrafters.md) -- [CodeWeaver](entities/CodeWeaver.md) -- [containerd](entities/containerd.md) -- [Coze](entities/Coze.md) -- [Cursor](entities/Cursor.md) -- [Curve-Finance](entities/Curve-Finance.md) -- [DanielStefanovic](entities/DanielStefanovic.md) -- [DeepLearningAI](entities/DeepLearningAI.md) -- [DeepSeek](entities/DeepSeek.md) -- [DeepSider](entities/DeepSider.md) -- [DenchClaw](entities/DenchClaw.md) -- [DevOps-Maturity-Model](entities/DevOps-Maturity-Model.md) -- [Dify](entities/Dify.md) -- [docker-buildx-plugin](entities/docker-buildx-plugin.md) -- [docker-ce](entities/docker-ce.md) -- [docker-compose-plugin](entities/docker-compose-plugin.md) -- [Docker-Desktop](entities/Docker-Desktop.md) -- [docker-engine](entities/docker-engine.md) -- [Docker-Network](entities/Docker-Network.md) -- [Docker卷](entities/Docker卷.md) -- [DORA-Metrics](entities/DORA-Metrics.md) -- [Douyin](entities/Douyin.md) -- [DracoVibeCoding](entities/DracoVibeCoding.md) -- [DXC-VSM](entities/DXC-VSM.md) -- [DXY](entities/DXY.md) -- [EESJGong](entities/EESJGong.md) -- [Euler-Finance](entities/Euler-Finance.md) -- [Eurocode](entities/Eurocode.md) -- [fireworks-tech-graph](entities/fireworks-tech-graph.md) -- [Flux](entities/Flux.md) -- [frp](entities/frp.md) -- [Gamma-AI](entities/Gamma-AI.md) -- [GDPR](entities/GDPR.md) -- [Gitea](entities/Gitea.md) -- [GitHubCopilot](entities/GitHubCopilot.md) -- [Gitmoji](entities/Gitmoji.md) -- [glances](entities/glances.md) -- [gog](entities/gog.md) -- [gog-CLI](entities/gog-CLI.md) -- [Google](entities/Google.md) -- [Google-Cloud](entities/Google-Cloud.md) -- [GoogleAds](entities/GoogleAds.md) -- [GoogleCloud](entities/GoogleCloud.md) -- [Grafana](entities/Grafana.md) -- [Gruntwork](entities/Gruntwork.md) -- [HashiCorp](entities/HashiCorp.md) -- [Heather-Norris](entities/Heather-Norris.md) -- [hello-world](entities/hello-world.md) -- [HemantSawant](entities/HemantSawant.md) -- [HIPAA](entities/HIPAA.md) -- [HP-ZBook](entities/HP-ZBook.md) -- [htop](entities/htop.md) -- [HunyuanVideo](entities/HunyuanVideo.md) -- [IBM](entities/IBM.md) -- [idea-reality-mcp](entities/idea-reality-mcp.md) -- [InsightsLM](entities/InsightsLM.md) -- [Intelephense](entities/Intelephense.md) -- [Intsas.local](entities/Intsas.local.md) -- [ISO-27001](entities/ISO-27001.md) -- [it-tools](entities/it-tools.md) -- [Jared-Diamond](entities/Jared-Diamond.md) -- [Jay-Comer](entities/Jay-Comer.md) -- [Jellyfin](entities/Jellyfin.md) -- [Jira](entities/Jira.md) -- [Jira-Workflow-Steward](entities/Jira-Workflow-Steward.md) -- [JohnWilliams](entities/JohnWilliams.md) -- [K3s](entities/K3s.md) -- [KAI](entities/KAI.md) -- [KakaoTalk](entities/KakaoTalk.md) -- [kepano](entities/kepano.md) -- [KoolCenter固件服务器](entities/KoolCenter固件服务器.md) -- [Kubernetes](entities/Kubernetes.md) -- [LangChain](entities/LangChain.md) -- [LaunchDarkly](entities/LaunchDarkly.md) -- [LeonardoDaVinci](entities/LeonardoDaVinci.md) -- [Linear](entities/Linear.md) -- [LinkedIn-Campaign-Manager](entities/LinkedIn-Campaign-Manager.md) -- [LinuxServer.io](entities/LinuxServer.io.md) -- [LSIF](entities/LSIF.md) -- [Mac-Mini-M4](entities/Mac-Mini-M4.md) -- [Mackinder](entities/Mackinder.md) -- [macOS-Spatial-Metal-Engineer](entities/macOS-Spatial-Metal-Engineer.md) -- [Manus](entities/Manus.md) -- [MariaDB](entities/MariaDB.md) -- [Martin-Nash](entities/Martin-Nash.md) -- [MCP（Model Context Protocol）](entities/MCP（Model Context Protocol）.md) -- [Mem0](entities/Mem0.md) -- [Memsearch](entities/Memsearch.md) -- [MerlinClash插件](entities/MerlinClash插件.md) -- [Meta-Ads-Manager](entities/Meta-Ads-Manager.md) -- [Micro-Focus](entities/Micro-Focus.md) -- [Micro-Focus-IGA](entities/Micro-Focus-IGA.md) -- [Microsoft-Planner](entities/Microsoft-Planner.md) -- [MicrosoftAdvertising](entities/MicrosoftAdvertising.md) -- [Midjourney](entities/Midjourney.md) -- [Milvus](entities/Milvus.md) -- [MinIO](entities/MinIO.md) -- [mission-center](entities/mission-center.md) -- [n8n](entities/n8n.md) -- [n8n-mcp](entities/n8n-mcp.md) -- [Nano Banana 2](entities/Nano Banana 2.md) -- [Navidrome](entities/Navidrome.md) -- [NetApp](entities/NetApp.md) -- [Netdata](entities/Netdata.md) -- [NicholasCarlini](entities/NicholasCarlini.md) -- [Niklas-Luhmann](entities/Niklas-Luhmann.md) -- [NMPA](entities/NMPA.md) -- [node-exporter](entities/node-exporter.md) -- [Node.js](entities/Node.js.md) -- [nodewarden](entities/nodewarden.md) -- [Nomad-Bridge](entities/Nomad-Bridge.md) -- [NotebookLlama](entities/NotebookLlama.md) -- [NotebookLM](entities/NotebookLM.md) -- [Obsidian](entities/Obsidian.md) -- [Octane-Hub](entities/Octane-Hub.md) -- [Ollama](entities/Ollama.md) -- [Open-Alliance-for-Cloud-Adoption](entities/Open-Alliance-for-Cloud-Adoption.md) -- [Open-WebUI](entities/Open-WebUI.md) -- [OpenAI](entities/OpenAI.md) -- [OpenClaw](entities/OpenClaw.md) -- [openclaw-n8n-stack](entities/openclaw-n8n-stack.md) -- [OpenCode](entities/OpenCode.md) -- [OpenManus](entities/OpenManus.md) -- [OpenNotebook](entities/OpenNotebook.md) -- [PageLM](entities/PageLM.md) -- [Perplexica](entities/Perplexica.md) -- [Phenops-Team](entities/Phenops-Team.md) -- [PingMe](entities/PingMe.md) -- [Podcastfy](entities/Podcastfy.md) -- [Portainer](entities/Portainer.md) -- [Prismer-AI](entities/Prismer-AI.md) -- [Product-Security-Group](entities/Product-Security-Group.md) -- [Project-Management-Experiment-Tracker](entities/Project-Management-Experiment-Tracker.md) -- [Prometheus](entities/Prometheus.md) -- [Public-Cloud-Provider](entities/Public-Cloud-Provider.md) -- [Qdrant](entities/Qdrant.md) -- [Qwen](entities/Qwen.md) -- [RackNerd](entities/RackNerd.md) -- [RAIT-09](entities/RAIT-09.md) -- [Raj-Vardhan-Singh](entities/Raj-Vardhan-Singh.md) -- [Recapio](entities/Recapio.md) -- [RichardFeynman](entities/RichardFeynman.md) -- [rsvg-convert](entities/rsvg-convert.md) -- [rsync](entities/rsync.md) -- [Rufus](entities/Rufus.md) -- [RustDesk](entities/RustDesk.md) -- [SAM-Serverless-Application-Model](entities/SAM-Serverless-Application-Model.md) -- [SAMR](entities/SAMR.md) -- [SankarGopov](entities/SankarGopov.md) -- [shenwei](entities/shenwei.md) -- [Simon-Hoiberg](entities/Simon-Hoiberg.md) -- [Slack](entities/Slack.md) -- [SMACKS](entities/SMACKS.md) -- [SMACs](entities/SMACs.md) -- [SONY](entities/SONY.md) -- [SparkryAI](entities/SparkryAI.md) -- [SRE-Team](entities/SRE-Team.md) -- [Stable-Diffusion](entities/Stable-Diffusion.md) -- [stacer](entities/stacer.md) -- [Studio-Producer](entities/Studio-Producer.md) -- [Suravpul](entities/Suravpul.md) -- [SurfSense](entities/SurfSense.md) -- [Swinford.net](entities/Swinford.net.md) -- [Synology-NAS-DS718](entities/Synology-NAS-DS718.md) -- [Telnyx](entities/Telnyx.md) -- [Terraform](entities/Terraform.md) -- [Terragrunt](entities/Terragrunt.md) -- [The-Agency](entities/The-Agency.md) -- [The-DAO-2016](entities/The-DAO-2016.md) -- [Tiago-Forte](entities/Tiago-Forte.md) -- [TikTok-Ads](entities/TikTok-Ads.md) -- [tini](entities/tini.md) -- [Todoist](entities/Todoist.md) -- [Trae](entities/Trae.md) -- [TranscriptAPI](entities/TranscriptAPI.md) -- [Transmission](entities/Transmission.md) -- [TruffleHog](entities/TruffleHog.md) -- [tukuai](entities/tukuai.md) -- [TweetClaw](entities/TweetClaw.md) -- [TypeScript-Language-Server](entities/TypeScript-Language-Server.md) -- [Ubuntu-Server](entities/Ubuntu-Server.md) -- [Uptime-Kuma](entities/Uptime-Kuma.md) -- [Veeam](entities/Veeam.md) -- [Vibe-Kanban](entities/Vibe-Kanban.md) -- [VictoriaMetrics](entities/VictoriaMetrics.md) -- [Vinay](entities/Vinay.md) -- [VMware](entities/VMware.md) -- [WildCard](entities/WildCard.md) -- [Windsurf](entities/Windsurf.md) -- [Xiaohongshu](entities/Xiaohongshu.md) -- [XR-Cockpit-Interaction-Specialist](entities/XR-Cockpit-Interaction-Specialist.md) -- [XR-Immersive-Developer](entities/XR-Immersive-Developer.md) -- [XR-Interface-Architect](entities/XR-Interface-Architect.md) -- [YishenTu](entities/YishenTu.md) -- [Zipline](entities/Zipline.md) -- [zk-steward-companion](entities/zk-steward-companion.md) -- [余梦珑](entities/余梦珑.md) -- [剪映](entities/剪映.md) -- [机场](entities/机场.md) -- [梅林固件](entities/梅林固件.md) -- [滴滴](entities/滴滴.md) -- [盖伊亨德里克斯](entities/盖伊亨德里克斯.md) -- [矿神源](entities/矿神源.md) -- [网件RAX50](entities/网件RAX50.md) -- [苏东坡](entities/苏东坡.md) - -## Concepts -- [14种UML图](concepts/14种UML图.md) -- [7种视觉风格系统](concepts/7种视觉风格系统.md) -- [ABTesting](concepts/ABTesting.md) -- [Account-Health-Score](concepts/Account-Health-Score.md) -- [Account-Tiering-Model](concepts/Account-Tiering-Model.md) -- [AccountArchitecture](concepts/AccountArchitecture.md) -- [ActionItemTracking](concepts/ActionItemTracking.md) -- [Active-Accountability](concepts/Active-Accountability.md) -- [Adaptive-Tone](concepts/Adaptive-Tone.md) -- [ADDIE-Model](concepts/ADDIE-Model.md) -- [AdExtensions](concepts/AdExtensions.md) -- [AdStrength](concepts/AdStrength.md) -- [Advantage+-Campaigns](concepts/Advantage+-Campaigns.md) -- [Adversarial-Debate-Pattern](concepts/Adversarial-Debate-Pattern.md) -- [Agent-Build-Gate](concepts/Agent-Build-Gate.md) -- [Agent-Design-Principles](concepts/Agent-Design-Principles.md) -- [Agent-Driven-Market-Research](concepts/Agent-Driven-Market-Research.md) -- [Agent-Memory](concepts/Agent-Memory.md) -- [Agent-Mode](concepts/Agent-Mode.md) -- [Agent-Personality](concepts/Agent-Personality.md) -- [Agent-Routing-Rules](concepts/Agent-Routing-Rules.md) -- [Agent-Specialization](concepts/Agent-Specialization.md) -- [Agent-Template](concepts/Agent-Template.md) -- [AgentFileFormat](concepts/AgentFileFormat.md) -- [AGENTS.md](concepts/AGENTS.md.md) -- [Agile-Ceremonies](concepts/Agile-Ceremonies.md) -- [AgilePractices](concepts/AgilePractices.md) -- [Aha-Moment](concepts/Aha-Moment.md) -- [AI-Agent](concepts/AI-Agent.md) -- [AI-Auto-Response](concepts/AI-Auto-Response.md) -- [AI-ChatOps](concepts/AI-ChatOps.md) -- [AI-Driven-Task-Extraction](concepts/AI-Driven-Task-Extraction.md) -- [AI-Logo-Generation](concepts/AI-Logo-Generation.md) -- [Ai-Powered-Digest](concepts/Ai-Powered-Digest.md) -- [AIOps](concepts/AIOps.md) -- [AI代理](concepts/AI代理.md) -- [AI图生视频](concepts/AI图生视频.md) -- [AI开源平替](concepts/AI开源平替.md) -- [AI文生视频](concepts/AI文生视频.md) -- [AI簡報工作流](concepts/AI簡報工作流.md) -- [Alerting](concepts/Alerting.md) -- [Algorithm-Agility](concepts/Algorithm-Agility.md) -- [Amazon-EKS](concepts/Amazon-EKS.md) -- [AmbientMessageMonitoring](concepts/AmbientMessageMonitoring.md) -- [Analogy-as-Straitjacket](concepts/Analogy-as-Straitjacket.md) -- [Annales-School](concepts/Annales-School.md) -- [Appearance-Anxiety](concepts/Appearance-Anxiety.md) -- [APT-仓库配置](concepts/APT-仓库配置.md) -- [Architectural-Empathy](concepts/Architectural-Empathy.md) -- [arXiv-API](concepts/arXiv-API.md) -- [Asset-Management](concepts/Asset-Management.md) -- [Atomic-Commit](concepts/Atomic-Commit.md) -- [Attachment-Theory](concepts/Attachment-Theory.md) -- [Attach容器](concepts/Attach容器.md) -- [Attention-Economy](concepts/Attention-Economy.md) -- [Audit-Trail](concepts/Audit-Trail.md) -- [Automated-Health-Logging](concepts/Automated-Health-Logging.md) -- [Automated-Security-Audit](concepts/Automated-Security-Audit.md) -- [AutomationGovernance](concepts/AutomationGovernance.md) -- [Availability](concepts/Availability.md) -- [AWS-Secrets-Manager](concepts/AWS-Secrets-Manager.md) -- [AWS-Source-Identity](concepts/AWS-Source-Identity.md) -- [AWS-Tagging-Standards](concepts/AWS-Tagging-Standards.md) -- [AWS-Tags](concepts/AWS-Tags.md) -- [BEATS](concepts/BEATS.md) -- [Behavioral-Psychology](concepts/Behavioral-Psychology.md) -- [Big-Five-Personality](concepts/Big-Five-Personality.md) -- [BindMount](concepts/BindMount.md) -- [BI平台](concepts/BI平台.md) -- [Blocking](concepts/Blocking.md) -- [Bloom-认知分类](concepts/Bloom-认知分类.md) -- [Blue-Green-Deployment](concepts/Blue-Green-Deployment.md) -- [Blue-Hat-Logo](concepts/Blue-Hat-Logo.md) -- [BOOTSTRAP.md](concepts/BOOTSTRAP.md.md) -- [Brain-Dump](concepts/Brain-Dump.md) -- [Branch-Strategy](concepts/Branch-Strategy.md) -- [Brand-Environment](concepts/Brand-Environment.md) -- [Break-the-Build](concepts/Break-the-Build.md) -- [Bug-Bounty](concepts/Bug-Bounty.md) -- [Build-Mode](concepts/Build-Mode.md) -- [Build-Your-Own-X](concepts/Build-Your-Own-X.md) -- [BuildInPublic](concepts/BuildInPublic.md) -- [Business-Impact-Analysis](concepts/Business-Impact-Analysis.md) -- [Business-Knowledge-Base](concepts/Business-Knowledge-Base.md) -- [caffeinate](concepts/caffeinate.md) -- [Calibration-Testing](concepts/Calibration-Testing.md) -- [Call-Worthy-Threshold](concepts/Call-Worthy-Threshold.md) -- [Canary-Deployment](concepts/Canary-Deployment.md) -- [Canary-Release](concepts/Canary-Release.md) -- [Canvas](concepts/Canvas.md) -- [CAPA](concepts/CAPA.md) -- [Centralized-Logging](concepts/Centralized-Logging.md) -- [CEOPattern](concepts/CEOPattern.md) -- [Chained Agents](concepts/Chained Agents.md) -- [Challenger-Sales-Model](concepts/Challenger-Sales-Model.md) -- [Change-Failure-Rate](concepts/Change-Failure-Rate.md) -- [Change-Management](concepts/Change-Management.md) -- [Channel-Based-Monitoring](concepts/Channel-Based-Monitoring.md) -- [Character-Arc](concepts/Character-Arc.md) -- [Check-in-Fatigue](concepts/Check-in-Fatigue.md) -- [ChinaLaborLawCompliance](concepts/ChinaLaborLawCompliance.md) -- [CI-CD-Pipeline](concepts/CI-CD-Pipeline.md) -- [CICDPipeline](concepts/CICDPipeline.md) -- [CIS-Benchmark](concepts/CIS-Benchmark.md) -- [Claude-Code-Templates](concepts/Claude-Code-Templates.md) -- [Claude-Skills](concepts/Claude-Skills.md) -- [Claudian](concepts/Claudian.md) -- [Cloud-Adoption-Strategy](concepts/Cloud-Adoption-Strategy.md) -- [Cloud-Cost-Optimization](concepts/Cloud-Cost-Optimization.md) -- [Cloud-DevOps-Maturity-Model](concepts/Cloud-DevOps-Maturity-Model.md) -- [Cloud-Governance](concepts/Cloud-Governance.md) -- [Cloud-Maturity-Levels](concepts/Cloud-Maturity-Levels.md) -- [cloud-migration](concepts/cloud-migration.md) -- [Cloud-Monitoring](concepts/Cloud-Monitoring.md) -- [Cloud-Native](concepts/Cloud-Native.md) -- [Cloud-Native-Maturity-Model](concepts/Cloud-Native-Maturity-Model.md) -- [Cloud-Operating-Model](concepts/Cloud-Operating-Model.md) -- [cloud-security](concepts/cloud-security.md) -- [Cloud-Security-Maturity-Model](concepts/Cloud-Security-Maturity-Model.md) -- [Cloud-Service-Delivery](concepts/Cloud-Service-Delivery.md) -- [Cluster-Autoscaler](concepts/Cluster-Autoscaler.md) -- [CMDB](concepts/CMDB.md) -- [Cockpit-Ergonomics](concepts/Cockpit-Ergonomics.md) -- [CodeWeaver](concepts/CodeWeaver.md) -- [Cognitive-Distortions](concepts/Cognitive-Distortions.md) -- [Cognitive-Load-Reduction](concepts/Cognitive-Load-Reduction.md) -- [Columnar-Storage](concepts/Columnar-Storage.md) -- [Compaction](concepts/Compaction.md) -- [Competition-Analysis](concepts/Competition-Analysis.md) -- [Compliance-Automation](concepts/Compliance-Automation.md) -- [Compliance-Risk-Matrix](concepts/Compliance-Risk-Matrix.md) -- [Confidence-Score](concepts/Confidence-Score.md) -- [Configuration-Management](concepts/Configuration-Management.md) -- [Consensus-Voting-Pattern](concepts/Consensus-Voting-Pattern.md) -- [Constraint-Driven-Control-Mechanics](concepts/Constraint-Driven-Control-Mechanics.md) -- [Container-Lifecycle-Hardening](concepts/Container-Lifecycle-Hardening.md) -- [Content Automation](concepts/Content Automation.md) -- [Content-Creator](concepts/Content-Creator.md) -- [Content-Hashing](concepts/Content-Hashing.md) -- [Content-Ingestion](concepts/Content-Ingestion.md) -- [Context-Substrate](concepts/Context-Substrate.md) -- [Context-Window](concepts/Context-Window.md) -- [Continuous-Delivery](concepts/Continuous-Delivery.md) -- [Continuous-Deployment](concepts/Continuous-Deployment.md) -- [Continuous-Integration](concepts/Continuous-Integration.md) -- [Conversational-Interface](concepts/Conversational-Interface.md) -- [Conversions-API](concepts/Conversions-API.md) -- [Cost-Optimization](concepts/Cost-Optimization.md) -- [CoworkWorkspace](concepts/CoworkWorkspace.md) -- [Coze-Workflow](concepts/Coze-Workflow.md) -- [CreativeFatigue](concepts/CreativeFatigue.md) -- [Credential-Isolation](concepts/Credential-Isolation.md) -- [Credit-Efficient-Processing](concepts/Credit-Efficient-Processing.md) -- [Cron定时任务](concepts/Cron定时任务.md) -- [Cross-Account-Monitoring](concepts/Cross-Account-Monitoring.md) -- [Cross-account-Terraform-Modules](concepts/Cross-account-Terraform-Modules.md) -- [Cumulative-Memory](concepts/Cumulative-Memory.md) -- [Custom-Audience-Engineering](concepts/Custom-Audience-Engineering.md) -- [Custom-Instructions](concepts/Custom-Instructions.md) -- [Daily-Digest](concepts/Daily-Digest.md) -- [Daily-Log](concepts/Daily-Log.md) -- [DAST](concepts/DAST.md) -- [Data-Governance](concepts/Data-Governance.md) -- [Data-Sovereignty](concepts/Data-Sovereignty.md) -- [DBA-Role-Evolution](concepts/DBA-Role-Evolution.md) -- [DealHealthScoring](concepts/DealHealthScoring.md) -- [DecisionFramework](concepts/DecisionFramework.md) -- [Default-Bias](concepts/Default-Bias.md) -- [Defense-in-Depth](concepts/Defense-in-Depth.md) -- [Defense-Mechanisms](concepts/Defense-Mechanisms.md) -- [Defuddle](concepts/Defuddle.md) -- [Delegation-Chain](concepts/Delegation-Chain.md) -- [Delivery-Traceability](concepts/Delivery-Traceability.md) -- [Demo-Engineering](concepts/Demo-Engineering.md) -- [Dengbao-2.0](concepts/Dengbao-2.0.md) -- [Dependency-Management](concepts/Dependency-Management.md) -- [Deployment-Automation](concepts/Deployment-Automation.md) -- [Deployment-vs-Release](concepts/Deployment-vs-Release.md) -- [Design-Thinking](concepts/Design-Thinking.md) -- [Design-to-Code-Workflow](concepts/Design-to-Code-Workflow.md) -- [DevOps-Maturity](concepts/DevOps-Maturity.md) -- [DevOpsCulture](concepts/DevOpsCulture.md) -- [DevSecOps](concepts/DevSecOps.md) -- [Discrimination-Metrics](concepts/Discrimination-Metrics.md) -- [DKIM-Email-Authentication](concepts/DKIM-Email-Authentication.md) -- [dm-verity](concepts/dm-verity.md) -- [DNS托管](concepts/DNS托管.md) -- [Docker-Compose](concepts/Docker-Compose.md) -- [Docker-Containerization](concepts/Docker-Containerization.md) -- [Docker-LLM-Deployment](concepts/Docker-LLM-Deployment.md) -- [Docker-用户组](concepts/Docker-用户组.md) -- [Docker堆栈](concepts/Docker堆栈.md) -- [Docker容器生命周期管理](concepts/Docker容器生命周期管理.md) -- [Docker警告处理](concepts/Docker警告处理.md) -- [Domain-Thinking](concepts/Domain-Thinking.md) -- [DORA-Metrics](concepts/DORA-Metrics.md) -- [DRaaS](concepts/DRaaS.md) -- [DRY-Principle](concepts/DRY-Principle.md) -- [DRY原则](concepts/DRY原则.md) -- [DuckDB](concepts/DuckDB.md) -- [Dynamic-Dashboard](concepts/Dynamic-Dashboard.md) -- [Early-Live-Support](concepts/Early-Live-Support.md) -- [Earnings-Beat-Miss](concepts/Earnings-Beat-Miss.md) -- [Earnings-Calendar](concepts/Earnings-Calendar.md) -- [EC2-Purchase-Options](concepts/EC2-Purchase-Options.md) -- [efibootmgr](concepts/efibootmgr.md) -- [EFS-vs-EBS](concepts/EFS-vs-EBS.md) -- [EKS-Auto-Mode](concepts/EKS-Auto-Mode.md) -- [ELK-Stack](concepts/ELK-Stack.md) -- [Email-Triage](concepts/Email-Triage.md) -- [Emergency-Change](concepts/Emergency-Change.md) -- [emptyDir-Volume](concepts/emptyDir-Volume.md) -- [Enterprise-Architecture](concepts/Enterprise-Architecture.md) -- [Environmental-Determinism](concepts/Environmental-Determinism.md) -- [Error-Accountability](concepts/Error-Accountability.md) -- [Error-Budget](concepts/Error-Budget.md) -- [Error-Surface-vs-Root-Cause](concepts/Error-Surface-vs-Root-Cause.md) -- [ESN](concepts/ESN.md) -- [Event-Correlation](concepts/Event-Correlation.md) -- [Event-Driven-Architecture](concepts/Event-Driven-Architecture.md) -- [EventSourcing](concepts/EventSourcing.md) -- [Evidence-based-Merge-Proposal](concepts/Evidence-based-Merge-Proposal.md) -- [Evidence-Chain](concepts/Evidence-Chain.md) -- [Expert-User-Assumption](concepts/Expert-User-Assumption.md) -- [Exporter](concepts/Exporter.md) -- [Extended Thinking](concepts/Extended Thinking.md) -- [external配置](concepts/external配置.md) -- [Fabula-Sjuzhet](concepts/Fabula-Sjuzhet.md) -- [Fail-Closed](concepts/Fail-Closed.md) -- [Failover](concepts/Failover.md) -- [Feature-Flag](concepts/Feature-Flag.md) -- [FeatureList](concepts/FeatureList.md) -- [Federated-Access](concepts/Federated-Access.md) -- [FIA-Framework](concepts/FIA-Framework.md) -- [File-System-First-UI](concepts/File-System-First-UI.md) -- [File-Watcher](concepts/File-Watcher.md) -- [FinOps](concepts/FinOps.md) -- [Fixed-Point-Semantics](concepts/Fixed-Point-Semantics.md) -- [Food-Sensitivity-Tracking](concepts/Food-Sensitivity-Tracking.md) -- [Full-Draft-Generation](concepts/Full-Draft-Generation.md) -- [Full-Funnel-Campaign-Architecture](concepts/Full-Funnel-Campaign-Architecture.md) -- [Fuzzy-Matching](concepts/Fuzzy-Matching.md) -- [Gamification](concepts/Gamification.md) -- [Gatekeeper](concepts/Gatekeeper.md) -- [GDM3](concepts/GDM3.md) -- [Gegenrede](concepts/Gegenrede.md) -- [Generalist](concepts/Generalist.md) -- [Generation](concepts/Generation.md) -- [Generator](concepts/Generator.md) -- [Generator-Space](concepts/Generator-Space.md) -- [Genetic-Algorithm](concepts/Genetic-Algorithm.md) -- [Geographic-Coherence](concepts/Geographic-Coherence.md) -- [GitAsAuditLog](concepts/GitAsAuditLog.md) -- [GitHub-Release-Monitoring](concepts/GitHub-Release-Monitoring.md) -- [Gitmoji-Commit](concepts/Gitmoji-Commit.md) -- [GitOps](concepts/GitOps.md) -- [Global-First-Architecture](concepts/Global-First-Architecture.md) -- [GPG-密钥验证](concepts/GPG-密钥验证.md) -- [Grandes-Ecoles](concepts/Grandes-Ecoles.md) -- [Green-Computing](concepts/Green-Computing.md) -- [Hand-Tracking](concepts/Hand-Tracking.md) -- [Handoff-Contract](concepts/Handoff-Contract.md) -- [HCX](concepts/HCX.md) -- [Headless-服务器](concepts/Headless-服务器.md) -- [Healthcare-Marketing-Compliance](concepts/Healthcare-Marketing-Compliance.md) -- [Heartbeat-Monitoring](concepts/Heartbeat-Monitoring.md) -- [Hidden-Failure-Paths](concepts/Hidden-Failure-Paths.md) -- [Hierarchy-Agent-Pattern](concepts/Hierarchy-Agent-Pattern.md) -- [high-availability](concepts/high-availability.md) -- [Holistic-Admissions](concepts/Holistic-Admissions.md) -- [HookBodyCTA](concepts/HookBodyCTA.md) -- [Hosmer-Lemeshow-Test](concepts/Hosmer-Lemeshow-Test.md) -- [HouseholdInventoryTracking](concepts/HouseholdInventoryTracking.md) -- [HTTPS自动化证书](concepts/HTTPS自动化证书.md) -- [Human-Centered-Design](concepts/Human-Centered-Design.md) -- [Human-Handoff](concepts/Human-Handoff.md) -- [Hybrid-Cloud](concepts/Hybrid-Cloud.md) -- [Hybrid-Search](concepts/Hybrid-Search.md) -- [HybridDnsResolution](concepts/HybridDnsResolution.md) -- [Hyperautomation](concepts/Hyperautomation.md) -- [IANG-Visa](concepts/IANG-Visa.md) -- [IAST](concepts/IAST.md) -- [ICP-Ideal-Customer-Profile](concepts/ICP-Ideal-Customer-Profile.md) -- [Idea-Density](concepts/Idea-Density.md) -- [Idea-Museum](concepts/Idea-Museum.md) -- [Identity-Governance](concepts/Identity-Governance.md) -- [Identity-Resolution](concepts/Identity-Resolution.md) -- [IDENTITY.md](concepts/IDENTITY.md.md) -- [Ikigai框架](concepts/Ikigai框架.md) -- [Immutable-Infrastructure](concepts/Immutable-Infrastructure.md) -- [Immutable-Root-Filesystem](concepts/Immutable-Root-Filesystem.md) -- [Incident-Management](concepts/Incident-Management.md) -- [InclusiveVisuals](concepts/InclusiveVisuals.md) -- [Incremental-Graph-Update](concepts/Incremental-Graph-Update.md) -- [Incrementality-Testing](concepts/Incrementality-Testing.md) -- [Indexing](concepts/Indexing.md) -- [Infrastructure-as-Code](concepts/Infrastructure-as-Code.md) -- [Innovation-Pipeline](concepts/Innovation-Pipeline.md) -- [IntegrationGovernance](concepts/IntegrationGovernance.md) -- [Intent-Classification](concepts/Intent-Classification.md) -- [Intentional-Cloud-Strategy](concepts/Intentional-Cloud-Strategy.md) -- [Inversion](concepts/Inversion.md) -- [Invisible-Exclusion](concepts/Invisible-Exclusion.md) -- [IP纯净度](concepts/IP纯净度.md) -- [ISOHybrid镜像](concepts/ISOHybrid镜像.md) -- [ITSM](concepts/ITSM.md) -- [ITSM-2.0](concepts/ITSM-2.0.md) -- [JFFS双清](concepts/JFFS双清.md) -- [Jira-Gate](concepts/Jira-Gate.md) -- [Jira-Git-Traceability](concepts/Jira-Git-Traceability.md) -- [Kaizen](concepts/Kaizen.md) -- [Kanban](concepts/Kanban.md) -- [Karpman-Drama-Triangle](concepts/Karpman-Drama-Triangle.md) -- [Keyword-Based-Monitoring](concepts/Keyword-Based-Monitoring.md) -- [Kill-Switch](concepts/Kill-Switch.md) -- [Kirkpatrick-四级评估](concepts/Kirkpatrick-四级评估.md) -- [Knock-out-Pattern](concepts/Knock-out-Pattern.md) -- [Knowledge-Base-RAG](concepts/Knowledge-Base-RAG.md) -- [Kolb-体验式学习圈](concepts/Kolb-体验式学习圈.md) -- [Kubernetes](concepts/Kubernetes.md) -- [Land-and-Expand](concepts/Land-and-Expand.md) -- [Landing-Zone-Architecture](concepts/Landing-Zone-Architecture.md) -- [LangChain](concepts/LangChain.md) -- [Language-Detection](concepts/Language-Detection.md) -- [Large-Language-Model](concepts/Large-Language-Model.md) -- [Last-30-Days-Method](concepts/Last-30-Days-Method.md) -- [LaTeX-Flattening](concepts/LaTeX-Flattening.md) -- [launchd](concepts/launchd.md) -- [Layered-Configuration](concepts/Layered-Configuration.md) -- [Lead-Time](concepts/Lead-Time.md) -- [Lean](concepts/Lean.md) -- [Learn-By-Building](concepts/Learn-By-Building.md) -- [Left-over-Principle](concepts/Left-over-Principle.md) -- [Link-Proposer](concepts/Link-Proposer.md) -- [Liquid-Glass-Design-System](concepts/Liquid-Glass-Design-System.md) -- [LLM-Wiki](concepts/LLM-Wiki.md) -- [Local-Caching](concepts/Local-Caching.md) -- [Local-first-Git](concepts/Local-first-Git.md) -- [Local-LLM-Deployment](concepts/Local-LLM-Deployment.md) -- [Lockable-Workflow](concepts/Lockable-Workflow.md) -- [Log-Driven-Debugging](concepts/Log-Driven-Debugging.md) -- [Longue-Duree](concepts/Longue-Duree.md) -- [LSP-317-Specification](concepts/LSP-317-Specification.md) -- [Luhmann-四原则](concepts/Luhmann-四原则.md) -- [Mackinder-Heartland-Theory](concepts/Mackinder-Heartland-Theory.md) -- [Management-Pack](concepts/Management-Pack.md) -- [MCPOnceAllAgents](concepts/MCPOnceAllAgents.md) -- [MEDDPICC](concepts/MEDDPICC.md) -- [Medical-Advertisement-Review](concepts/Medical-Advertisement-Review.md) -- [MeetingNotes](concepts/MeetingNotes.md) -- [Memory-Backend](concepts/Memory-Backend.md) -- [MEMORY.md](concepts/MEMORY.md.md) -- [MessageMatch](concepts/MessageMatch.md) -- [Micro-Recovery](concepts/Micro-Recovery.md) -- [Miping](concepts/Miping.md) -- [Model-Context-Protocol](concepts/Model-Context-Protocol.md) -- [Model-Fallback](concepts/Model-Fallback.md) -- [Momentum-Nudge](concepts/Momentum-Nudge.md) -- [Morning-Briefing](concepts/Morning-Briefing.md) -- [Motion-Sickness-Threshold](concepts/Motion-Sickness-Threshold.md) -- [MPP](concepts/MPP.md) -- [MTTA](concepts/MTTA.md) -- [MTTD](concepts/MTTD.md) -- [MTTR](concepts/MTTR.md) -- [Multi-Account-Deployment](concepts/Multi-Account-Deployment.md) -- [Multi-AgentHub](concepts/Multi-AgentHub.md) -- [Multi-AI-Review](concepts/Multi-AI-Review.md) -- [Multi-Channel-Delivery](concepts/Multi-Channel-Delivery.md) -- [Multi-Channel-Sequence-Architecture](concepts/Multi-Channel-Sequence-Architecture.md) -- [Multi-Cloud-Strategy](concepts/Multi-Cloud-Strategy.md) -- [Multi-Database-Architecture](concepts/Multi-Database-Architecture.md) -- [Multi-factor-Authentication](concepts/Multi-factor-Authentication.md) -- [Multi-Tenancy](concepts/Multi-Tenancy.md) -- [Multi-Window-Architecture](concepts/Multi-Window-Architecture.md) -- [N8nWorkflowStandard](concepts/N8nWorkflowStandard.md) -- [Narrative-Debt](concepts/Narrative-Debt.md) -- [nas套件管理](concepts/nas套件管理.md) -- [National-Annex](concepts/National-Annex.md) -- [NegativePromptingLibrary](concepts/NegativePromptingLibrary.md) -- [Net-Revenue-Retention](concepts/Net-Revenue-Retention.md) -- [NFS网络备份](concepts/NFS网络备份.md) -- [Nitro-System](concepts/Nitro-System.md) -- [Normal-Change](concepts/Normal-Change.md) -- [Nunchi](concepts/Nunchi.md) -- [NVMe硬盘分区](concepts/NVMe硬盘分区.md) -- [Observable-States](concepts/Observable-States.md) -- [Obsidian-Agent-Client](concepts/Obsidian-Agent-Client.md) -- [Obsidian-Bases](concepts/Obsidian-Bases.md) -- [Obsidian-CLI](concepts/Obsidian-CLI.md) -- [Obsidian-Tasks](concepts/Obsidian-Tasks.md) -- [OpenTelemetry](concepts/OpenTelemetry.md) -- [Oracle-Manipulation](concepts/Oracle-Manipulation.md) -- [OWASP-Top-Ten](concepts/OWASP-Top-Ten.md) -- [Pain-Point-Mining](concepts/Pain-Point-Mining.md) -- [Paper-Abstract-Batch-Fetching](concepts/Paper-Abstract-Batch-Fetching.md) -- [Parallel-Agent-Execution](concepts/Parallel-Agent-Execution.md) -- [Partial-Dependence-Plots](concepts/Partial-Dependence-Plots.md) -- [Partition-Updates](concepts/Partition-Updates.md) -- [Passive-Learning](concepts/Passive-Learning.md) -- [passkey](concepts/passkey.md) -- [Patient-Privacy-PIPL](concepts/Patient-Privacy-PIPL.md) -- [Pay-as-you-go](concepts/Pay-as-you-go.md) -- [Peer-Verification](concepts/Peer-Verification.md) -- [Penetration-Testing](concepts/Penetration-Testing.md) -- [Performance-Contracts](concepts/Performance-Contracts.md) -- [PerformanceMax](concepts/PerformanceMax.md) -- [Personal-CRM](concepts/Personal-CRM.md) -- [Personalization](concepts/Personalization.md) -- [PersuasionArchitecture](concepts/PersuasionArchitecture.md) -- [Pipeline](concepts/Pipeline.md) -- [PipelineVelocity](concepts/PipelineVelocity.md) -- [Pivot-Strategy](concepts/Pivot-Strategy.md) -- [Plan-Mode](concepts/Plan-Mode.md) -- [PMDelegationPattern](concepts/PMDelegationPattern.md) -- [pmset](concepts/pmset.md) -- [POC-Scoping](concepts/POC-Scoping.md) -- [Pod-Security-Context](concepts/Pod-Security-Context.md) -- [Policy-as-Code](concepts/Policy-as-Code.md) -- [Pomodoro-Technique](concepts/Pomodoro-Technique.md) -- [Population-Stability-Index](concepts/Population-Stability-Index.md) -- [Portage-Salarial](concepts/Portage-Salarial.md) -- [Portfolio-ROI](concepts/Portfolio-ROI.md) -- [PRD生成工作流](concepts/PRD生成工作流.md) -- [Pre-Build-Validation](concepts/Pre-Build-Validation.md) -- [Predictive-Maintenance](concepts/Predictive-Maintenance.md) -- [Private-Cloud](concepts/Private-Cloud.md) -- [Private-Context](concepts/Private-Context.md) -- [Proactive-Agent-Recommendation](concepts/Proactive-Agent-Recommendation.md) -- [Proactive-AI](concepts/Proactive-AI.md) -- [Problem-Management](concepts/Problem-Management.md) -- [process-management](concepts/process-management.md) -- [Progressive-Rollout](concepts/Progressive-Rollout.md) -- [ProjectState](concepts/ProjectState.md) -- [Prometheus告警规则](concepts/Prometheus告警规则.md) -- [PromQL](concepts/PromQL.md) -- [Propp-Morphology](concepts/Propp-Morphology.md) -- [proxychains](concepts/proxychains.md) -- [Public-Cloud](concepts/Public-Cloud.md) -- [PUID-PGID](concepts/PUID-PGID.md) -- [Pull-Request-Governance](concepts/Pull-Request-Governance.md) -- [Purpose-Built-Databases](concepts/Purpose-Built-Databases.md) -- [Quality-Scoring-Algorithm](concepts/Quality-Scoring-Algorithm.md) -- [QualityAdjustedCoverage](concepts/QualityAdjustedCoverage.md) -- [RAG](concepts/RAG.md) -- [Reality-Signal](concepts/Reality-Signal.md) -- [RealityKit-SwiftUI-Integration](concepts/RealityKit-SwiftUI-Integration.md) -- [ReAuditTriggers](concepts/ReAuditTriggers.md) -- [Reciprocal-Rank-Fusion](concepts/Reciprocal-Rank-Fusion.md) -- [RecruitmentFunnelAnalyzer](concepts/RecruitmentFunnelAnalyzer.md) -- [Recurring-Task](concepts/Recurring-Task.md) -- [Recurring-Tasks](concepts/Recurring-Tasks.md) -- [Recursive-Self-Optimization](concepts/Recursive-Self-Optimization.md) -- [Redis缓存](concepts/Redis缓存.md) -- [Reentrancy](concepts/Reentrancy.md) -- [Reference-Architecture](concepts/Reference-Architecture.md) -- [Release-Management](concepts/Release-Management.md) -- [Reliability-Engineering](concepts/Reliability-Engineering.md) -- [ReliabilityBaseline](concepts/ReliabilityBaseline.md) -- [Remote-SSH](concepts/Remote-SSH.md) -- [RemoteDevelopment](concepts/RemoteDevelopment.md) -- [RemoteRescuePattern](concepts/RemoteRescuePattern.md) -- [Renovate-Bot](concepts/Renovate-Bot.md) -- [Resource-Allocation](concepts/Resource-Allocation.md) -- [ResponsiveSearchAds](concepts/ResponsiveSearchAds.md) -- [Retrieval](concepts/Retrieval.md) -- [Reviewer](concepts/Reviewer.md) -- [Rightsizing](concepts/Rightsizing.md) -- [Risk-Mitigation](concepts/Risk-Mitigation.md) -- [ROI](concepts/ROI.md) -- [Rollback-Rate](concepts/Rollback-Rate.md) -- [Root-Cause-Analysis](concepts/Root-Cause-Analysis.md) -- [RPO](concepts/RPO.md) -- [RSS-Aggregation](concepts/RSS-Aggregation.md) -- [RTO](concepts/RTO.md) -- [S3-兼容对象存储](concepts/S3-兼容对象存储.md) -- [Safeguard-Steps](concepts/Safeguard-Steps.md) -- [Sandboxed-Persona](concepts/Sandboxed-Persona.md) -- [SAST](concepts/SAST.md) -- [Savings-Plans](concepts/Savings-Plans.md) -- [SCA](concepts/SCA.md) -- [Scalability](concepts/Scalability.md) -- [Scheduled-Reminder](concepts/Scheduled-Reminder.md) -- [Scheduled-Task-Flywheel](concepts/Scheduled-Task-Flywheel.md) -- [Scholar-Skill](concepts/Scholar-Skill.md) -- [Scrum](concepts/Scrum.md) -- [SDDC](concepts/SDDC.md) -- [SE-Linux-Enforcing](concepts/SE-Linux-Enforcing.md) -- [Second-Renaissance](concepts/Second-Renaissance.md) -- [Secrets-Management](concepts/Secrets-Management.md) -- [Security-and-Compliance](concepts/Security-and-Compliance.md) -- [Self-Education](concepts/Self-Education.md) -- [Self-Healing-Systems](concepts/Self-Healing-Systems.md) -- [self-hosted-password-manager](concepts/self-hosted-password-manager.md) -- [Self-Improving-Skill](concepts/Self-Improving-Skill.md) -- [Self-Interest](concepts/Self-Interest.md) -- [Self-Referential-Computation](concepts/Self-Referential-Computation.md) -- [Self-Sufficiency](concepts/Self-Sufficiency.md) -- [Semantic-Deduplication](concepts/Semantic-Deduplication.md) -- [Semantic-Index-Infrastructure](concepts/Semantic-Index-Infrastructure.md) -- [Semantic-Search](concepts/Semantic-Search.md) -- [Semantic-Versioning](concepts/Semantic-Versioning.md) -- [Sequential-Thinking](concepts/Sequential-Thinking.md) -- [Serverless-Computing](concepts/Serverless-Computing.md) -- [Service-Control-Policies-SCPs](concepts/Service-Control-Policies-SCPs.md) -- [SES-Sandbox-Mode](concepts/SES-Sandbox-Mode.md) -- [SHAP](concepts/SHAP.md) -- [Shared-Memory-Architecture](concepts/Shared-Memory-Architecture.md) -- [Shared-Responsibility-Model](concepts/Shared-Responsibility-Model.md) -- [SharedStateCoordination](concepts/SharedStateCoordination.md) -- [Shift-Left-Security](concepts/Shift-Left-Security.md) -- [Shift-Right-Security](concepts/Shift-Right-Security.md) -- [Signal-Based-Selling-Framework](concepts/Signal-Based-Selling-Framework.md) -- [Single-Control-Plane](concepts/Single-Control-Plane.md) -- [Six-Sigma](concepts/Six-Sigma.md) -- [SKAdNetwork](concepts/SKAdNetwork.md) -- [SLS](concepts/SLS.md) -- [SmartBidding](concepts/SmartBidding.md) -- [SnapMirror](concepts/SnapMirror.md) -- [Social-Media-Monitoring](concepts/Social-Media-Monitoring.md) -- [Socket-登录](concepts/Socket-登录.md) -- [SOCKS5代理](concepts/SOCKS5代理.md) -- [Software-Assurance-Maturity-Model](concepts/Software-Assurance-Maturity-Model.md) -- [Solution-Architecture](concepts/Solution-Architecture.md) -- [SOUL.md](concepts/SOUL.md.md) -- [Source-Grounding](concepts/Source-Grounding.md) -- [Spatial-Computing](concepts/Spatial-Computing.md) -- [Spatial-Widgets](concepts/Spatial-Widgets.md) -- [Split](concepts/Split.md) -- [Spot-Instances](concepts/Spot-Instances.md) -- [SprintPlanning](concepts/SprintPlanning.md) -- [SSE-Server-Sent-Events](concepts/SSE-Server-Sent-Events.md) -- [StackSets-Deployment-Visibility](concepts/StackSets-Deployment-Visibility.md) -- [Stakeholder-Alignment](concepts/Stakeholder-Alignment.md) -- [Standard-Change](concepts/Standard-Change.md) -- [STARFramework](concepts/STARFramework.md) -- [Startup-MVP-Pipeline](concepts/Startup-MVP-Pipeline.md) -- [Statistical-Process-Control](concepts/Statistical-Process-Control.md) -- [Strategic-Portfolio-Management](concepts/Strategic-Portfolio-Management.md) -- [Streak-Tracking](concepts/Streak-Tracking.md) -- [Stretched-Cluster](concepts/Stretched-Cluster.md) -- [StructuredInterview](concepts/StructuredInterview.md) -- [StudyVault](concepts/StudyVault.md) -- [Sub-Agent-Race-Condition](concepts/Sub-Agent-Race-Condition.md) -- [SwiftUI-Volumetric-APIs](concepts/SwiftUI-Volumetric-APIs.md) -- [symbolic-link](concepts/symbolic-link.md) -- [System-Economy](concepts/System-Economy.md) -- [system-monitoring](concepts/system-monitoring.md) -- [systemd](concepts/systemd.md) -- [Tag-Validation-Tool](concepts/Tag-Validation-Tool.md) -- [Task-Query](concepts/Task-Query.md) -- [TaskAutomation](concepts/TaskAutomation.md) -- [Taylorism](concepts/Taylorism.md) -- [TCP隧道](concepts/TCP隧道.md) -- [Technical-Architecture](concepts/Technical-Architecture.md) -- [Technical-Objection-Handling](concepts/Technical-Objection-Handling.md) -- [Telegram-Trigger](concepts/Telegram-Trigger.md) -- [Telephony-Integration](concepts/Telephony-Integration.md) -- [Terraform-Modules](concepts/Terraform-Modules.md) -- [Test-Mode](concepts/Test-Mode.md) -- [Text-and-Search](concepts/Text-and-Search.md) -- [Threat-Modeling](concepts/Threat-Modeling.md) -- [Three-Tier-Review-Mechanism](concepts/Three-Tier-Review-Mechanism.md) -- [ThreeActProposalNarrative](concepts/ThreeActProposalNarrative.md) -- [TieredCampaignArchitecture](concepts/TieredCampaignArchitecture.md) -- [Time-to-Market](concepts/Time-to-Market.md) -- [Todoist-API](concepts/Todoist-API.md) -- [Token-Light-Design](concepts/Token-Light-Design.md) -- [Tool-Calling](concepts/Tool-Calling.md) -- [TOOLS.md](concepts/TOOLS.md.md) -- [ToolWrapper](concepts/ToolWrapper.md) -- [Topic-Based-Routing](concepts/Topic-Based-Routing.md) -- [totp](concepts/totp.md) -- [Transactional-Analysis](concepts/Transactional-Analysis.md) -- [Transcript-Based-Summarization](concepts/Transcript-Based-Summarization.md) -- [TranscriptProcessing](concepts/TranscriptProcessing.md) -- [Trauma-Informed-Analysis](concepts/Trauma-Informed-Analysis.md) -- [Tree-of-Thoughts](concepts/Tree-of-Thoughts.md) -- [Trust-Scoring](concepts/Trust-Scoring.md) -- [tui](concepts/tui.md) -- [Tutor-Skills](concepts/Tutor-Skills.md) -- [Two-Way-Voice-Conversation](concepts/Two-Way-Voice-Conversation.md) -- [UCAS-System](concepts/UCAS-System.md) -- [UEFI-Only](concepts/UEFI-Only.md) -- [UEFI启动](concepts/UEFI启动.md) -- [ULS](concepts/ULS.md) -- [Unified-Inbox](concepts/Unified-Inbox.md) -- [USER.md](concepts/USER.md.md) -- [Value-Stream-Mapping](concepts/Value-Stream-Mapping.md) -- [Variables-YAML](concepts/Variables-YAML.md) -- [Vector-Embedding](concepts/Vector-Embedding.md) -- [Vendor-Lock-In](concepts/Vendor-Lock-In.md) -- [Vibe-Coding](concepts/Vibe-Coding.md) -- [Visual-Debugging](concepts/Visual-Debugging.md) -- [vLLM](concepts/vLLM.md) -- [VMware-Cloud-on-AWS](concepts/VMware-Cloud-on-AWS.md) -- [Voice-Interface](concepts/Voice-Interface.md) -- [Voice-Notification-Channel](concepts/Voice-Notification-Channel.md) -- [VPC-Endpoint](concepts/VPC-Endpoint.md) -- [Vulnerability-Scanning](concepts/Vulnerability-Scanning.md) -- [Wake-on-LAN](concepts/Wake-on-LAN.md) -- [Wayland](concepts/Wayland.md) -- [Web-Search-Aggregation](concepts/Web-Search-Aggregation.md) -- [Webhook](concepts/Webhook.md) -- [Webhook-Proxy-Pattern](concepts/Webhook-Proxy-Pattern.md) -- [WEBHOOK_URL](concepts/WEBHOOK_URL.md) -- [WebXR](concepts/WebXR.md) -- [Weekly-Pattern-Analysis](concepts/Weekly-Pattern-Analysis.md) -- [What-If-Simulation](concepts/What-If-Simulation.md) -- [WinThemes](concepts/WinThemes.md) -- [Workflow-Engineering](concepts/Workflow-Engineering.md) -- [Workflow-Registry](concepts/Workflow-Registry.md) -- [Workflow-Tree-Spec](concepts/Workflow-Tree-Spec.md) -- [Workspace](concepts/Workspace.md) -- [X11](concepts/X11.md) -- [Xinchuang](concepts/Xinchuang.md) -- [Y-Combinator](concepts/Y-Combinator.md) -- [Zero-Friction-Capture](concepts/Zero-Friction-Capture.md) -- [Zero-Trust](concepts/Zero-Trust.md) -- [Zero-Trust-Architecture](concepts/Zero-Trust-Architecture.md) -- [Zettelkasten](concepts/Zettelkasten.md) -- [一人公司](concepts/一人公司.md) -- [上下文刷新](concepts/上下文刷新.md) -- [上下文压缩](concepts/上下文压缩.md) -- [个人品牌](concepts/个人品牌.md) -- [九宫格法](concepts/九宫格法.md) -- [云盘挂载](concepts/云盘挂载.md) -- [交接协议](concepts/交接协议.md) -- [产品四层级体系](concepts/产品四层级体系.md) -- [价格锚定与诱饵效应](concepts/价格锚定与诱饵效应.md) -- [全盘镜像备份](concepts/全盘镜像备份.md) -- [内容矩阵](concepts/内容矩阵.md) -- [内网穿透](concepts/内网穿透.md) -- [写入纪律](concepts/写入纪律.md) -- [单一职责原则](concepts/单一职责原则.md) -- [反向代理](concepts/反向代理.md) -- [合成监控](concepts/合成监控.md) -- [启动序列](concepts/启动序列.md) -- [四个心理陷阱](concepts/四个心理陷阱.md) -- [固件刷入](concepts/固件刷入.md) -- [固定机位](concepts/固定机位.md) -- [图床](concepts/图床.md) -- [增量备份](concepts/增量备份.md) -- [天才地带](concepts/天才地带.md) -- [容器资源限制](concepts/容器资源限制.md) -- [容器重启策略](concepts/容器重启策略.md) -- [工作流自动化](concepts/工作流自动化.md) -- [并发编程](concepts/并发编程.md) -- [底层能力](concepts/底层能力.md) -- [微服务架构](concepts/微服务架构.md) -- [思维蒸馏（女娲造人术）](concepts/思维蒸馏（女娲造人术）.md) -- [技术图生成](concepts/技术图生成.md) -- [挂载点检查](concepts/挂载点检查.md) -- [指纹浏览器](concepts/指纹浏览器.md) -- [接码平台](concepts/接码平台.md) -- [播客生成](concepts/播客生成.md) -- [故障转移](concepts/故障转移.md) -- [数字导师](concepts/数字导师.md) -- [数据可视化](concepts/数据可视化.md) -- [文档问答](concepts/文档问答.md) -- [时序数据库](concepts/时序数据库.md) -- [本地化部署](concepts/本地化部署.md) -- [桥接网络](concepts/桥接网络.md) -- [模块化编程](concepts/模块化编程.md) -- [每日复盘机制](concepts/每日复盘机制.md) -- [永久挂载](concepts/永久挂载.md) -- [消息队列](concepts/消息队列.md) -- [混合搜索](concepts/混合搜索.md) -- [版本控制](concepts/版本控制.md) -- [用户权限](concepts/用户权限.md) -- [硬件转码](concepts/硬件转码.md) -- [端口映射](concepts/端口映射.md) -- [策略组分流](concepts/策略组分流.md) -- [系统睡眠管理](concepts/系统睡眠管理.md) -- [虚拟信用卡](concepts/虚拟信用卡.md) -- [裸机恢复](concepts/裸机恢复.md) -- [订阅机制](concepts/订阅机制.md) -- [设备直通](concepts/设备直通.md) -- [语义形状词汇表](concepts/语义形状词汇表.md) -- [语义搜索](concepts/语义搜索.md) -- [语义箭头系统](concepts/语义箭头系统.md) -- [账号隔离](concepts/账号隔离.md) -- [超级个体](concepts/超级个体.md) -- [跨境支付](concepts/跨境支付.md) -- [软链接策略](concepts/软链接策略.md) -- [输入-处理-输出模型](concepts/输入-处理-输出模型.md) -- [过渡固件](concepts/过渡固件.md) -- [进程管理](concepts/进程管理.md) -- [逻辑备份](concepts/逻辑备份.md) -- [销售漏斗](concepts/销售漏斗.md) -- [首尾针动画](concepts/首尾针动画.md) -- [품의](concepts/품의.md) - -## Syntheses +# Wiki Index + +## Overview +- [Overview](overview.md) — living synthesis + +## Sources +- [2026-04-26] [Autonomous Optimization Architect](sources/engineering-autonomous-optimization-architect.md) +- [2026-04-26] [Mobile App Builder Agent Personality](sources/engineering-mobile-app-builder.md) +- [2026-04-26] [Software Architect Agent Personality](sources/engineering-software-architect.md) +- [2026-04-26] [Godot Multiplayer Engineer Agent Personality](sources/godot-multiplayer-engineer.md) +- [2026-04-26] [Godot Shader Developer Agent Personality](sources/godot-shader-developer.md) +- [2026-04-26] [Godot Gameplay Scripter Agent Personality](sources/godot-gameplay-scripter.md) +- [2026-04-26] [Blender Add-on Engineer Agent Personality](sources/blender-addon-engineer.md) +- [2026-04-26] [Roblox Avatar Creator Agent Personality](sources/roblox-avatar-creator.md) +- [2026-04-26] [Roblox Systems Scripter Agent Personality](sources/roblox-systems-scripter.md) +- [2026-04-26] [Roblox Experience Designer](sources/roblox-experience-designer.md) +- [2026-04-26] [Unity Architect](sources/unity-architect.md) +- [2026-04-26] [Unity Multiplayer Engineer](sources/unity-multiplayer-engineer.md) +- [2026-04-26] [Unity Shader Graph Artist](sources/unity-shader-graph-artist.md) +- [2026-04-26] [Unity Editor Tool Developer](sources/unity-editor-tool-developer.md) +- [2026-04-26] [Unreal World Builder Agent Personality](sources/unreal-world-builder.md) +- [2026-04-26] [Unreal Systems Engineer](sources/unreal-systems-engineer.md) +- [2026-04-26] [Unreal Multiplayer Architect](sources/unreal-multiplayer-architect.md) +- [2026-04-26] [Unreal Technical Artist](sources/unreal-technical-artist.md) +- [2026-04-26] [Game Designer Agent Personality](sources/game-designer.md) +- [2026-04-25] [Narrative Designer Agent Personality](sources/narrative-designer.md) +- [2026-04-25] [Level Designer Agent Personality](sources/level-designer.md) +- [2026-04-25] [Technical Artist](sources/technical-artist.md) +- [2026-04-25] [Game Audio Engineer Agent](sources/game-audio-engineer.md) +- [2026-04-25] [AI Citation Strategist](sources/marketing-ai-citation-strategist.md) +- [2026-04-25] [Marketing Growth Hacker Agent](sources/marketing-growth-hacker.md) +- [2026-04-25] [Marketing Xiaohongshu Specialist](sources/marketing-xiaohongshu-specialist.md) +- [2026-04-25] [Marketing Podcast Strategist](sources/marketing-podcast-strategist.md) +- [2026-04-25] [Marketing Bilibili Content Strategist](sources/marketing-bilibili-content-strategist.md) +- [2026-04-25] [Marketing Content Creator](sources/marketing-content-creator.md) +- [2026-04-25] [Marketing Twitter Engager](sources/marketing-twitter-engager.md) +- [2026-04-25] [Marketing Livestream Commerce Coach](sources/marketing-livestream-commerce-coach.md) +- [2026-04-25] [Marketing TikTok Strategist](sources/marketing-tiktok-strategist.md) +- [2026-04-25] [Marketing SEO Specialist](sources/marketing-seo-specialist.md) +- [2026-04-25] [China Market Localization Strategist](sources/marketing-china-market-localization-strategist.md) +- [2026-04-25] [App Store Optimizer](sources/marketing-app-store-optimizer.md) +- [2026-04-25] [Marketing WeChat Official Account Manager](sources/marketing-wechat-official-account.md) +- [2026-04-25] [LinkedIn Content Creator](sources/marketing-linkedin-content-creator.md) +- [2026-04-25] [Marketing Weibo Strategist](sources/marketing-weibo-strategist.md) +- [2026-04-25] [Marketing Baidu SEO Specialist](sources/marketing-baidu-seo-specialist.md) +- [2026-04-25] [Marketing Carousel Growth Engine](sources/marketing-carousel-growth-engine.md) +- [2026-04-25] [Marketing Private Domain Operator](sources/marketing-private-domain-operator.md) +- [2026-04-25] [Marketing Short-Video Editing Coach](sources/marketing-short-video-editing-coach.md) +- [2026-04-25] [Social Media Strategist](sources/marketing-social-media-strategist.md) +- [2026-04-25] [Marketing Kuaishou Strategist](sources/marketing-kuaishou-strategist.md) +- [2026-04-25] [Marketing Video Optimization Specialist](sources/marketing-video-optimization-specialist.md) +- [2026-04-25] [Marketing Instagram Curator](sources/marketing-instagram-curator.md) +- [2026-04-25] [Marketing China E-Commerce Operator](sources/marketing-china-ecommerce-operator.md) +- [2026-04-25] [Marketing Reddit Community Builder](sources/marketing-reddit-community-builder.md) +- [2026-04-25] [Marketing Cross-Border E-Commerce Specialist](sources/marketing-cross-border-ecommerce.md) +- [2026-04-25] [Book Co-Author](sources/marketing-book-co-author.md) +- [2026-04-25] [Marketing Zhihu Strategist](sources/marketing-zhihu-strategist.md) +- [2026-04-25] [Marketing Douyin Strategist](sources/marketing-douyin-strategist.md) +- [2026-04-25] [Nexus Spatial: Full Agency Discovery Exercise](sources/nexus-spatial-discovery.md) +- [2026-04-25] [Multi-Agent Workflow: Startup MVP with Persistent Memory](sources/workflow-with-memory.md) +- [2026-04-25] [Multi-Agent Workflow: Landing Page Sprint](sources/workflow-landing-page.md) +- [2026-04-25] [Multi-Agent Workflow: Startup MVP](sources/workflow-startup-mvp.md) +- [2026-04-25] [Examples - Agency Multi-Agent Collaboration Showcase](sources/readme.md) +- [2026-04-25] [Workflow Example: Book Chapter Development](sources/workflow-book-chapter.md) +- [2026-04-25] [Executive Summary Generator Agent Personality](sources/support-executive-summary-generator.md) +- [2026-04-25] [Finance Tracker Agent Personality](sources/support-finance-tracker.md) +- [2026-04-25] [Support Infrastructure Maintainer Agent Personality](sources/support-infrastructure-maintainer.md) +- [2026-04-25] [Support Responder Agent Personality](sources/support-support-responder.md) +- [2026-04-25] [Analytics Reporter Agent Personality](sources/support-analytics-reporter.md) +- [2026-04-25] [Support Legal Compliance Checker Agent Personality](sources/support-legal-compliance-checker.md) +- [2026-04-25] [Accessibility Auditor Agent Personality](sources/testing-accessibility-auditor.md) +- [2026-04-25] [Tool Evaluator Agent Personality](sources/testing-tool-evaluator.md) +- [2026-04-25] [Testing Evidence Collector Agent Personality](sources/testing-evidence-collector.md) +- [2026-04-25] [Test Results Analyzer Agent Personality](sources/testing-test-results-analyzer.md) +- [2026-04-25] [Performance Benchmarker Agent Personality](sources/testing-performance-benchmarker.md) +- [2026-04-25] [Testing Reality Checker](sources/testing-reality-checker.md) +- [2026-04-25] [Workflow Optimizer Agent Personality](sources/testing-workflow-optimizer.md) +- [2026-04-25] [API Tester Agent Personality](sources/testing-api-tester.md) +- [2026-04-25] [Examples - Agency Multi-Agent Collaboration Showcase](sources/readme.md) +- [2026-04-25] [Examples - Agency Multi-Agent Collaboration Showcase](sources/readme.md) +- [2026-04-25] [Examples - Agency Multi-Agent Collaboration Showcase](sources/readme.md) +- [2026-04-25] [Examples - Agency Multi-Agent Collaboration Showcase](sources/readme.md) +- [2026-04-25] [Examples - Agency Multi-Agent Collaboration Showcase](sources/readme.md) +- [2026-04-25] [Examples - Agency Multi-Agent Collaboration Showcase](sources/readme.md) +- [2026-04-25] [Examples - Agency Multi-Agent Collaboration Showcase](sources/readme.md) +- [2026-04-25] [Examples - Agency Multi-Agent Collaboration Showcase](sources/readme.md) +- [2026-04-25] [Backend Architect with Memory](sources/backend-architect-with-memory.md) +- [2026-04-25] [Examples - Agency Multi-Agent Collaboration Showcase](sources/readme.md) +- [2026-04-25] [Examples - Agency Multi-Agent Collaboration Showcase](sources/readme.md) +- [2026-04-25] [Examples - Agency Multi-Agent Collaboration Showcase](sources/readme.md) +- [2026-04-25] [Examples - Agency Multi-Agent Collaboration Showcase](sources/readme.md) +- [2026-04-25] [Historian Agent Personality](sources/academic-historian.md) +- [2026-04-25] [Academic Geographer](sources/academic-geographer.md) +- [2026-04-25] [Academic Narratologist](sources/academic-narratologist.md) +- [2026-04-25] [Academic Anthropologist](sources/academic-anthropologist.md) +- [2026-04-25] [Academic Psychologist](sources/academic-psychologist.md) +- [2026-04-25] [Behavioral Nudge Engine](sources/product-behavioral-nudge-engine.md) +- [2026-04-25] [Product Sprint Prioritizer Agent](sources/product-sprint-prioritizer.md) +- [2026-04-25] [Product Trend Researcher Agent](sources/product-trend-researcher.md) +- [2026-04-25] [Product Manager Agent](sources/product-manager.md) +- [2026-04-25] [Product Feedback Synthesizer Agent](sources/product-feedback-synthesizer.md) +- [2026-04-25] [Specialized Developer Advocate](sources/specialized-developer-advocate.md) +- [2026-04-25] [Automation Governance Architect](sources/automation-governance-architect.md) +- [2026-04-25] [Report Distribution Agent](sources/report-distribution-agent.md) +- [2026-04-25] [Data Consolidation Agent](sources/data-consolidation-agent.md) +- [2026-04-25] [Supply Chain Strategist Agent](sources/supply-chain-strategist.md) +- [2026-04-25] [ZK Steward Agent](sources/zk-steward.md) +- [2026-04-25] [Korean Business Navigator](sources/specialized-korean-business-navigator.md) +- [2026-04-25] [French Consulting Market Navigator](sources/specialized-french-consulting-market.md) +- [2026-04-25] [Blockchain Security Auditor](sources/blockchain-security-auditor.md) +- [2026-04-25] [Sales Data Extraction Agent](sources/sales-data-extraction-agent.md) +- [2026-04-25] [Study Abroad Advisor](sources/study-abroad-advisor.md) +- [2026-04-25] [Agents Orchestrator](sources/agents-orchestrator.md) +- [2026-04-25] [MCP Builder Agent](sources/specialized-mcp-builder.md) +- [2026-04-25] [Compliance Auditor Agent](sources/compliance-auditor.md) +- [2026-04-25] [Specialized Salesforce Architect](sources/specialized-salesforce-architect.md) +- [2026-04-25] [LSP/Index Engineer Agent Personality](sources/lsp-index-engineer.md) +- [2026-04-25] [Model QA Specialist](sources/specialized-model-qa.md) +- [2026-04-25] [Corporate Training Designer](sources/corporate-training-designer.md) +- [2026-04-25] [Cultural Intelligence Strategist](sources/specialized-cultural-intelligence-strategist.md) +- [2026-04-25] [Healthcare Marketing Compliance Specialist](sources/healthcare-marketing-compliance.md) +- [2026-04-24] [Workflow Architect Agent Personality](sources/specialized-workflow-architect.md) +- [2026-04-24] [Government Digital Presales Consultant](sources/government-digital-presales-consultant.md) +- [2026-04-24] [Agentic Identity & Trust Architect](sources/agentic-identity-trust.md) +- [2026-04-24] [Document Generator Agent](sources/specialized-document-generator.md) +- [2026-04-24] [Identity Graph Operator](sources/identity-graph-operator.md) +- [2026-04-24] [Accounts Payable Agent Personality](sources/accounts-payable-agent.md) +- [2026-04-24] [Recruitment Specialist Agent](sources/recruitment-specialist.md) +- [2026-04-24] [Specialized Civil Engineer Agent](sources/specialized-civil-engineer.md) +- [2026-04-24] [Experiment Tracker Agent Personality](sources/project-management-experiment-tracker.md) +- [2026-04-24] [Studio Operations Agent Personality](sources/project-management-studio-operations.md) +- [2026-04-24] [Senior Project Manager Agent Personality](sources/project-manager-senior.md) +- [2026-04-24] [Jira Workflow Steward Agent Personality](sources/project-management-jira-workflow-steward.md) +- [2026-04-24] [Project Shepherd Agent Personality](sources/project-management-project-shepherd.md) +- [2026-04-24] [Studio Producer Agent Personality](sources/project-management-studio-producer.md) +- [2026-04-24] [visionOS Spatial Engineer](sources/visionos-spatial-engineer.md) +- [2026-04-24] [XR Interface Architect Agent Personality](sources/xr-interface-architect.md) +- [2026-04-24] [macOS Spatial/Metal Engineer Agent Personality](sources/macos-spatial-metal-engineer.md) +- [2026-04-24] [Terminal Integration Specialist](sources/terminal-integration-specialist.md) +- [2026-04-24] [XR Immersive Developer Agent Personality](sources/xr-immersive-developer.md) +- [2026-04-24] [XR Cockpit Interaction Specialist Agent](sources/xr-cockpit-interaction-specialist.md) +- [2026-04-24] [Sales Engineer Agent](sources/sales-engineer.md) +- [2026-04-24] [Pipeline Analyst Agent](sources/sales-pipeline-analyst.md) +- [2026-04-24] [Outbound Strategist Agent](sources/sales-outbound-strategist.md) +- [2026-04-24] [Deal Strategist Agent](sources/sales-deal-strategist.md) +- [2026-04-24] [Account Strategist Agent](sources/sales-account-strategist.md) +- [2026-04-24] [Sales Proposal Strategist](sources/sales-proposal-strategist.md) +- [2026-04-24] [Sales Coach Agent](sources/sales-coach.md) +- [2026-04-24] [Discovery Coach Agent](sources/sales-discovery-coach.md) +- [2026-04-24] [Paid Media Tracking & Measurement Specialist Agent](sources/paid-media-tracking-specialist.md) +- [2026-04-24] [Paid Media Ad Creative Strategist Agent](sources/paid-media-creative-strategist.md) +- [2026-04-24] [Paid Social Strategist](sources/paid-media-paid-social-strategist.md) +- [2026-04-24] [Paid Media Search Query Analyst Agent](sources/paid-media-search-query-analyst.md) +- [2026-04-24] [Paid Media Auditor Agent](sources/paid-media-auditor.md) +- [2026-04-24] [Paid Media PPC Campaign Strategist Agent](sources/paid-media-ppc-strategist.md) +- [2026-04-24] [Paid Media Programmatic & Display Buyer Agent](sources/paid-media-programmatic-buyer.md) +- [2026-04-24] [Visual Storyteller Agent](sources/design-visual-storyteller.md) +- [2026-04-24] [Inclusive Visuals Specialist](sources/design-inclusive-visuals-specialist.md) +- [2026-04-24] [Image Prompt Engineer Agent](sources/design-image-prompt-engineer.md) +- [2026-04-24] [UI Designer Agent Personality](sources/design-ui-designer.md) +- [2026-04-24] [Design Brand Guardian](sources/design-brand-guardian.md) +- [2026-04-24] [UX Researcher Agent Personality](sources/design-ux-researcher.md) +- [2026-04-24] [Design Whimsy Injector](sources/design-whimsy-injector.md) +- [2026-04-24] [ArchitectUX Agent Personality](sources/design-ux-architect.md) +- [2026-04-24] [Contributing to The Agency](sources/contributing.md) +- [2026-04-24] [为 The Agency 贡献代码](sources/contributing_zh-cn.md) +- [2026-04-24] [CTP Topic 12 Using SES SMTP service terraform module](sources/ctp-topic-12-using-ses-smtp-service-terraform-module.md) +- [2026-04-24] [Learning Sessions Cloud Transformation Programme-Deploying RDS via Terraform](sources/learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform.md) +- [2026-04-24] [Learning Sessions Cloud Transformation Programme-20230808 183322-Meeting Recording](sources/learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi.md) +- [2026-04-24] [CTP Topic 16 Cross-account Terraform modules](sources/ctp-topic-16-cross-account-terraform-modules.md) +- [2026-04-24] [Learning Sessions ECS Deployment using IAC - 20230808](sources/learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording.md) +- [2026-04-24] [CTP Topic 48 Terraform vs Terragrunt](sources/ctp-topic-48-terraform-vs-terragrunt.md) +- [2026-04-24] [Public Cloud Learning Sessions (OpenText) - AI Use Cases - 20241126 160106](sources/public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec.md) +- [2026-04-24] [Public Cloud Learning Sessions (OpenText) - Event Driven Architecture Part 2](sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091.md) +- [2026-04-24] [Public Cloud Learning Sessions (OpenText) - Generative AI & Prompt Engineering - 20241112](sources/public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111.md) +- [2026-04-24] [Public Cloud Learning Sessions (OpenText) - Event Driven Architecture Part 1](sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091.md) +- [2026-04-24] [Public Cloud Learning Sessions - Serverless Computing - 20240903](sources/public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee.md) +- [2026-04-24] [Public Cloud Learning Sessions - Introduction to AI/ML with AWS](sources/public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin.md) +- [2026-04-24] [Cloud Learning Master Index](sources/cloud-learning-master-index.md) +- [2026-04-24] [CTP Topic 27 AWS Instance Scheduler](sources/ctp-topic-27-aws-instance-scheduler.md) +- [2026-04-24] [Public Cloud Learning Sessions - Budget Control - 20240319](sources/public-cloud-learning-sessions-budget-control-20240319-160204-meeting-recording.md) +- [2026-04-24] [CTP Topic 63 Optimise resource cost using automation](sources/ctp-topic-63-optimise-resource-cost-using-automation.md) +- [2026-04-24] [Public Cloud Learning Sessions - Storage Cost Optimization - 20240305](sources/public-cloud-learning-sessions-storage-cost-optimization-20240305-160037-meeting.md) +- [2026-04-24] [CTP Topic 71 PCG's guide to RightSizing, why, how when](sources/ctp-topic-71-pcgs-guide-to-rightsizing-why-how-when.md) +- [2026-04-24] [Public Cloud Learning Sessions - Best practices for EC2 cost optimization in AWS - 20240529](sources/public-cloud-learning-sessions-best-practices-for-ec2-cost-optimization-in-aws-2.md) +- [2026-04-24] [Public Cloud Learning Sessions - Reducing Cloud Costs - 20250318](sources/public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco.md) +- [2026-04-24] [CTP Topic 13 Cloud FinOps Micro Focus Policies best practices to optimize the costs](sources/ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co.md) +- [2026-04-24] [CTP Topic 15 Working with Renovatebot](sources/ctp-topic-15-working-with-renovatebot.md) +- [2026-04-24] [CTP Topic 56 Automated Infrastructure Testing](sources/ctp-topic-56-automated-infrastructure-testing.md) +- [2026-04-24] [Public Cloud Learning Sessions - Ollie Workflow and The Demand Process - 20240416](sources/public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16.md) +- [2026-04-24] [CTP Topic 33 An Introduction to GitOps](sources/ctp-topic-33-an-introduction-to-gitops.md) +- [2026-04-24] [CTP Topic 3 Deploy and maintain infrastructure](sources/ctp-topic-3-deploy-and-maintain-infrastructure.md) +- [2026-04-24] [CTP Topic 9 CI CD with Gruntwork](sources/ctp-topic-9-ci-cd-with-gruntwork.md) +- [2026-04-24] [CTP Topic 32 Using Atlantis CICD for Infrastructure Deployments](sources/ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments.md) +- [2026-04-24] [CTP Topic 2 Git](sources/ctp-topic-2-git.md) +- [2026-04-24] [CTP Topic 24 Micro Focus Product Privacy Framework](sources/ctp-topic-24-micro-focus-product-privacy-framework.md) +- [2026-04-24] [CTP Topic 49 Container Lifecycle Hardening Standards](sources/ctp-topic-49-container-lifecycle-hardening-standards.md) +- [2026-04-24] [CTP Topic 21 Supply Chain Security in Micro Focus](sources/ctp-topic-21-supply-chain-security-in-micro-focus.md) +- [2026-04-24] [CTP Topic 52 3 Lines of Defence (3LoD) framework Cloud Security Posture Management (CSPM)](sources/ctp-topic-52-3-lines-of-defence-3lod-framework-cloud-security-posture-management.md) +- [2026-04-24] [CTP Topic 55 AWS Firewall Manager](sources/ctp-topic-55-aws-firewall-manager.md) +- [2026-04-24] [CTP Topic 37 Secrets Certificates Management](sources/ctp-topic-37-secrets-certificates-management.md) +- [2026-04-24] [CTP Topic 62 AWS Secrets Manager](sources/ctp-topic-62-aws-secrets-manager.md) +- [2026-04-24] [Public Cloud Learning Sessions - OpenText GIS Security Policies - 20241015](sources/public-cloud-learning-sessions-opentext-gis-security-policies-20241015-160257-me.md) +- [2026-04-24] [CTP Topic 64 Scaling out with Amazon EKS](sources/ctp-topic-64-scaling-out-with-amazon-eks.md) +- [2026-04-24] [CTP Topic 67 Cloud native observability using OpenTelemetry](sources/ctp-topic-67-cloud-native-observability-using-opentelemetry.md) +- [2026-04-24] [Public Cloud Learning Sessions - EKS Optimization Part 2 of 3 - Running Containers with Bottlerocket OS](sources/public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w.md) +- [2026-04-24] [CTP Topic 42 Grafana Observability Dashboard](sources/ctp-topic-42-grafana-observability-dashboard.md) +- [2026-04-24] [Public Cloud Learning Sessions - Observability with OpenTelemetry - 20240402](sources/public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113.md) +- [2026-04-24] [CTP Topic 54 ESM SaaS Log Analytics](sources/ctp-topic-54-esm-saas-log-analytics.md) +- [2026-04-24] [CTP Topic 59 Achieving reliability with Amazon EKS](sources/ctp-topic-59-achieving-reliability-with-amazon-eks.md) +- [2026-04-24] [CTP Topic 29 Cloud Monitoring – SaaS LZ accounts](sources/ctp-topic-29-cloud-monitoring-saas-lz-accounts.md) +- [2026-04-24] [CTP Topic 39 Implementing EKS in the AWS Lab Landing Zone](sources/ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone.md) +- [2026-04-24] [Public Cloud Learning Sessions - EKS Optimization Part 1 of 3 - Compute Optimization with Karpenter](sources/public-cloud-learning-sessions-eks-optimization-part-1-of-3-compute-optimization.md) +- [2026-04-24] [CTP Topic 70 EKS deployment using IAC](sources/ctp-topic-70-eks-deployment-using-iac.md) +- [2026-04-24] [CTP Topic 60 - Monitor AWS using Hyperscale Observability with Grafana](sources/ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana.md) +- [2026-04-24] [Public Cloud Learning Sessions - EKS Optimization Part 3 of 3 - Introduction to EKS Auto Mode](sources/public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks.md) +- [2026-04-24] [CTP Topic 8 - Implementation of Cloud Monitoring using Micro Focus Operations Bridge Manager](sources/ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid.md) +- [2026-04-23] [CTP Topic 11 AD Integration and Login using AD Accounts](sources/ctp-topic-11-ad-integration-and-login-using-ad-accounts.md) +- [2026-04-23] [CTP Topic 5 - AWS Identity and Access Management (IAM)](sources/ctp-topic-5-aws-identity-and-access-management-iam.md) +- [2026-04-23] [Learning Sessions Identity Governance VSM Replacement - 20231128](sources/learning-sessions-identity-governance-vsm-replacement-20231128-160326-meeting-re.md) +- [2026-04-23] [Public Cloud Learning Sessions - AWS End User Compute Services - 20240430](sources/public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee.md) +- [2026-04-23] [Public Cloud Learning Sessions- Applicable Business Analysis Techniques - 20240109](sources/public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109.md) +- [2026-04-23] [Public Cloud Learning Sessions (OpenText) - Product Hub (PHT) Overview and Q&A - 20240806](sources/public-cloud-learning-sessions-opentext-product-hub-pht-overview-and-qa-20240806.md) +- [2026-04-23] [Public Cloud Learning Sessions - Tagging Standards for All Hyperscalers - 20240123](sources/public-cloud-learning-sessions-tagging-standards-for-all-hyperscalers-20240123-1.md) +- [2026-04-23] [CTP Topic 23 Introduction to the Technical Architecture Team and Function](sources/ctp-topic-23-introduction-to-the-technical-architecture-team-and-function.md) +- [2026-04-23] [CTP Topic 57 Product backlog managing demand](sources/ctp-topic-57-product-backlog-managing-demand.md) +- [2026-04-23] [Public Cloud Learning Sessions (OpenText) - Thor Platform & Flows](sources/public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet.md) +- [2026-04-23] [CTP Topic 6 AWS Workspaces Demo](sources/ctp-topic-6-aws-workspaces-demo.md) +- [2026-04-23] [CTP Topic 53 Why bother with Cloud](sources/ctp-topic-53-why-bother-with-cloud.md) +- [2026-04-23] [Public Cloud Learning Sessions (OpenText) - GitHub Enterprise to GitLab Migration](sources/public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20.md) +- [2026-04-23] [Public Cloud Learning Sessions - OpenText Tagging Standard v2 - 20250429](sources/public-cloud-learning-sessions-opentext-tagging-standard-v2-20250429-170111-meet.md) +- [2026-04-23] [CTP Topic 41 NFR's and Error Budgets](sources/ctp-topic-41-nfrs-and-error-budgets.md) +- [2026-04-23] [CTP Topic 10 AWS Landing Zone (LZ) Data Collection, Tagging Related Security](sources/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md) +- [2026-04-23] [CTP Topic 20 Program demand process flow and PoC onboarding](sources/ctp-topic-20-program-demand-process-flow-and-poc-onboarding.md) +- [2026-04-23] [CTP Topic 4 Using Agile to Run the Cloud Transformation Programme](sources/ctp-topic-4-using-agile-to-run-the-cloud-transformation-program.md) +- [2026-04-23] [CTP Topic 65 Tracing the Value Delivered in Cloud Transformation](sources/ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation.md) +- [2026-04-23] [Public Cloud Learning Sessions (OpenText) - Evolving from DR to Recovery Assurance - 20240723](sources/public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2.md) +- [2026-04-23] [CTP Topic 30 Managing Change](sources/ctp-topic-30-managing-change.md) +- [2026-04-23] [CTP Topic 69 Best Practices for Migrating On-Premises (IOD) Virtual Machines to VMware Cloud on AWS](sources/ctp-topic-69-best-practices-for-migrating-on-premises-iod-virtual-machines-to-vm.md) +- [2026-04-23] [CTP Topic 31 Network Segregation and Secure Access to the New AWS Landing Zones](sources/ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones.md) +- [2026-04-23] [CTP Topic 18 Wide Area Networking in AWS Cloud](sources/ctp-topic-18-wide-area-networking-in-aws-cloud.md) +- [2026-04-23] [CTP Topic 43 VMware Cloud on AWS](sources/ctp-topic-43-vmware-cloud-on-aws.md) +- [2026-04-23] [CTP Topic 61 Workload VPC provision with IPAM Automation](sources/ctp-topic-61-workload-vpc-provision-with-ipam-automation.md) +- [2026-04-23] [CTP Topic 45 Automatic IP address allocation with IPAM](sources/ctp-topic-45-automatic-ip-address-allocation-with-ipam.md) +- [2026-04-23] [CTP Topic 19 Configuring DNS within AWS LZs](sources/ctp-topic-19-configuring-dns-within-aws-lzs.md) +- [2026-04-23] [CTP Topic 36 SendGrid as an Email Service](sources/ctp-topic-36-sendgrid-as-an-email-service.md) +- [2026-04-23] [CTP Topic 22 Global DNS service offerings](sources/ctp-topic-22-global-dns-service-offerings.md) +- [2026-04-23] [CTP Topic 50 AMI Roadmap for AWS AMIs](sources/ctp-topic-50-ami-roadmap-for-aws-amis.md) +- [2026-04-23] [CTP Topic 40 SaaS Database Architecture On AWS Cloud](sources/ctp-topic-40-saas-database-architecture-on-aws-cloud.md) +- [2026-04-23] [CTP Topic 26 Standard AMI – build, publish, share processes](sources/ctp-topic-26-standard-ami-build-publish-share-processes.md) +- [2026-04-23] [CTP Topic 68 Introduction to Redshift](sources/ctp-topic-68-introduction-to-redshift.md) +- [2026-04-23] [CTP Topic 58 AWS EC2 Image Builder](sources/ctp-topic-58-aws-ec2-image-builder.md) +- [2026-04-23] [CTP Topic 25 Labs Landing Zone Overview - ITOM Teams](sources/ctp-topic-25-labs-landing-zone-overview-itom-teams.md) +- [2026-04-23] [Learning Sessions: Standard AMI Updates 20231205](sources/learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2.md) +- [2026-04-23] [CTP Topic 7 SaaS Landing Zone Design](sources/ctp-topic-7-saas-landing-zone-design.md) +- [2026-04-23] [CTP Topic 34 Azure Landing Zone Architecture Overview](sources/ctp-topic-34-azure-landing-zone-architecture-overview.md) +- [2026-04-23] [CTP Topic 35 AWS Landing Zone Design Refresher (SaaS Labs)](sources/ctp-topic-35-aws-landing-zone-design-refresher-saas-labs.md) +- [2026-04-23] [CTP Topic 10 AWS Landing Zone (LZ) Data Collection, Tagging Related Security](sources/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md) +- [2026-04-23] [CTP Topic 73 AWS Backup Implementation of the Cloud Transformation Programme](sources/ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program.md) +- [2026-04-23] [CTP Topic 28 AWS Tag Validation Tool](sources/ctp-topic-28-aws-tag-validation-tool.md) +- [2026-04-23] [CTP Topic 47 Enterprise Architecture Cloud Standards](sources/ctp-topic-47-enterprise-architecture-cloud-standards.md) +- [2026-04-23] [CTP Topic 72 Implementing an Enterprise DR Strategy Using AWS Backup](sources/ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup.md) +- [2026-04-23] [CTP Topic 1 Gruntwork Landing Zone Architecture](sources/ctp-topic-1-gruntwork-landing-zone-architecture.md) +- [2026-04-23] [CTP Topic 51 Architecting with AWS Purpose-Built Databases](sources/ctp-topic-51-architecting-with-aws-purpose-built-databases.md) +- [2026-04-23] [CTP Topic 46 NetApps on AWS](sources/ctp-topic-46-netapps-on-aws.md) +- [2026-04-23] [CTP Topic 17 Active Directory Services in Gruntwork AWS LZs](sources/ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs.md) +- [2026-04-23] [CTP Topic 66 Exposing the differences between PostgreSQL RDS and Aurora](sources/ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora.md) +- [2026-04-23] [CTP Topic 14 Octane Hub on AWS Real Life Experience Moving Production Services](sources/ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services-i.md) +- [2026-04-23] [CTP Topic 44 AWS Backup in Micro Focus](sources/ctp-topic-44-aws-backup-in-micro-focus.md) +- [2026-04-23] [Blogwatcher Daily 技能收藏](sources/blogwatcher-daily收藏.md) +- [2026-04-23] [实战笔记：本地部署 RSSHub 并获取 YouTube 订阅](sources/实战笔记-本地部署-rsshub-并获取-youtube-订阅.md) +- [2026-04-23] [Mac必装软件清单](sources/mac必装软件清单-2026-04-17.md) +- [2026-04-23] [Install WSL](sources/install-wsl.md) +- [2026-04-23] [WSL2 启动与网络配置指南](sources/wsl2-启动与网络配置指南.md) +- [2026-04-23] [fireworks-tech-graph](sources/fireworks-tech-graph.md) +- [2026-04-23] [Obsidian 官方 CLI 命令全景速查表](sources/obsidian-官方-cli-命令全景速查表.md) +- [2026-04-23] [Obsidian CLI](sources/obsidian-cli.md) +- [2026-04-23] [我做了个 Skill：让 AI 帮你生成 Logo 和图标](sources/我做了个-skill-让-ai-帮你生成-logo-和图标.md) +- [2026-04-23] [Obsidian 必装 Skills](sources/obsidian-必装-skills.md) +- [2026-04-23] [在 Ubuntu 安装 Ollama 并运行 Qwen2.5‑Coder 7B](sources/在-ubuntu-安装-ollama-并运行-qwen2-5‑coder-7b.md) +- [2026-04-23] [Learn AI for free directly from top companies](sources/learn-ai-for-free-directly-from-top-companies.md) +- [2026-04-23] [I Went Through Every AI Memory Tool I Could Find. There Are Two Camps.](sources/ai-memory-tools-two-camps.md) +- [2026-04-23] [可自动化、可扩展、AI增强的电商数据采集与处理系统](sources/可自动化-可扩展-ai增强的电商数据采集与处理系统.md) +- [2026-04-23] [Building your Quartz](sources/building-your-quartz.md) +- [2026-04-23] [电商如何选品 - 如何找到爆款选品策略](sources/电商如何选品-如何找到爆款-选品策略.md) +- [2026-04-23] [电商视频Prompt库](sources/电商视频prompt.md) +- [2026-04-23] [TikTok Shop - Apache Superset Dashboard设计思路](sources/tiktok-shop-apache-superset-dashboard设计思路.md) +- [2026-04-23] [做TK跨境思路不对努力白费](sources/做tk跨境思路不对努力白费.md) +- [2026-04-23] [超达物流定价](sources/超达物流定价.md) +- [2026-04-23] [TK美国面单授权及操作流程](sources/tk美国面单授权及操作流程.md) +- [2026-04-23] [Scrapy + Playwright 抓取TikTok Shop Data](sources/scrapy-playwright-抓取tiktok-shop-data.md) +- [2026-04-23] [GOG CLI 安装配置指南](sources/gog-cli-安装配置指南.md) +- [2026-04-23] [Last30Days 使用指南](sources/last30days-使用指南.md) +- [2026-04-23] [如何利用Sora接口实现视频自动化生成工作流](sources/如何利用sora接口实现视频自动化生成工作流.md) +- [2026-04-23] [If You Have Multiple Interests, Do Not Waste the Next 2-3 Years](sources/if-you-have-multiple-interests-do-not-waste-the-next-2-3-years-如果你有多项兴趣爱好-不要浪费接下来的两三年时间.md) +- [2026-04-23] [我用 Gemini 3 一口气做了 10 个应用，附教程](sources/我用-gemini-3-一口气做了-10-个应用-附教程.md) +- [2026-04-23] [Multi-Agent System Reliability](sources/multi-agent-system-reliability.md) +- [2026-04-23] [全网最全！Nano Banana 2 使用指南（2025年12月更新）](sources/全网最全-nano-banana-2-使用指南-2025年12月更新-1.md) +- [2026-04-23] [2025 年 11 个神级 AI 开源平替，GitHub 杀疯了](sources/2025-年-11-个神级-ai-开源平替-github-杀疯了.md) +- [2026-04-23] [AI 解决方案专家培训课程](sources/ai-解决方案专家培训课程.md) +- [2026-04-23] [RAG从入门到精通系列1：基础RAG](sources/rag从入门到精通系列1-基础rag.md) +- [2026-04-23] [固定镜头短视频制作的AI全流程解析](sources/固定镜头短视频制作的ai全流程解析.md) +- [2026-04-23] [大模型相关术语和框架总结｜LLM、MCP、Prompt、RAG、vLLM、Token、数据蒸馏](sources/大模型相关术语和框架总结｜llm-mcp-prompt-rag-vllm-token-数据蒸馏.md) +- [2026-04-23] [Nano Banana Pro 提示词指南与策略（上篇）](sources/nano-banana-pro-prompting-guide-strategies-1.md) +- [2026-04-23] [我的工具集](sources/我的工具集.md) +- [2026-04-23] [3.2 万人收藏的 Claude Skills，才是 AI 这条路上最值得研究的一套范式！](sources/3-2-万人收藏的-claude-skills-才是-ai-这条路上最值得研究的一套范式.md) +- [2026-04-23] [如何写出完美的Prompt（提示词）？](sources/如何写出完美的prompt-提示词.md) +- [2026-04-23] [codecrafters-io/build-your-own-x: Master programming by recreating your favorite technologies from scratch](sources/codecrafters-iobuild-your-own-x-master-programming-by-recreating-your-favorite-technologies-from-scratch.md) +- [2026-04-23] [系统提示词构建原则](sources/系统提示词构建原则.md) +- [2026-04-23] [GitHub 上 5000 人收藏的 Vibe Coding 神级指南](sources/github-上-5000-人收藏的-vibe-coding-神级指南.md) +- [2026-04-23] [How to Get the RSS Feed For Any YouTube Channel](sources/how-to-get-the-rss-feed-for-any-youtube-channel.md) +- [2026-04-23] [3.2 万人收藏的 Claude Skills，才是 AI 这条路上最值得研究的一套范式！](sources/3-2-万人收藏的-claude-skills-才是-ai-这条路上最值得研究的一套范式-1.md) +- [2026-04-22] [不会Gemini的产品经理真的要被淘汰了 | 附保姆级PRD生成指南](sources/不会gemini的产品经理真的要被淘汰了-附保姆级prd生成指南.md) +- [2026-04-22] [7 ways I use NotebookLM to make my life easier](sources/7-ways-i-use-notebooklm-to-make-my-life-easier.md) +- [2026-04-22] [Never write another prompt](sources/never-write-another-prompt.md) +- [2026-04-22] [一语点醒梦中人](sources/一语点醒梦中人.md) +- [2026-04-22] [Best 7 news API data feeds - AI News](sources/best-7-news-api-data-feeds-ai-news.md) +- [2026-04-22] [Claude Prompt Library 汇总表](sources/useful-prompt-lib.md) +- [2026-04-22] [二创视频必不可少！2025年最热门AI工具推荐合集-AI配音、声音克隆](sources/二创视频必不可少-2025年最热门ai工具推荐合集-ai配音-声音克隆.md) +- [2026-04-22] [The Picture They Paint of You](sources/the-picture-they-paint-of-you.md) +- [2026-04-22] [Nano Banana 提示词框架](sources/nano-banana-提示词框架.md) +- [2026-04-22] [谷歌深夜甩出一份【Nano Banana Pro提示词指南】，手把手教你生产专业级内容，实战案例+提示词模版](sources/谷歌深夜甩出一份-nano-banana-pro提示词指南-手把手教你生产专业级内容-实战案例-提示词模版.md) +- [2026-04-22] [详细！离线部署大模型：ollama+deepseek+open-webui安装使用方法及常见问题解决 1](sources/详细-离线部署大模型-ollama-deepseek-open-webui安装使用方法及常见问题解决-1.md) +- [2026-04-22] [OpenAI ChatGPT 个性化定义](sources/openai-chatgpt-个性化定义.md) +- [2026-04-22] [清华出的DeepSeek使用手册，104页，真的是太厉害了！（免费领取）](sources/清华出的deepseek使用手册-104页-真的是太厉害了-免费领取.md) +- [2026-04-22] [LLMs、RAG、AI Agent 三个到底什么区别？](sources/llms-rag-ai-agent-三个到底什么区别.md) +- [2026-04-22] [A Formalization of Recursive Self-Optimizing Generative Systems](sources/a-formalization-of-recursive-self-optimizing-generative-systems.md) +- [2026-04-22] [文字生成视频网站推荐](sources/文字生成视频网站推荐.md) +- [2026-04-22] [Google 神级生产力工具，所有 GitHub 开源平替都找到了。](sources/google-神级生产力工具-所有-github-开源平替都找到了.md) +- [2026-04-22] [教學 ChatGPT 先做知識整理，再讓 Canva、 Gamma AI 輸出簡報](sources/教學-chatgpt-先做知識整理-再讓-canva-gamma-ai-輸出簡報.md) +- [2026-04-22] [Designing for Agentic AI](sources/designing-for-agentic-ai.md) +- [2026-04-22] [14个免费的AI图生视频工具，用AI让图片动起来](sources/14个免费的ai图生视频工具-用ai让图片动起来-ai视频教程-ai自动化工作流定制服务-ai培训学习平台-黑喵大叔.md) +- [2026-04-22] [养虾日记5：深夜与苏轼聊AI，他说：被浪打下去还能爬起来的才叫风流](sources/养虾日记5-深夜与苏轼聊ai-他说-被浪打下去还能爬起来的才叫风流.md) +- [2026-04-22] [养虾日记4：一次「Context Limit Exceeded」错误排查：我以为是小问题，结果踩了大坑](sources/养虾日记4-一次「context-limit-exceeded」错误排查-我以为是小问题-结果踩了大坑.md) +- [2026-04-22] [不谈技术：普通人该怎么在AI时代赚钱？](sources/不谈技术-普通人该怎么在ai时代赚钱.md) +- [2026-04-22] [养虾日记3：用 Obsidian + Gitea 为 AI 助手构建持久化笔记系统](sources/养虾日记3-用-obsidian-gitea-为-ai-助手构建持久化笔记系统.md) +- [2026-04-22] [养龙虾5天血泪史：我的AI Agent为什么总失忆？OpenClaw 记忆调试全记录](sources/养龙虾5天血泪史-我的ai-agent为什么总失忆-openclaw-记忆调试全记录.md) +- [2026-04-22] [养虾日记1：我用 OpenClaw 管了 28 万张照片：一次真实的多设备照片整理实战](sources/养虾日记1-我用-openclaw-管了-28-万张照片-一次真实的多设备照片整理实战.md) +- [2026-04-22] [养虾日记2：让Agent更懂你：OpenClaw + Self-Improving 复盘实战案例分享](sources/养虾日记2-让agent更懂你-openclaw-self-improving-复盘实战案例分享.md) +- [2026-04-22] [X Account Analysis](sources/x-account-analysis.md) +- [2026-04-22] [Phone Call Notifications](sources/phone-call-notifications.md) +- [2026-04-22] [Autonomous Educational Game Development Pipeline](sources/autonomous-game-dev-pipeline.md) +- [2026-04-22] [arXiv Paper Reader](sources/arxiv-paper-reader.md) +- [2026-04-22] [Semantic Memory Search](sources/semantic-memory-search.md) +- [2026-04-22] [OpenClaw as Desktop Cowork (AionUi) — Remote Rescue & Multi-Agent Hub](sources/aionui-cowork-desktop.md) +- [2026-04-22] [Family Calendar Aggregation & Household Assistant](sources/family-calendar-household-assistant.md) +- [2026-04-22] [Multi-Source Tech News Digest](sources/multi-source-tech-news-digest.md) +- [2026-04-22] [X/Twitter Automation from Chat](sources/x-twitter-automation.md) +- [2026-04-22] [Personal Knowledge Base (RAG)](sources/knowledge-base-rag.md) +- [2026-04-22] [Personal CRM with Automatic Contact Discovery](sources/personal-crm.md) +- [2026-04-22] [YouTube Content Pipeline](sources/youtube-content-pipeline.md) +- [2026-04-22] [Polymarket Autopilot](sources/polymarket-autopilot.md) +- [2026-04-22] [Goal-Driven Autonomous Tasks](sources/overnight-mini-app-builder.md) +- [2026-04-22] [Local CRM Framework with DenchClaw](sources/local-crm-framework.md) +- [2026-04-22] [OpenClaw + n8n Workflow Orchestration](sources/n8n-workflow-orchestration.md) +- [2026-04-22] [Multi-Channel AI Customer Service Platform](sources/multi-channel-customer-service.md) +- [2026-04-22] [Second Brain](sources/second-brain.md) +- [2026-04-22] [LaTeX Paper Writing](sources/latex-paper-writing.md) +- [2026-04-22] [Habit Tracker & Accountability Coach](sources/habit-tracker-accountability-coach.md) +- [2026-04-22] [Todoist Task Manager](sources/todoist-task-manager.md) +- [2026-04-22] [Dynamic Dashboard with Sub-agent Spawning](sources/dynamic-dashboard.md) +- [2026-04-22] [Pre-Build Idea Validator](sources/pre-build-idea-validator.md) +- [2026-04-22] [Autonomous Project Management with Subagents](sources/autonomous-project-management.md) +- [2026-04-22] [Daily Reddit Digest](sources/daily-reddit-digest.md) +- [2026-04-22] [Inbox De-clutter](sources/inbox-declutter.md) +- [2026-04-22] [Custom Morning Brief](sources/custom-morning-brief.md) +- [2026-04-22] [Market Research & Product Factory](sources/market-research-product-factory.md) +- [2026-04-22] [Phone-Based Personal Assistant](sources/phone-based-personal-assistant.md) +- [2026-04-22] [Event Guest Confirmation](sources/event-guest-confirmation.md) +- [2026-04-22] [Multi-Channel Personal Assistant](sources/multi-channel-assistant.md) +- [2026-04-22] [AI-Powered Earnings Tracker](sources/earnings-tracker.md) +- [2026-04-22] [Multi-Agent Specialized Team (Solo Founder Setup)](sources/multi-agent-team.md) +- [2026-04-22] [Project State Management System: Event-Driven Alternative to Kanban](sources/project-state-management.md) +- [2026-04-22] [Health & Symptom Tracker](sources/health-symptom-tracker.md) +- [2026-04-22] [Self-Healing Home Server & Infrastructure Management](sources/self-healing-home-server.md) +- [2026-04-22] [Multi-Agent Content Factory](sources/content-factory.md) +- [2026-04-22] [Daily YouTube Digest](sources/daily-youtube-digest.md) +- [2026-04-22] [Automated Meeting Notes & Action Items](sources/meeting-notes-action-items.md) +- [2026-04-22] [Podcast Production Pipeline](sources/podcast-production-pipeline.md) +- [2026-04-22] [Claude Code 调用方法总结](sources/claude-code调用方法总结.md) +- [2026-04-22] [N8N Full Tutorial Building AI Agents in 2025 for Beginners!](sources/n8n-full-tutorial-building-ai-agents-in-2025-for-beginners.md) +- [2026-04-22] [n8n + Claude：通过自然语言自动化工作流](sources/n8n-claude-通过自然语言自动化工作流.md) +- [2026-04-22] [万字保姆级教程，让你90天跑通一人公司模式（附AI提示词）](sources/万字保姆级教程-90天跑通一人公司模式-2026-03-29.md) +- [2026-04-22] [使用Claude自动生成N8N工作流的实操教程](sources/使用claude自动生成n8n工作流的实操教程.md) +- [2026-04-22] [MCP在Cursor中的集成与应用详解](sources/mcp在cursor中的集成与应用详解.md) +- [2026-04-22] [Google 5个 Agent Skill 设计模式](sources/google-5个agent-skill设计模式-2026-03-19.md) +- [2026-04-22] [n8n configure telegram trigger](sources/n8n-configure-telegram-trigger.md) +- [2026-04-22] [n8n Docker 安装与更新](sources/n8n-docker-install-update.md) +- [2026-04-22] [万字讲透OpenClaw Workspace深度解析](sources/万字讲透openclaw-workspace深度解析-2026-03-21.md) +- [2026-04-22] [How to get Youtube Channel ID](sources/how-to-get-youtube-channel-id.md) +- [2026-04-22] [TikTok PM - Python Django 项目](sources/tiktok-pm-python-django-project.md) +- [2026-04-22] [dataview-让我从“笔记黑洞”里逃出来的-obsidian-神器-1](sources/dataview-让我从“笔记黑洞”里逃出来的-obsidian-神器-1.md) — (expected: wiki/sources/dataview-让我从“笔记黑洞”里逃出来的-obsidian-神器-1.md — source missing) +- [2026-04-22] [Obsidian 高效指南：我常用的插件与实用技巧](sources/obsidian-高效指南-我常用的插件与实用技巧.md) +- [2026-04-22] [Obsidian最有必要安装的10款插件是这些](sources/obsidian最有必要安装的10款插件是这些.md) +- [2026-04-22] [Obsidian Tasks 插件：这可能是最适合懒人的任务管理方式](sources/obsidian-tasks-插件-这可能是最适合懒人的任务管理方式.md) +- [2026-04-22] [ChinaTextbook - 41.53 GB，中国小学、初中、高中、大学 PDF 教材](sources/chinatextbook-41-53-gb-中国小学-初中-高中-大学-pdf-教材.md) +- [2026-04-22] [开发经验与项目规范整理文档](sources/开发经验与项目规范整理文档.md) +- [2026-04-22] [在Ubuntu上安装Vibe-Kanban](sources/在ubuntu上安装vibe-kanban.md) +- [2026-04-22] [Vibe-Kanban + OpenCode 在 Ubuntu Server 上安装与管理指南](sources/vibe-kanban-opencode-在-ubuntu-server-上安装与管理指南.md) +- [2026-04-22] [Vibe Coding 经验收集](sources/vibe-coding经验收集.md) +- [2026-04-22] [如何在项目里安装Claude Code Templates Skills](sources/如何在项目里安装claude-code-templates-skills.md) +- [2026-04-22] [Trae远程开发部署指南](sources/trae远程开发部署指南.md) +- [2026-04-22] [Cursor 2.0初学者使用指南](sources/cursor-2-0初学者使用指南.md) +- [2026-04-22] [如何在Ubuntu上安装OpenCode并配置Vibe-Kanban](sources/如何在ubuntu上安装opencode并配置vibe-kanban.md) +- [2026-04-22] [如何传输Docker images 并且在另一个Docker安装](sources/如何传输docker-images-并且在另一个docker安装.md) +- [2026-04-22] [Ubuntu用RustDesk远程登录出现不能使用Wayland登录的错误](sources/ubuntu用rustdesk远程登录出现不能使用wayland登录的错误.md) +- [2026-04-21] [用Docker安装Homarr](sources/用docker安装homarr.md) +- [2026-04-21] [在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透](sources/在ubuntu上通过vps-内网反向代理实现域名访问内网穿透.md) +- [2026-04-21] [如何在Ubuntu Server上通过NFS挂载Synology NAS上的共享文件夹](sources/如何在ubuntu-server上通过nfs挂载synology-nas上的共享文件夹.md) +- [2026-04-21] [用Docker安装Apache Superset](sources/用docker安装apache-superset.md) +- [2026-04-21] [Mac Mini 服务器配置：防止自动锁屏与睡眠](sources/mac-mini-服务器配置-防止自动锁屏与睡眠.md) +- [2026-04-21] [家庭网络环境概览](sources/家庭网络环境概览_2026-04-03.md) +- [2026-04-21] [如何删除旧的废弃的Docker Container + Volume](sources/如何删除旧的废弃的docker-container-volume.md) +- [2026-04-21] [用Docker安装Portainer](sources/用docker安装portainer.md) +- [2026-04-21] [用Docker安装Jellyfin](sources/用docker安装jellyfin.md) +- [2026-04-21] [Ubuntu Server科学上网](sources/ubuntu-server科学上网.md) +- [2026-04-21] [Ubuntu禁用合盖休眠](sources/ubuntu禁用合盖休眠.md) +- [2026-04-21] [安装v2rayN](sources/安装v2rayn.md) +- [2026-04-21] [Install Apache Superset in Docker](sources/install-apache-superset-in-docker.md) +- [2026-04-21] [MinIO + Zipline 自托管图床应用安装教程](sources/minio-zipline-自托管图床应用安装教程.md) +- [2026-04-21] [群晖NAS科学上网方法](sources/群晖nas科学上网方法.md) +- [2026-04-21] [NodeWarden - 把 Bitwarden 搬上 Cloudflare Workers，彻底告别服务器](sources/nodewarden-把-bitwarden-搬上-cloudflare-workers-彻底告别服务器.md) +- [2026-04-21] [macOS 创建与解除 Symbolic Link（OpenClaw 目录映射）](sources/macos-创建与解除-symbolic-link-openclaw-目录映射.md) +- [2026-04-21] [如何在Ubuntu Server安装 Docker & Docker Compose](sources/如何在ubuntu-server安装-docker-docker-compose.md) +- [2026-04-21] [家庭监控方案：Prometheus + Grafana + Node Exporter + cAdvisor + Blackbox](sources/家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox.md) +- [2026-04-21] [Ubuntu 安装 FRP 0.65.0（x86_64）操作笔记](sources/ubuntu-安装-frp-0-65-0-x86_64-操作笔记.md) +- [2026-04-21] [Mac Mini 安装 FRP 0.65.0（ARM64）操作笔记](sources/mac-mini-安装-frp-0-65-0-arm64-操作笔记.md) +- [2026-04-21] [在Synology NAS上安装CloudDrive2](sources/在synology-nas上安装clouddrive2.md) +- [2026-04-21] [如何判别你的Linux 服务器是 x64（也就是 x86_64）还是 ARM64](sources/如何判别你的linux-服务器是-x64-也就是-x86_64-还是-arm64.md) +- [2026-04-21] [如何用指纹浏览器安全注册并订阅Claude Pro会员全攻略](sources/如何用指纹浏览器安全注册并订阅claude-pro会员全攻略.md) +- [2026-04-21] [安装Ubuntu 24.04.2在HP ZBook工作站笔记本上](sources/安装ubuntu-24-04-2在hp-zbook工作站笔记本上.md) +- [2026-04-21] [用Docker安装it-tools](sources/用docker安装it-tools.md) +- [2026-04-21] [通过VPS+内网反向代理实现域名访问内网穿透](sources/通过vps-内网反向代理实现域名访问内网穿透.md) +- [2026-04-21] [Clonezilla对Ubuntu Server进行全盘镜像备份](sources/clonezilla对ubuntu-server进行全盘镜像备份.md) +- [2026-04-21] [3X-UI Xray on BandwagonVPS](sources/3x-ui-xray-on-bandwagonvps.md) +- [2026-04-21] [Ubuntu 24.04 启动 SSH 服务](sources/ubuntu-24-04-enable-ssh.md) +- [2026-04-21] [用Docker安装transmission](sources/用docker安装transmission.md) +- [2026-04-21] [RAX50 路由器更新Merlin Clash订阅](sources/rax50-路由器-更新merlin-clash订阅.md) +- [2026-04-21] [网件RAX50路由器刷梅林固件与科学上网插件安装教程](sources/网件rax50路由器刷梅林固件与科学上网插件安装教程.md) +- [2026-04-21] [MySQL MariaDB 数据库详细信息](sources/mysql-mariadb-数据库详细信息.md) +- [2026-04-21] [Ubuntu服务器通过rsync实现日常增量备份](sources/ubuntu服务器通过rsync实现日常增量备份.md) +- [2026-04-21] [Linux 运维必会的 150 个命令](sources/linux-运维必会的-150-个命令.md) +- [2026-04-21] [用Docker中安装Navidrome](sources/用docker中安装navidrome.md) +- [2026-04-21] [Cloud Operating Model: Key Strategies and Best Practices](sources/cloud-operating-model-key-strategies-and-best-practices.md) +- [2026-04-21] [What is DevSecOps? Best Practices, Benefits, and Tools](sources/what-is-devsecops-best-practices-benefits-and-tools.md) +- [2026-04-21] [Modern ITSM: Driving Efficiency, Security & Resilience](sources/understanding-complete-itsm.md) +- [2026-04-21] [How to Simplify Multi-Account Deployments Monitoring: Centralized Logs for AWS CloudFormation StackSets](sources/how-to-simplify-multi-account-deployments-monitoring-centralized-logs-for-aws-cloudformation-stacksets.md) +- [2026-04-21] [RTO vs RPO: Key Differences for Modern Disaster Recovery](sources/rto-vs-rpo-key-differences-for-modern-disaster-recovery.md) +- [2026-04-21] [These 6 Linux Apps Let You Monitor System Resources in Style](sources/these-6-linux-apps-let-you-monitor-system-resources-in-style.md) +- [2026-04-21] [Public vs Private vs Hybrid Cloud Differences Explained](sources/public-vs-private-vs-hybrid-cloud-differences-explained.md) +- [2026-04-21] [How Agentic AI can help for Cloud DevOps](sources/how-agentic-ai-can-help-for-cloud-devops.md) +- [2026-04-21] [The Myths and Misconceptions About Cloud Computing | LinkedIn](sources/the-myths-and-misconceptions-about-cloud-computing-linkedin.md) +- [2026-04-21] [Cloud Maturity Model - A Detailed Guide For Cloud Adoption](sources/cloud-maturity-model-a-detailed-guide-for-cloud-adoption.md) +- [2026-04-21] [DevOps Maturity Model From Traditional IT to Advanced DevOps](sources/devops-maturity-model-from-traditional-it-to-advanced-devops.md) +- [2026-04-21] [How Can a Multi Cloud Strategy Transform Your Business ROI?](sources/how-can-a-multi-cloud-strategy-transform-your-business-roi.md) +- [2026-04-21] [What I Know About Cloud Service Delivery 1](sources/what-i-know-about-cloud-service-delivery-1.md) +- [2026-04-21] [Cloud DevOp Maturity - Guideline](sources/cloud-devop-maturity-guideline.md) +- [2026-04-21] [DevOps Culture and Transformation: Fostering Collaboration, Agile Practices, and Innovation](sources/devops-culture-and-transformation-fostering-collaboration-agile-practices-and-innovation-linkedin.md) +- [2026-04-20] [security](sources/security.md) — (expected: wiki/sources/security.md — source missing) +- [2026-04-20] [llm-wiki](sources/llm-wiki.md) — (expected: wiki/sources/llm-wiki.md — source missing) +- [2026-04-20] [baoyu-skills](sources/baoyu-skills.md) — (expected: wiki/sources/baoyu-skills.md — source missing) +- [Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog](sources/Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog.md) — (expected: wiki/sources/Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog.md — source missing) +- [Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend](sources/Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend.md) — (expected: wiki/sources/Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend.md — source missing) +- [n8n-调用openclaw-agents的工作流架构](sources/n8n-调用openclaw-agents的工作流架构.md) — (expected: wiki/sources/n8n-调用openclaw-agents的工作流架构.md — source missing) +- [n8n-docker-配置-telegram-代理-troubleshooting](sources/n8n-docker-配置-telegram-代理-troubleshooting.md) — (expected: wiki/sources/n8n-docker-配置-telegram-代理-troubleshooting.md — source missing) +- [n8n调用hermes-agents的工作流架构](sources/n8n调用hermes-agents的工作流架构.md) — (expected: wiki/sources/n8n调用hermes-agents的工作流架构.md — source missing) +- [open-webui-hermes-agent](sources/open-webui-hermes-agent.md) — (expected: wiki/sources/open-webui-hermes-agent.md — source missing) +- [language-translator](sources/language-translator.md) — (expected: wiki/sources/language-translator.md — source missing) +- [loan-officer-assistant](sources/loan-officer-assistant.md) — (expected: wiki/sources/loan-officer-assistant.md — source missing) +- [real-estate-buyer-seller](sources/real-estate-buyer-seller.md) — (expected: wiki/sources/real-estate-buyer-seller.md — source missing) +- [legal-document-review](sources/legal-document-review.md) — (expected: wiki/sources/legal-document-review.md — source missing) +- [sales-outreach](sources/sales-outreach.md) — (expected: wiki/sources/sales-outreach.md — source missing) +- [retail-customer-returns](sources/retail-customer-returns.md) — (expected: wiki/sources/retail-customer-returns.md — source missing) +- [specialized-chief-of-staff](sources/specialized-chief-of-staff.md) — (expected: wiki/sources/specialized-chief-of-staff.md — source missing) +- [hr-onboarding](sources/hr-onboarding.md) — (expected: wiki/sources/hr-onboarding.md — source missing) +- [customer-service](sources/customer-service.md) — (expected: wiki/sources/customer-service.md — source missing) +- [healthcare-customer-service](sources/healthcare-customer-service.md) — (expected: wiki/sources/healthcare-customer-service.md — source missing) +- [legal-billing-time-tracking](sources/legal-billing-time-tracking.md) — (expected: wiki/sources/legal-billing-time-tracking.md — source missing) +- [legal-client-intake](sources/legal-client-intake.md) — (expected: wiki/sources/legal-client-intake.md — source missing) +- [hospitality-guest-services](sources/hospitality-guest-services.md) — (expected: wiki/sources/hospitality-guest-services.md — source missing) +- [Examples - Agency Multi-Agent Collaboration Showcase](sources/readme.md) +- [marketing-agentic-search-optimizer](sources/marketing-agentic-search-optimizer.md) — (expected: wiki/sources/marketing-agentic-search-optimizer.md — source missing) +- [Examples - Agency Multi-Agent Collaboration Showcase](sources/readme.md) +- [finance-bookkeeper-controller](sources/finance-bookkeeper-controller.md) — (expected: wiki/sources/finance-bookkeeper-controller.md — source missing) +- [finance-fpa-analyst](sources/finance-fpa-analyst.md) — (expected: wiki/sources/finance-fpa-analyst.md — source missing) +- [finance-investment-researcher](sources/finance-investment-researcher.md) — (expected: wiki/sources/finance-investment-researcher.md — source missing) +- [finance-financial-analyst](sources/finance-financial-analyst.md) — (expected: wiki/sources/finance-financial-analyst.md — source missing) +- [finance-tax-strategist](sources/finance-tax-strategist.md) — (expected: wiki/sources/finance-tax-strategist.md — source missing) +- [engineering-voice-ai-integration-engineer](sources/engineering-voice-ai-integration-engineer.md) — (expected: wiki/sources/engineering-voice-ai-integration-engineer.md — source missing) +- [engineering-codebase-onboarding-engineer](sources/engineering-codebase-onboarding-engineer.md) — (expected: wiki/sources/engineering-codebase-onboarding-engineer.md — source missing) +- [engineering-minimal-change-engineer](sources/engineering-minimal-change-engineer.md) — (expected: wiki/sources/engineering-minimal-change-engineer.md — source missing) +- [sre-weekly-issue-513](sources/sre-weekly-issue-513.md) — (expected: wiki/sources/sre-weekly-issue-513.md — source missing) +- [karpathy-最新分享-用-llm-搭建个人知识库-告别-rag-的低效循环](sources/karpathy-最新分享-用-llm-搭建个人知识库-告别-rag-的低效循环.md) — (expected: wiki/sources/karpathy-最新分享-用-llm-搭建个人知识库-告别-rag-的低效循环.md — source missing) +- [如何让ai生成风格一致的图片](sources/如何让ai生成风格一致的图片.md) — (expected: wiki/sources/如何让ai生成风格一致的图片.md — source missing) +- [scenario-startup-mvp](sources/scenario-startup-mvp.md) — (expected: wiki/sources/scenario-startup-mvp.md — source missing) +- [scenario-marketing-campaign](sources/scenario-marketing-campaign.md) — (expected: wiki/sources/scenario-marketing-campaign.md — source missing) +- [scenario-incident-response](sources/scenario-incident-response.md) — (expected: wiki/sources/scenario-incident-response.md — source missing) +- [scenario-enterprise-feature](sources/scenario-enterprise-feature.md) — (expected: wiki/sources/scenario-enterprise-feature.md — source missing) +- [phase-6-operate](sources/phase-6-operate.md) — (expected: wiki/sources/phase-6-operate.md — source missing) +- [phase-5-launch](sources/phase-5-launch.md) — (expected: wiki/sources/phase-5-launch.md — source missing) +- [phase-4-hardening](sources/phase-4-hardening.md) — (expected: wiki/sources/phase-4-hardening.md — source missing) +- [phase-3-build](sources/phase-3-build.md) — (expected: wiki/sources/phase-3-build.md — source missing) +- [phase-2-foundation](sources/phase-2-foundation.md) — (expected: wiki/sources/phase-2-foundation.md — source missing) +- [phase-1-strategy](sources/phase-1-strategy.md) — (expected: wiki/sources/phase-1-strategy.md — source missing) +- [phase-0-discovery](sources/phase-0-discovery.md) — (expected: wiki/sources/phase-0-discovery.md — source missing) +- [nexus-strategy](sources/nexus-strategy.md) — (expected: wiki/sources/nexus-strategy.md — source missing) +- [handoff-templates](sources/handoff-templates.md) — (expected: wiki/sources/handoff-templates.md — source missing) +- [agent-activation-prompts](sources/agent-activation-prompts.md) — (expected: wiki/sources/agent-activation-prompts.md — source missing) +- [quickstart](sources/quickstart.md) — (expected: wiki/sources/quickstart.md — source missing) +- [executive-brief](sources/executive-brief.md) — (expected: wiki/sources/executive-brief.md — source missing) +- [engineering-wechat-mini-program-developer](sources/engineering-wechat-mini-program-developer.md) — (expected: wiki/sources/engineering-wechat-mini-program-developer.md — source missing) +- [engineering-threat-detection-engineer](sources/engineering-threat-detection-engineer.md) — (expected: wiki/sources/engineering-threat-detection-engineer.md — source missing) +- [engineering-technical-writer](sources/engineering-technical-writer.md) — (expected: wiki/sources/engineering-technical-writer.md — source missing) +- [engineering-sre](sources/engineering-sre.md) — (expected: wiki/sources/engineering-sre.md — source missing) +- [engineering-solidity-smart-contract-engineer](sources/engineering-solidity-smart-contract-engineer.md) — (expected: wiki/sources/engineering-solidity-smart-contract-engineer.md — source missing) +- [engineering-senior-developer](sources/engineering-senior-developer.md) — (expected: wiki/sources/engineering-senior-developer.md — source missing) +- [engineering-security-engineer](sources/engineering-security-engineer.md) — (expected: wiki/sources/engineering-security-engineer.md — source missing) +- [engineering-rapid-prototyper](sources/engineering-rapid-prototyper.md) — (expected: wiki/sources/engineering-rapid-prototyper.md — source missing) +- [engineering-incident-response-commander](sources/engineering-incident-response-commander.md) — (expected: wiki/sources/engineering-incident-response-commander.md — source missing) +- [engineering-git-workflow-master](sources/engineering-git-workflow-master.md) — (expected: wiki/sources/engineering-git-workflow-master.md — source missing) +- [engineering-frontend-developer](sources/engineering-frontend-developer.md) — (expected: wiki/sources/engineering-frontend-developer.md — source missing) +- [engineering-filament-optimization-specialist](sources/engineering-filament-optimization-specialist.md) — (expected: wiki/sources/engineering-filament-optimization-specialist.md — source missing) +- [engineering-feishu-integration-developer](sources/engineering-feishu-integration-developer.md) — (expected: wiki/sources/engineering-feishu-integration-developer.md — source missing) +- [engineering-embedded-firmware-engineer](sources/engineering-embedded-firmware-engineer.md) — (expected: wiki/sources/engineering-embedded-firmware-engineer.md — source missing) +- [engineering-email-intelligence-engineer](sources/engineering-email-intelligence-engineer.md) — (expected: wiki/sources/engineering-email-intelligence-engineer.md — source missing) +- [engineering-devops-automator](sources/engineering-devops-automator.md) — (expected: wiki/sources/engineering-devops-automator.md — source missing) +- [engineering-database-optimizer](sources/engineering-database-optimizer.md) — (expected: wiki/sources/engineering-database-optimizer.md — source missing) +- [engineering-data-engineer](sources/engineering-data-engineer.md) — (expected: wiki/sources/engineering-data-engineer.md — source missing) +- [engineering-code-reviewer](sources/engineering-code-reviewer.md) — (expected: wiki/sources/engineering-code-reviewer.md — source missing) +- [engineering-cms-developer](sources/engineering-cms-developer.md) — (expected: wiki/sources/engineering-cms-developer.md — source missing) +- [engineering-backend-architect](sources/engineering-backend-architect.md) — (expected: wiki/sources/engineering-backend-architect.md — source missing) +- [engineering-ai-engineer](sources/engineering-ai-engineer.md) — (expected: wiki/sources/engineering-ai-engineer.md — source missing) +- [engineering-ai-data-remediation-engineer](sources/engineering-ai-data-remediation-engineer.md) — (expected: wiki/sources/engineering-ai-data-remediation-engineer.md — source missing) + +## Entities +- [Acemoglu](entities/Acemoglu.md) +- [ACI-318](entities/ACI-318.md) +- [Acronis](entities/Acronis.md) +- [AdamSmith](entities/AdamSmith.md) +- [ADK](entities/ADK.md) +- [Adobe-Premiere-Pro](entities/Adobe-Premiere-Pro.md) +- [AdsPower](entities/AdsPower.md) +- [Agentic-AI](entities/Agentic-AI.md) +- [AionUi](entities/AionUi.md) +- [AISC-360](entities/AISC-360.md) +- [aitmpl.com](entities/aitmpl.com.md) +- [Alertmanager](entities/Alertmanager.md) +- [Alex-Ewerlof](entities/Alex-Ewerlof.md) +- [Alex-Finn](entities/Alex-Finn.md) +- [Amazon-API-Gateway](entities/Amazon-API-Gateway.md) +- [Amazon-Aurora](entities/Amazon-Aurora.md) +- [Amazon-CloudWatch-Logs](entities/Amazon-CloudWatch-Logs.md) +- [Amazon-DocumentDB](entities/Amazon-DocumentDB.md) +- [Amazon-DynamoDB](entities/Amazon-DynamoDB.md) +- [Amazon-ElastiCache](entities/Amazon-ElastiCache.md) +- [Amazon-EventBridge](entities/Amazon-EventBridge.md) +- [Amazon-Keyspaces](entities/Amazon-Keyspaces.md) +- [Amazon-Neptune](entities/Amazon-Neptune.md) +- [Amazon-RDS](entities/Amazon-RDS.md) +- [Amazon-Redshift](entities/Amazon-Redshift.md) +- [Amazon-Timestream](entities/Amazon-Timestream.md) +- [AmazonAds](entities/AmazonAds.md) +- [Andrej-Karpathy](entities/Andrej-Karpathy.md) +- [Anthropic](entities/Anthropic.md) +- [Apache-Superset](entities/Apache-Superset.md) +- [Asana](entities/Asana.md) +- [ASCE-7](entities/ASCE-7.md) +- [Ashish](entities/Ashish.md) +- [Atlantis](entities/Atlantis.md) +- [AWS](entities/AWS.md) +- [AWS-CloudFormation-StackSets](entities/AWS-CloudFormation-StackSets.md) +- [AWS-Lambda](entities/AWS-Lambda.md) +- [AWS-OpenSearch](entities/AWS-OpenSearch.md) +- [AWS-Organizations](entities/AWS-Organizations.md) +- [AWS-Step-Functions](entities/AWS-Step-Functions.md) +- [Axton](entities/Axton.md) +- [Azure](entities/Azure.md) +- [Backend-Architect](entities/Backend-Architect.md) +- [BackendArchitect](entities/BackendArchitect.md) +- [Baidu](entities/Baidu.md) +- [baoyu](entities/baoyu.md) +- [BehavioralNudgeEngine](entities/BehavioralNudgeEngine.md) +- [bitwarden](entities/bitwarden.md) +- [blackbox-exporter](entities/blackbox-exporter.md) +- [BMC](entities/BMC.md) +- [BossZhipin](entities/BossZhipin.md) +- [Bottlerocket](entities/Bottlerocket.md) +- [bottom](entities/bottom.md) +- [Brendan-Starnig](entities/Brendan-Starnig.md) +- [btop++](entities/btop++.md) +- [Caddy](entities/Caddy.md) +- [cAdvisor](entities/cAdvisor.md) +- [Calibre](entities/Calibre.md) +- [Canva](entities/Canva.md) +- [CapCut-Pro](entities/CapCut-Pro.md) +- [ChatGPT](entities/ChatGPT.md) +- [Checkpoint](entities/Checkpoint.md) +- [ChinesePodcastPlatforms](entities/ChinesePodcastPlatforms.md) +- [Choi-Wontak](entities/Choi-Wontak.md) +- [Claude-Desktop](entities/Claude-Desktop.md) +- [Claude-Pro](entities/Claude-Pro.md) +- [ClawdTalk](entities/ClawdTalk.md) +- [ClawHub](entities/ClawHub.md) +- [clawr.ing](entities/clawr.ing.md) +- [Cline](entities/Cline.md) +- [Clonezilla](entities/Clonezilla.md) +- [cloud-computing](entities/cloud-computing.md) +- [Cloud-Maturity-Model](entities/Cloud-Maturity-Model.md) +- [Cloud-Provider](entities/Cloud-Provider.md) +- [clouddrive2](entities/clouddrive2.md) +- [CodeCrafters](entities/CodeCrafters.md) +- [CodeWeaver](entities/CodeWeaver.md) +- [containerd](entities/containerd.md) +- [Content-Creator](entities/Content-Creator.md) +- [Coze](entities/Coze.md) +- [CrewAI](entities/CrewAI.md) +- [Cursor](entities/Cursor.md) +- [Curve-Finance](entities/Curve-Finance.md) +- [DanielStefanovic](entities/DanielStefanovic.md) +- [DaVinci-Resolve](entities/DaVinci-Resolve.md) +- [DeepLearningAI](entities/DeepLearningAI.md) +- [DeepSeek](entities/DeepSeek.md) +- [DeepSider](entities/DeepSider.md) +- [DenchClaw](entities/DenchClaw.md) +- [DevOps-Maturity-Model](entities/DevOps-Maturity-Model.md) +- [Dify](entities/Dify.md) +- [docker-buildx-plugin](entities/docker-buildx-plugin.md) +- [docker-ce](entities/docker-ce.md) +- [docker-compose-plugin](entities/docker-compose-plugin.md) +- [Docker-Desktop](entities/Docker-Desktop.md) +- [docker-engine](entities/docker-engine.md) +- [Docker-Network](entities/Docker-Network.md) +- [Docker卷](entities/Docker卷.md) +- [DORA-Metrics](entities/DORA-Metrics.md) +- [Douyin](entities/Douyin.md) +- [DracoVibeCoding](entities/DracoVibeCoding.md) +- [DXC-VSM](entities/DXC-VSM.md) +- [DXY](entities/DXY.md) +- [EESJGong](entities/EESJGong.md) +- [Euler-Finance](entities/Euler-Finance.md) +- [Eurocode](entities/Eurocode.md) +- [Final-Cut-Pro](entities/Final-Cut-Pro.md) +- [fireworks-tech-graph](entities/fireworks-tech-graph.md) +- [Flux](entities/Flux.md) +- [FMOD](entities/FMOD.md) +- [Frontend-Developer](entities/Frontend-Developer.md) +- [frp](entities/frp.md) +- [Gamma-AI](entities/Gamma-AI.md) +- [GDPR](entities/GDPR.md) +- [Gemini](entities/Gemini.md) +- [Gitea](entities/Gitea.md) +- [GitHubCopilot](entities/GitHubCopilot.md) +- [Gitmoji](entities/Gitmoji.md) +- [glances](entities/glances.md) +- [gog](entities/gog.md) +- [gog-CLI](entities/gog-CLI.md) +- [Google](entities/Google.md) +- [Google-Cloud](entities/Google-Cloud.md) +- [GoogleAds](entities/GoogleAds.md) +- [GoogleCloud](entities/GoogleCloud.md) +- [GoogleGemini](entities/GoogleGemini.md) +- [Grafana](entities/Grafana.md) +- [Growth-Hacker](entities/Growth-Hacker.md) +- [Gruntwork](entities/Gruntwork.md) +- [HashiCorp](entities/HashiCorp.md) +- [Heather-Norris](entities/Heather-Norris.md) +- [hello-world](entities/hello-world.md) +- [HemantSawant](entities/HemantSawant.md) +- [HIPAA](entities/HIPAA.md) +- [HP-ZBook](entities/HP-ZBook.md) +- [htop](entities/htop.md) +- [HunyuanVideo](entities/HunyuanVideo.md) +- [IBM](entities/IBM.md) +- [idea-reality-mcp](entities/idea-reality-mcp.md) +- [InsightsLM](entities/InsightsLM.md) +- [Intelephense](entities/Intelephense.md) +- [Intsas.local](entities/Intsas.local.md) +- [ISO-27001](entities/ISO-27001.md) +- [it-tools](entities/it-tools.md) +- [Jared-Diamond](entities/Jared-Diamond.md) +- [Jay-Comer](entities/Jay-Comer.md) +- [Jellyfin](entities/Jellyfin.md) +- [Jira](entities/Jira.md) +- [Jira-Workflow-Steward](entities/Jira-Workflow-Steward.md) +- [JohnWilliams](entities/JohnWilliams.md) +- [K3s](entities/K3s.md) +- [KAI](entities/KAI.md) +- [KakaoTalk](entities/KakaoTalk.md) +- [kepano](entities/kepano.md) +- [KoolCenter固件服务器](entities/KoolCenter固件服务器.md) +- [Kuaishou](entities/Kuaishou.md) +- [Kubernetes](entities/Kubernetes.md) +- [LangChain](entities/LangChain.md) +- [LaunchDarkly](entities/LaunchDarkly.md) +- [LeonardoDaVinci](entities/LeonardoDaVinci.md) +- [Linear](entities/Linear.md) +- [LinkedIn-Campaign-Manager](entities/LinkedIn-Campaign-Manager.md) +- [LinuxServer.io](entities/LinuxServer.io.md) +- [LSIF](entities/LSIF.md) +- [Mac-Mini-M4](entities/Mac-Mini-M4.md) +- [Mackinder](entities/Mackinder.md) +- [macOS-Spatial-Metal-Engineer](entities/macOS-Spatial-Metal-Engineer.md) +- [Manus](entities/Manus.md) +- [MariaDB](entities/MariaDB.md) +- [Martin-Nash](entities/Martin-Nash.md) +- [MCP（Model Context Protocol）](entities/MCP（Model Context Protocol）.md) +- [Mem0](entities/Mem0.md) +- [Memsearch](entities/Memsearch.md) +- [MerlinClash插件](entities/MerlinClash插件.md) +- [Meta-Ads-Manager](entities/Meta-Ads-Manager.md) +- [Micro-Focus](entities/Micro-Focus.md) +- [Micro-Focus-IGA](entities/Micro-Focus-IGA.md) +- [Microsoft-Planner](entities/Microsoft-Planner.md) +- [MicrosoftAdvertising](entities/MicrosoftAdvertising.md) +- [Midjourney](entities/Midjourney.md) +- [Milvus](entities/Milvus.md) +- [MinIO](entities/MinIO.md) +- [mission-center](entities/mission-center.md) +- [n8n](entities/n8n.md) +- [n8n-mcp](entities/n8n-mcp.md) +- [Nano Banana 2](entities/Nano Banana 2.md) +- [Navidrome](entities/Navidrome.md) +- [NetApp](entities/NetApp.md) +- [NetcodeForGameObjects](entities/NetcodeForGameObjects.md) +- [Netdata](entities/Netdata.md) +- [Nexus-Spatial](entities/Nexus-Spatial.md) +- [NicholasCarlini](entities/NicholasCarlini.md) +- [Niklas-Luhmann](entities/Niklas-Luhmann.md) +- [NMPA](entities/NMPA.md) +- [node-exporter](entities/node-exporter.md) +- [Node.js](entities/Node.js.md) +- [nodewarden](entities/nodewarden.md) +- [Nomad-Bridge](entities/Nomad-Bridge.md) +- [NotebookLlama](entities/NotebookLlama.md) +- [NotebookLM](entities/NotebookLM.md) +- [Obsidian](entities/Obsidian.md) +- [OceanEngine](entities/OceanEngine.md) +- [Octane-Hub](entities/Octane-Hub.md) +- [Ollama](entities/Ollama.md) +- [Open-Alliance-for-Cloud-Adoption](entities/Open-Alliance-for-Cloud-Adoption.md) +- [Open-WebUI](entities/Open-WebUI.md) +- [OpenAI](entities/OpenAI.md) +- [OpenClaw](entities/OpenClaw.md) +- [openclaw-n8n-stack](entities/openclaw-n8n-stack.md) +- [OpenCode](entities/OpenCode.md) +- [OpenManus](entities/OpenManus.md) +- [OpenNotebook](entities/OpenNotebook.md) +- [OrchestratorAgent](entities/OrchestratorAgent.md) +- [PageLM](entities/PageLM.md) +- [Perplexica](entities/Perplexica.md) +- [Phenops-Team](entities/Phenops-Team.md) +- [PingMe](entities/PingMe.md) +- [Playwright](entities/Playwright.md) +- [Podcastfy](entities/Podcastfy.md) +- [Portainer](entities/Portainer.md) +- [Prismer-AI](entities/Prismer-AI.md) +- [Product-Security-Group](entities/Product-Security-Group.md) +- [Project-Management-Experiment-Tracker](entities/Project-Management-Experiment-Tracker.md) +- [Prometheus](entities/Prometheus.md) +- [Public-Cloud-Provider](entities/Public-Cloud-Provider.md) +- [Qdrant](entities/Qdrant.md) +- [Qwen](entities/Qwen.md) +- [RackNerd](entities/RackNerd.md) +- [RAIT-09](entities/RAIT-09.md) +- [Raj-Vardhan-Singh](entities/Raj-Vardhan-Singh.md) +- [Rapid-Prototyper](entities/Rapid-Prototyper.md) +- [Reality-Checker](entities/Reality-Checker.md) +- [Recapio](entities/Recapio.md) +- [RetroBoard](entities/RetroBoard.md) +- [RichardFeynman](entities/RichardFeynman.md) +- [rsvg-convert](entities/rsvg-convert.md) +- [rsync](entities/rsync.md) +- [Rufus](entities/Rufus.md) +- [RustDesk](entities/RustDesk.md) +- [SAM-Serverless-Application-Model](entities/SAM-Serverless-Application-Model.md) +- [SAMR](entities/SAMR.md) +- [SankarGopov](entities/SankarGopov.md) +- [shenwei](entities/shenwei.md) +- [Simon-Hoiberg](entities/Simon-Hoiberg.md) +- [Slack](entities/Slack.md) +- [SMACKS](entities/SMACKS.md) +- [SMACs](entities/SMACs.md) +- [SONY](entities/SONY.md) +- [SparkryAI](entities/SparkryAI.md) +- [Sprint-Prioritizer](entities/Sprint-Prioritizer.md) +- [SRE-Team](entities/SRE-Team.md) +- [Stable-Diffusion](entities/Stable-Diffusion.md) +- [stacer](entities/stacer.md) +- [Studio-Producer](entities/Studio-Producer.md) +- [Suravpul](entities/Suravpul.md) +- [SurfSense](entities/SurfSense.md) +- [Swinford.net](entities/Swinford.net.md) +- [Synology-NAS-DS718](entities/Synology-NAS-DS718.md) +- [Telnyx](entities/Telnyx.md) +- [Terraform](entities/Terraform.md) +- [Terragrunt](entities/Terragrunt.md) +- [The-Agency](entities/The-Agency.md) +- [The-DAO-2016](entities/The-DAO-2016.md) +- [Tiago-Forte](entities/Tiago-Forte.md) +- [TikTok-Ads](entities/TikTok-Ads.md) +- [tini](entities/tini.md) +- [Todoist](entities/Todoist.md) +- [Trae](entities/Trae.md) +- [TranscriptAPI](entities/TranscriptAPI.md) +- [Transmission](entities/Transmission.md) +- [TruffleHog](entities/TruffleHog.md) +- [tukuai](entities/tukuai.md) +- [TweetClaw](entities/TweetClaw.md) +- [TypeScript-Language-Server](entities/TypeScript-Language-Server.md) +- [Ubuntu-Server](entities/Ubuntu-Server.md) +- [UI-Designer](entities/UI-Designer.md) +- [UnityGamingServices](entities/UnityGamingServices.md) +- [UnityMultiplayerEngineer](entities/UnityMultiplayerEngineer.md) +- [UnrealEngine5](entities/UnrealEngine5.md) +- [UnrealMultiplayerArchitect](entities/UnrealMultiplayerArchitect.md) +- [Upload-Post](entities/Upload-Post.md) +- [Uptime-Kuma](entities/Uptime-Kuma.md) +- [UX-Researcher](entities/UX-Researcher.md) +- [Veeam](entities/Veeam.md) +- [Vibe-Kanban](entities/Vibe-Kanban.md) +- [VictoriaMetrics](entities/VictoriaMetrics.md) +- [Vinay](entities/Vinay.md) +- [VMware](entities/VMware.md) +- [WeChat](entities/WeChat.md) +- [WeCom](entities/WeCom.md) +- [Weibo](entities/Weibo.md) +- [WildCard](entities/WildCard.md) +- [Windsurf](entities/Windsurf.md) +- [Xiaohongshu](entities/Xiaohongshu.md) +- [XiaohongshuPlatform](entities/XiaohongshuPlatform.md) +- [Xiaoyuzhou](entities/Xiaoyuzhou.md) +- [Ximalaya](entities/Ximalaya.md) +- [XR-Cockpit-Interaction-Specialist](entities/XR-Cockpit-Interaction-Specialist.md) +- [XR-Immersive-Developer](entities/XR-Immersive-Developer.md) +- [XR-Interface-Architect](entities/XR-Interface-Architect.md) +- [YishenTu](entities/YishenTu.md) +- [YouTube](entities/YouTube.md) +- [Zhihu](entities/Zhihu.md) +- [Zipline](entities/Zipline.md) +- [zk-steward-companion](entities/zk-steward-companion.md) +- [余梦珑](entities/余梦珑.md) +- [剪映](entities/剪映.md) +- [机场](entities/机场.md) +- [梅林固件](entities/梅林固件.md) +- [滴滴](entities/滴滴.md) +- [盖伊亨德里克斯](entities/盖伊亨德里克斯.md) +- [矿神源](entities/矿神源.md) +- [网件RAX50](entities/网件RAX50.md) +- [苏东坡](entities/苏东坡.md) + +## Concepts +- [14种UML图](concepts/14种UML图.md) +- [3-2-1产品介绍公式](concepts/3-2-1产品介绍公式.md) +- [6-Slide-Narrative-Arc](concepts/6-Slide-Narrative-Arc.md) +- [7种视觉风格系统](concepts/7种视觉风格系统.md) +- [ABTesting](concepts/ABTesting.md) +- [Account-Health-Score](concepts/Account-Health-Score.md) +- [Account-Tiering-Model](concepts/Account-Tiering-Model.md) +- [AccountArchitecture](concepts/AccountArchitecture.md) +- [ActionItemTracking](concepts/ActionItemTracking.md) +- [Active-Accountability](concepts/Active-Accountability.md) +- [Actor-Replication](concepts/Actor-Replication.md) +- [Adaptive-Tone](concepts/Adaptive-Tone.md) +- [AdaptiveMusic](concepts/AdaptiveMusic.md) +- [ADDIE-Model](concepts/ADDIE-Model.md) +- [AdExtensions](concepts/AdExtensions.md) +- [AdStrength](concepts/AdStrength.md) +- [Advantage+-Campaigns](concepts/Advantage+-Campaigns.md) +- [Adversarial-Debate-Pattern](concepts/Adversarial-Debate-Pattern.md) +- [Agent-Build-Gate](concepts/Agent-Build-Gate.md) +- [Agent-Design-Principles](concepts/Agent-Design-Principles.md) +- [Agent-Driven-Market-Research](concepts/Agent-Driven-Market-Research.md) +- [Agent-Memory](concepts/Agent-Memory.md) +- [Agent-Mode](concepts/Agent-Mode.md) +- [Agent-Personality](concepts/Agent-Personality.md) +- [Agent-Routing-Rules](concepts/Agent-Routing-Rules.md) +- [Agent-Specialization](concepts/Agent-Specialization.md) +- [Agent-Template](concepts/Agent-Template.md) +- [AgentFileFormat](concepts/AgentFileFormat.md) +- [AGENTS.md](concepts/AGENTS.md.md) +- [Agile-Ceremonies](concepts/Agile-Ceremonies.md) +- [AgilePractices](concepts/AgilePractices.md) +- [Aha-Moment](concepts/Aha-Moment.md) +- [AI-Agent](concepts/AI-Agent.md) +- [AI-Assisted-Editing](concepts/AI-Assisted-Editing.md) +- [AI-Auto-Response](concepts/AI-Auto-Response.md) +- [AI-ChatOps](concepts/AI-ChatOps.md) +- [AI-Driven-Task-Extraction](concepts/AI-Driven-Task-Extraction.md) +- [AI-Logo-Generation](concepts/AI-Logo-Generation.md) +- [Ai-Powered-Digest](concepts/Ai-Powered-Digest.md) +- [AIFinOps](concepts/AIFinOps.md) +- [AIOps](concepts/AIOps.md) +- [AI代理](concepts/AI代理.md) +- [AI图生视频](concepts/AI图生视频.md) +- [AI开源平替](concepts/AI开源平替.md) +- [AI文生视频](concepts/AI文生视频.md) +- [AI簡報工作流](concepts/AI簡報工作流.md) +- [Alerting](concepts/Alerting.md) +- [Algorithm-Agility](concepts/Algorithm-Agility.md) +- [Amazon-EKS](concepts/Amazon-EKS.md) +- [AmbientMessageMonitoring](concepts/AmbientMessageMonitoring.md) +- [Analogy-as-Straitjacket](concepts/Analogy-as-Straitjacket.md) +- [Analytics-Feedback-Loop](concepts/Analytics-Feedback-Loop.md) +- [Annales-School](concepts/Annales-School.md) +- [Answer-Engine-Optimization](concepts/Answer-Engine-Optimization.md) +- [AntiCheatArchitecture](concepts/AntiCheatArchitecture.md) +- [Appearance-Anxiety](concepts/Appearance-Anxiety.md) +- [APT-仓库配置](concepts/APT-仓库配置.md) +- [Architectural-Empathy](concepts/Architectural-Empathy.md) +- [arXiv-API](concepts/arXiv-API.md) +- [Asset-Management](concepts/Asset-Management.md) +- [Asset-Pipeline](concepts/Asset-Pipeline.md) +- [Atomic-Commit](concepts/Atomic-Commit.md) +- [Attachment-Theory](concepts/Attachment-Theory.md) +- [Attach容器](concepts/Attach容器.md) +- [Attention-Economy](concepts/Attention-Economy.md) +- [Audit-Trail](concepts/Audit-Trail.md) +- [Automated-Health-Logging](concepts/Automated-Health-Logging.md) +- [Automated-Security-Audit](concepts/Automated-Security-Audit.md) +- [AutomationGovernance](concepts/AutomationGovernance.md) +- [Availability](concepts/Availability.md) +- [AWS-Secrets-Manager](concepts/AWS-Secrets-Manager.md) +- [AWS-Source-Identity](concepts/AWS-Source-Identity.md) +- [AWS-Tagging-Standards](concepts/AWS-Tagging-Standards.md) +- [AWS-Tags](concepts/AWS-Tags.md) +- [B2B-Social-Selling](concepts/B2B-Social-Selling.md) +- [Baidu-Ecosystem-Integration](concepts/Baidu-Ecosystem-Integration.md) +- [Baidu-SEO](concepts/Baidu-SEO.md) +- [BandwidthManagement](concepts/BandwidthManagement.md) +- [Beat-Sync](concepts/Beat-Sync.md) +- [BEATS](concepts/BEATS.md) +- [Behavioral-Psychology](concepts/Behavioral-Psychology.md) +- [Big-Five-Personality](concepts/Big-Five-Personality.md) +- [BindMount](concepts/BindMount.md) +- [BI平台](concepts/BI平台.md) +- [Blocking](concepts/Blocking.md) +- [Blockout-Discipline](concepts/Blockout-Discipline.md) +- [Bloom-认知分类](concepts/Bloom-认知分类.md) +- [Blue-Green-Deployment](concepts/Blue-Green-Deployment.md) +- [Blue-Hat-Logo](concepts/Blue-Hat-Logo.md) +- [BOOTSTRAP.md](concepts/BOOTSTRAP.md.md) +- [Brain-Dump](concepts/Brain-Dump.md) +- [Branch-Strategy](concepts/Branch-Strategy.md) +- [Branching-Narrative](concepts/Branching-Narrative.md) +- [Brand-Environment](concepts/Brand-Environment.md) +- [Break-the-Build](concepts/Break-the-Build.md) +- [Bug-Bounty](concepts/Bug-Bounty.md) +- [Build-Mode](concepts/Build-Mode.md) +- [Build-Your-Own-X](concepts/Build-Your-Own-X.md) +- [BuildInPublic](concepts/BuildInPublic.md) +- [Business-Impact-Analysis](concepts/Business-Impact-Analysis.md) +- [Business-Knowledge-Base](concepts/Business-Knowledge-Base.md) +- [CACandLTV](concepts/CACandLTV.md) +- [caffeinate](concepts/caffeinate.md) +- [Calibration-Testing](concepts/Calibration-Testing.md) +- [Call-Worthy-Threshold](concepts/Call-Worthy-Threshold.md) +- [Canary-Deployment](concepts/Canary-Deployment.md) +- [Canary-Release](concepts/Canary-Release.md) +- [Canvas](concepts/Canvas.md) +- [CAPA](concepts/CAPA.md) +- [Centralized-Logging](concepts/Centralized-Logging.md) +- [CEOPattern](concepts/CEOPattern.md) +- [Chained Agents](concepts/Chained Agents.md) +- [Challenger-Sales-Model](concepts/Challenger-Sales-Model.md) +- [Change-Failure-Rate](concepts/Change-Failure-Rate.md) +- [Change-Management](concepts/Change-Management.md) +- [Channel-Based-Monitoring](concepts/Channel-Based-Monitoring.md) +- [Character-Arc](concepts/Character-Arc.md) +- [Character-Voice-Pillars](concepts/Character-Voice-Pillars.md) +- [Check-in-Fatigue](concepts/Check-in-Fatigue.md) +- [ChinaLaborLawCompliance](concepts/ChinaLaborLawCompliance.md) +- [Choice-Architecture](concepts/Choice-Architecture.md) +- [CI-CD-Pipeline](concepts/CI-CD-Pipeline.md) +- [CICDPipeline](concepts/CICDPipeline.md) +- [CircuitBreaker](concepts/CircuitBreaker.md) +- [CIS-Benchmark](concepts/CIS-Benchmark.md) +- [Citation-Rate](concepts/Citation-Rate.md) +- [Claude-Code-Templates](concepts/Claude-Code-Templates.md) +- [Claude-Skills](concepts/Claude-Skills.md) +- [Claudian](concepts/Claudian.md) +- [ClientPrediction](concepts/ClientPrediction.md) +- [Cloud-Adoption-Strategy](concepts/Cloud-Adoption-Strategy.md) +- [Cloud-Cost-Optimization](concepts/Cloud-Cost-Optimization.md) +- [Cloud-DevOps-Maturity-Model](concepts/Cloud-DevOps-Maturity-Model.md) +- [Cloud-Governance](concepts/Cloud-Governance.md) +- [Cloud-Maturity-Levels](concepts/Cloud-Maturity-Levels.md) +- [cloud-migration](concepts/cloud-migration.md) +- [Cloud-Monitoring](concepts/Cloud-Monitoring.md) +- [Cloud-Native](concepts/Cloud-Native.md) +- [Cloud-Native-Maturity-Model](concepts/Cloud-Native-Maturity-Model.md) +- [Cloud-Operating-Model](concepts/Cloud-Operating-Model.md) +- [cloud-security](concepts/cloud-security.md) +- [Cloud-Security-Maturity-Model](concepts/Cloud-Security-Maturity-Model.md) +- [Cloud-Service-Delivery](concepts/Cloud-Service-Delivery.md) +- [Cluster-Autoscaler](concepts/Cluster-Autoscaler.md) +- [CMDB](concepts/CMDB.md) +- [Cockpit-Ergonomics](concepts/Cockpit-Ergonomics.md) +- [CodeWeaver](concepts/CodeWeaver.md) +- [Cognitive-Distortions](concepts/Cognitive-Distortions.md) +- [Cognitive-Load-Reduction](concepts/Cognitive-Load-Reduction.md) +- [Color-Grading](concepts/Color-Grading.md) +- [Columnar-Storage](concepts/Columnar-Storage.md) +- [Command-Theater-Interface](concepts/Command-Theater-Interface.md) +- [Community-Credibility](concepts/Community-Credibility.md) +- [Compaction](concepts/Compaction.md) +- [Competition-Analysis](concepts/Competition-Analysis.md) +- [CompletionRate](concepts/CompletionRate.md) +- [Compliance-Automation](concepts/Compliance-Automation.md) +- [Compliance-Risk-Matrix](concepts/Compliance-Risk-Matrix.md) +- [Confidence-Score](concepts/Confidence-Score.md) +- [Configuration-Management](concepts/Configuration-Management.md) +- [Consensus-Voting-Pattern](concepts/Consensus-Voting-Pattern.md) +- [Constraint-Driven-Control-Mechanics](concepts/Constraint-Driven-Control-Mechanics.md) +- [Container-Lifecycle-Hardening](concepts/Container-Lifecycle-Hardening.md) +- [Content Automation](concepts/Content Automation.md) +- [Content-60-30-10-Rule](concepts/Content-60-30-10-Rule.md) +- [Content-Creator](concepts/Content-Creator.md) +- [Content-Hashing](concepts/Content-Hashing.md) +- [Content-Ingestion](concepts/Content-Ingestion.md) +- [Content-Matrix-Strategy](concepts/Content-Matrix-Strategy.md) +- [Content-Pillar](concepts/Content-Pillar.md) +- [ContentMixStrategy](concepts/ContentMixStrategy.md) +- [Context-Passing](concepts/Context-Passing.md) +- [Context-Substrate](concepts/Context-Substrate.md) +- [Context-Window](concepts/Context-Window.md) +- [Continuous-Delivery](concepts/Continuous-Delivery.md) +- [Continuous-Deployment](concepts/Continuous-Deployment.md) +- [Continuous-Integration](concepts/Continuous-Integration.md) +- [Conversational-Interface](concepts/Conversational-Interface.md) +- [Conversions-API](concepts/Conversions-API.md) +- [Core-Gameplay-Loop](concepts/Core-Gameplay-Loop.md) +- [Cost-Optimization](concepts/Cost-Optimization.md) +- [CoworkWorkspace](concepts/CoworkWorkspace.md) +- [Coze-Workflow](concepts/Coze-Workflow.md) +- [CreativeFatigue](concepts/CreativeFatigue.md) +- [Credential-Isolation](concepts/Credential-Isolation.md) +- [Credit-Efficient-Processing](concepts/Credit-Efficient-Processing.md) +- [Cron定时任务](concepts/Cron定时任务.md) +- [Cross-Account-Monitoring](concepts/Cross-Account-Monitoring.md) +- [Cross-account-Terraform-Modules](concepts/Cross-account-Terraform-Modules.md) +- [Cross-Platform-Strategy](concepts/Cross-Platform-Strategy.md) +- [Cumulative-Memory](concepts/Cumulative-Memory.md) +- [Custom-Audience-Engineering](concepts/Custom-Audience-Engineering.md) +- [Custom-Instructions](concepts/Custom-Instructions.md) +- [Daily-Digest](concepts/Daily-Digest.md) +- [Daily-Log](concepts/Daily-Log.md) +- [DarkLaunching](concepts/DarkLaunching.md) +- [DAST](concepts/DAST.md) +- [Data-Governance](concepts/Data-Governance.md) +- [Data-Sovereignty](concepts/Data-Sovereignty.md) +- [DBA-Role-Evolution](concepts/DBA-Role-Evolution.md) +- [DealHealthScoring](concepts/DealHealthScoring.md) +- [Debugging-Visualization](concepts/Debugging-Visualization.md) +- [DecisionFramework](concepts/DecisionFramework.md) +- [Default-Bias](concepts/Default-Bias.md) +- [Defense-in-Depth](concepts/Defense-in-Depth.md) +- [Defense-Mechanisms](concepts/Defense-Mechanisms.md) +- [Defuddle](concepts/Defuddle.md) +- [Delegation-Chain](concepts/Delegation-Chain.md) +- [Delivery-Traceability](concepts/Delivery-Traceability.md) +- [Demo-Engineering](concepts/Demo-Engineering.md) +- [Dengbao-2.0](concepts/Dengbao-2.0.md) +- [Dependency-Management](concepts/Dependency-Management.md) +- [Deployment-Automation](concepts/Deployment-Automation.md) +- [Deployment-vs-Release](concepts/Deployment-vs-Release.md) +- [Design-Thinking](concepts/Design-Thinking.md) +- [Design-to-Code-Workflow](concepts/Design-to-Code-Workflow.md) +- [DevOps-Maturity](concepts/DevOps-Maturity.md) +- [DevOpsCulture](concepts/DevOpsCulture.md) +- [DevSecOps](concepts/DevSecOps.md) +- [Dialogue-Writing-Standards](concepts/Dialogue-Writing-Standards.md) +- [Discrimination-Metrics](concepts/Discrimination-Metrics.md) +- [DKIM-Email-Authentication](concepts/DKIM-Email-Authentication.md) +- [dm-verity](concepts/dm-verity.md) +- [DNS托管](concepts/DNS托管.md) +- [Docker-Compose](concepts/Docker-Compose.md) +- [Docker-Containerization](concepts/Docker-Containerization.md) +- [Docker-LLM-Deployment](concepts/Docker-LLM-Deployment.md) +- [Docker-用户组](concepts/Docker-用户组.md) +- [Docker堆栈](concepts/Docker堆栈.md) +- [Docker容器生命周期管理](concepts/Docker容器生命周期管理.md) +- [Docker警告处理](concepts/Docker警告处理.md) +- [Domain-Thinking](concepts/Domain-Thinking.md) +- [DORA-Metrics](concepts/DORA-Metrics.md) +- [DRaaS](concepts/DRaaS.md) +- [DRY-Principle](concepts/DRY-Principle.md) +- [DRY原则](concepts/DRY原则.md) +- [DuckDB](concepts/DuckDB.md) +- [Dynamic-Dashboard](concepts/Dynamic-Dashboard.md) +- [Early-Live-Support](concepts/Early-Live-Support.md) +- [Earnings-Beat-Miss](concepts/Earnings-Beat-Miss.md) +- [Earnings-Calendar](concepts/Earnings-Calendar.md) +- [EC2-Purchase-Options](concepts/EC2-Purchase-Options.md) +- [Economy-Balance](concepts/Economy-Balance.md) +- [efibootmgr](concepts/efibootmgr.md) +- [EFS-vs-EBS](concepts/EFS-vs-EBS.md) +- [EKS-Auto-Mode](concepts/EKS-Auto-Mode.md) +- [ELK-Stack](concepts/ELK-Stack.md) +- [Email-Triage](concepts/Email-Triage.md) +- [Emergency-Change](concepts/Emergency-Change.md) +- [Employee-Advocacy](concepts/Employee-Advocacy.md) +- [emptyDir-Volume](concepts/emptyDir-Volume.md) +- [Encounter-Design](concepts/Encounter-Design.md) +- [Enterprise-Architecture](concepts/Enterprise-Architecture.md) +- [Entity-Optimization](concepts/Entity-Optimization.md) +- [Environmental-Determinism](concepts/Environmental-Determinism.md) +- [Environmental-Storytelling](concepts/Environmental-Storytelling.md) +- [Error-Accountability](concepts/Error-Accountability.md) +- [Error-Budget](concepts/Error-Budget.md) +- [Error-Surface-vs-Root-Cause](concepts/Error-Surface-vs-Root-Cause.md) +- [ESN](concepts/ESN.md) +- [Event-Correlation](concepts/Event-Correlation.md) +- [Event-Driven-Architecture](concepts/Event-Driven-Architecture.md) +- [EventSourcing](concepts/EventSourcing.md) +- [Evidence-based-Merge-Proposal](concepts/Evidence-based-Merge-Proposal.md) +- [Evidence-Chain](concepts/Evidence-Chain.md) +- [Expert-User-Assumption](concepts/Expert-User-Assumption.md) +- [Exporter](concepts/Exporter.md) +- [Extended Thinking](concepts/Extended Thinking.md) +- [external配置](concepts/external配置.md) +- [Fabula-Sjuzhet](concepts/Fabula-Sjuzhet.md) +- [Fail-Closed](concepts/Fail-Closed.md) +- [Failover](concepts/Failover.md) +- [Feature-Flag](concepts/Feature-Flag.md) +- [FeatureList](concepts/FeatureList.md) +- [Federated-Access](concepts/Federated-Access.md) +- [Feedback-Loop](concepts/Feedback-Loop.md) +- [FIA-Framework](concepts/FIA-Framework.md) +- [File-System-First-UI](concepts/File-System-First-UI.md) +- [File-Watcher](concepts/File-Watcher.md) +- [FinOps](concepts/FinOps.md) +- [Five-Phase-Script-Framework](concepts/Five-Phase-Script-Framework.md) +- [Fix-Pack](concepts/Fix-Pack.md) +- [Fixed-Point-Semantics](concepts/Fixed-Point-Semantics.md) +- [Flow-And-Readability](concepts/Flow-And-Readability.md) +- [Food-Sensitivity-Tracking](concepts/Food-Sensitivity-Tracking.md) +- [Full-Draft-Generation](concepts/Full-Draft-Generation.md) +- [Full-Funnel-Campaign-Architecture](concepts/Full-Funnel-Campaign-Architecture.md) +- [Fuzzy-Matching](concepts/Fuzzy-Matching.md) +- [Gamification](concepts/Gamification.md) +- [GAS-Gameplay-Ability-System](concepts/GAS-Gameplay-Ability-System.md) +- [Gatekeeper](concepts/Gatekeeper.md) +- [GDM3](concepts/GDM3.md) +- [Gegenrede](concepts/Gegenrede.md) +- [Generalist](concepts/Generalist.md) +- [Generation](concepts/Generation.md) +- [Generative-Engine-Optimization](concepts/Generative-Engine-Optimization.md) +- [Generator](concepts/Generator.md) +- [Generator-Space](concepts/Generator-Space.md) +- [Genetic-Algorithm](concepts/Genetic-Algorithm.md) +- [Geographic-Coherence](concepts/Geographic-Coherence.md) +- [GitAsAuditLog](concepts/GitAsAuditLog.md) +- [GitHub-Release-Monitoring](concepts/GitHub-Release-Monitoring.md) +- [Gitmoji-Commit](concepts/Gitmoji-Commit.md) +- [GitOps](concepts/GitOps.md) +- [Global-First-Architecture](concepts/Global-First-Architecture.md) +- [Golden-3-Second-Hook](concepts/Golden-3-Second-Hook.md) +- [GPG-密钥验证](concepts/GPG-密钥验证.md) +- [Grandes-Ecoles](concepts/Grandes-Ecoles.md) +- [Green-Computing](concepts/Green-Computing.md) +- [Growth-Loop](concepts/Growth-Loop.md) +- [GrowthFunnelOptimization](concepts/GrowthFunnelOptimization.md) +- [Hand-Tracking](concepts/Hand-Tracking.md) +- [Handoff-Contract](concepts/Handoff-Contract.md) +- [HCX](concepts/HCX.md) +- [Headless-服务器](concepts/Headless-服务器.md) +- [Healthcare-Marketing-Compliance](concepts/Healthcare-Marketing-Compliance.md) +- [Heartbeat-Monitoring](concepts/Heartbeat-Monitoring.md) +- [Hidden-Failure-Paths](concepts/Hidden-Failure-Paths.md) +- [Hierarchy-Agent-Pattern](concepts/Hierarchy-Agent-Pattern.md) +- [high-availability](concepts/high-availability.md) +- [Holistic-Admissions](concepts/Holistic-Admissions.md) +- [HookBodyCTA](concepts/HookBodyCTA.md) +- [Hosmer-Lemeshow-Test](concepts/Hosmer-Lemeshow-Test.md) +- [Host-Incubation-System](concepts/Host-Incubation-System.md) +- [HouseholdInventoryTracking](concepts/HouseholdInventoryTracking.md) +- [HTTPS自动化证书](concepts/HTTPS自动化证书.md) +- [Human-Centered-Design](concepts/Human-Centered-Design.md) +- [Human-Handoff](concepts/Human-Handoff.md) +- [Hybrid-Cloud](concepts/Hybrid-Cloud.md) +- [Hybrid-Search](concepts/Hybrid-Search.md) +- [HybridDnsResolution](concepts/HybridDnsResolution.md) +- [Hyperautomation](concepts/Hyperautomation.md) +- [IANG-Visa](concepts/IANG-Visa.md) +- [IAST](concepts/IAST.md) +- [ICP-Filing](concepts/ICP-Filing.md) +- [ICP-Ideal-Customer-Profile](concepts/ICP-Ideal-Customer-Profile.md) +- [Idea-Density](concepts/Idea-Density.md) +- [Idea-Museum](concepts/Idea-Museum.md) +- [Identity-Governance](concepts/Identity-Governance.md) +- [Identity-Resolution](concepts/Identity-Resolution.md) +- [IDENTITY.md](concepts/IDENTITY.md.md) +- [Ikigai框架](concepts/Ikigai框架.md) +- [Immutable-Infrastructure](concepts/Immutable-Infrastructure.md) +- [Immutable-Root-Filesystem](concepts/Immutable-Root-Filesystem.md) +- [Incident-Management](concepts/Incident-Management.md) +- [InclusiveVisuals](concepts/InclusiveVisuals.md) +- [Incremental-Graph-Update](concepts/Incremental-Graph-Update.md) +- [Incrementality-Testing](concepts/Incrementality-Testing.md) +- [Indexing](concepts/Indexing.md) +- [Infrastructure-as-Code](concepts/Infrastructure-as-Code.md) +- [Innovation-Pipeline](concepts/Innovation-Pipeline.md) +- [IntegrationGovernance](concepts/IntegrationGovernance.md) +- [Intent-Classification](concepts/Intent-Classification.md) +- [Intentional-Cloud-Strategy](concepts/Intentional-Cloud-Strategy.md) +- [Inversion](concepts/Inversion.md) +- [Invisible-Exclusion](concepts/Invisible-Exclusion.md) +- [IP纯净度](concepts/IP纯净度.md) +- [ISOHybrid镜像](concepts/ISOHybrid镜像.md) +- [ITSM](concepts/ITSM.md) +- [ITSM-2.0](concepts/ITSM-2.0.md) +- [JFFS双清](concepts/JFFS双清.md) +- [Jira-Gate](concepts/Jira-Gate.md) +- [Jira-Git-Traceability](concepts/Jira-Git-Traceability.md) +- [Kaizen](concepts/Kaizen.md) +- [Kanban](concepts/Kanban.md) +- [Karpman-Drama-Triangle](concepts/Karpman-Drama-Triangle.md) +- [Keyword-Based-Monitoring](concepts/Keyword-Based-Monitoring.md) +- [KFactor](concepts/KFactor.md) +- [Kill-Switch](concepts/Kill-Switch.md) +- [Kirkpatrick-四级评估](concepts/Kirkpatrick-四级评估.md) +- [Knock-out-Pattern](concepts/Knock-out-Pattern.md) +- [Knowledge-Base-RAG](concepts/Knowledge-Base-RAG.md) +- [Kolb-体验式学习圈](concepts/Kolb-体验式学习圈.md) +- [Kubernetes](concepts/Kubernetes.md) +- [LagCompensation](concepts/LagCompensation.md) +- [Land-and-Expand](concepts/Land-and-Expand.md) +- [Landing-Zone-Architecture](concepts/Landing-Zone-Architecture.md) +- [LangChain](concepts/LangChain.md) +- [Language-Detection](concepts/Language-Detection.md) +- [Large-Language-Model](concepts/Large-Language-Model.md) +- [LargeWorldCoordinates](concepts/LargeWorldCoordinates.md) +- [Last-30-Days-Method](concepts/Last-30-Days-Method.md) +- [LaTeX-Flattening](concepts/LaTeX-Flattening.md) +- [launchd](concepts/launchd.md) +- [Layered-Configuration](concepts/Layered-Configuration.md) +- [Lead-Generation-Funnel](concepts/Lead-Generation-Funnel.md) +- [Lead-Time](concepts/Lead-Time.md) +- [Lean](concepts/Lean.md) +- [Learn-By-Building](concepts/Learn-By-Building.md) +- [Left-over-Principle](concepts/Left-over-Principle.md) +- [Link-Proposer](concepts/Link-Proposer.md) +- [Liquid-Glass-Design-System](concepts/Liquid-Glass-Design-System.md) +- [LLM-Wiki](concepts/LLM-Wiki.md) +- [LLMasJudge](concepts/LLMasJudge.md) +- [Local-Caching](concepts/Local-Caching.md) +- [Local-first-Git](concepts/Local-first-Git.md) +- [Local-LLM-Deployment](concepts/Local-LLM-Deployment.md) +- [Lockable-Workflow](concepts/Lockable-Workflow.md) +- [LOD](concepts/LOD.md) +- [LOD-Pipeline](concepts/LOD-Pipeline.md) +- [Log-Driven-Debugging](concepts/Log-Driven-Debugging.md) +- [Longue-Duree](concepts/Longue-Duree.md) +- [Lore-Architecture](concepts/Lore-Architecture.md) +- [Lost-Prompt-Analysis](concepts/Lost-Prompt-Analysis.md) +- [LSP-317-Specification](concepts/LSP-317-Specification.md) +- [Luhmann-四原则](concepts/Luhmann-四原则.md) +- [Mackinder-Heartland-Theory](concepts/Mackinder-Heartland-Theory.md) +- [Management-Pack](concepts/Management-Pack.md) +- [Marketing-Attribution](concepts/Marketing-Attribution.md) +- [MaterialFunction](concepts/MaterialFunction.md) +- [MCPOnceAllAgents](concepts/MCPOnceAllAgents.md) +- [MEDDPICC](concepts/MEDDPICC.md) +- [Medical-Advertisement-Review](concepts/Medical-Advertisement-Review.md) +- [MeetingNotes](concepts/MeetingNotes.md) +- [Memory-Backend](concepts/Memory-Backend.md) +- [Memory-Based-Handoff](concepts/Memory-Based-Handoff.md) +- [MEMORY.md](concepts/MEMORY.md.md) +- [Merge-Point](concepts/Merge-Point.md) +- [MessageMatch](concepts/MessageMatch.md) +- [Micro-Recovery](concepts/Micro-Recovery.md) +- [MicroInfluencerPartnership](concepts/MicroInfluencerPartnership.md) +- [Miping](concepts/Miping.md) +- [Model-Context-Protocol](concepts/Model-Context-Protocol.md) +- [Model-Fallback](concepts/Model-Fallback.md) +- [Momentum-Nudge](concepts/Momentum-Nudge.md) +- [Morning-Briefing](concepts/Morning-Briefing.md) +- [Motion-Sickness-Threshold](concepts/Motion-Sickness-Threshold.md) +- [MPP](concepts/MPP.md) +- [MTTA](concepts/MTTA.md) +- [MTTD](concepts/MTTD.md) +- [MTTR](concepts/MTTR.md) +- [Multi-Account-Deployment](concepts/Multi-Account-Deployment.md) +- [Multi-Agent-Orchestration](concepts/Multi-Agent-Orchestration.md) +- [Multi-AgentHub](concepts/Multi-AgentHub.md) +- [Multi-AI-Review](concepts/Multi-AI-Review.md) +- [Multi-Channel-Delivery](concepts/Multi-Channel-Delivery.md) +- [Multi-Channel-Sequence-Architecture](concepts/Multi-Channel-Sequence-Architecture.md) +- [Multi-Cloud-Strategy](concepts/Multi-Cloud-Strategy.md) +- [Multi-Database-Architecture](concepts/Multi-Database-Architecture.md) +- [Multi-factor-Authentication](concepts/Multi-factor-Authentication.md) +- [Multi-Tenancy](concepts/Multi-Tenancy.md) +- [Multi-Window-Architecture](concepts/Multi-Window-Architecture.md) +- [N8nWorkflowStandard](concepts/N8nWorkflowStandard.md) +- [Nanite](concepts/Nanite.md) +- [Narrative-Debt](concepts/Narrative-Debt.md) +- [Narrative-Debt-Tracking](concepts/Narrative-Debt-Tracking.md) +- [Narrative-Gameplay-Integration](concepts/Narrative-Gameplay-Integration.md) +- [nas套件管理](concepts/nas套件管理.md) +- [National-Annex](concepts/National-Annex.md) +- [NegativePromptingLibrary](concepts/NegativePromptingLibrary.md) +- [Net-Revenue-Retention](concepts/Net-Revenue-Retention.md) +- [Network-Prediction](concepts/Network-Prediction.md) +- [NetworkVariable](concepts/NetworkVariable.md) +- [NFS网络备份](concepts/NFS网络备份.md) +- [NiagaraVFX](concepts/NiagaraVFX.md) +- [Nitro-System](concepts/Nitro-System.md) +- [Normal-Change](concepts/Normal-Change.md) +- [NorthStarMetric](concepts/NorthStarMetric.md) +- [Nunchi](concepts/Nunchi.md) +- [NVMe硬盘分区](concepts/NVMe硬盘分区.md) +- [Observable-States](concepts/Observable-States.md) +- [Obsidian-Agent-Client](concepts/Obsidian-Agent-Client.md) +- [Obsidian-Bases](concepts/Obsidian-Bases.md) +- [Obsidian-CLI](concepts/Obsidian-CLI.md) +- [Obsidian-Tasks](concepts/Obsidian-Tasks.md) +- [OpenTelemetry](concepts/OpenTelemetry.md) +- [Oracle-Manipulation](concepts/Oracle-Manipulation.md) +- [Organic-Traffic-Amplification](concepts/Organic-Traffic-Amplification.md) +- [OWASP-Top-Ten](concepts/OWASP-Top-Ten.md) +- [Pacing-Architecture](concepts/Pacing-Architecture.md) +- [Pain-Point-Mining](concepts/Pain-Point-Mining.md) +- [Paper-Abstract-Batch-Fetching](concepts/Paper-Abstract-Batch-Fetching.md) +- [Parallel-Agent-Execution](concepts/Parallel-Agent-Execution.md) +- [Parallel-Agent-Work](concepts/Parallel-Agent-Work.md) +- [Parallel-Kickoff](concepts/Parallel-Kickoff.md) +- [Partial-Dependence-Plots](concepts/Partial-Dependence-Plots.md) +- [Partition-Updates](concepts/Partition-Updates.md) +- [Passive-Learning](concepts/Passive-Learning.md) +- [passkey](concepts/passkey.md) +- [Patient-Privacy-PIPL](concepts/Patient-Privacy-PIPL.md) +- [Pay-as-you-go](concepts/Pay-as-you-go.md) +- [PCG](concepts/PCG.md) +- [Peer-Verification](concepts/Peer-Verification.md) +- [Penetration-Testing](concepts/Penetration-Testing.md) +- [Performance-Budget](concepts/Performance-Budget.md) +- [Performance-Contracts](concepts/Performance-Contracts.md) +- [PerformanceMax](concepts/PerformanceMax.md) +- [Personal-CRM](concepts/Personal-CRM.md) +- [Personalization](concepts/Personalization.md) +- [PersuasionArchitecture](concepts/PersuasionArchitecture.md) +- [Pipeline](concepts/Pipeline.md) +- [PipelineVelocity](concepts/PipelineVelocity.md) +- [Pivot-Strategy](concepts/Pivot-Strategy.md) +- [Plan-Mode](concepts/Plan-Mode.md) +- [PMDelegationPattern](concepts/PMDelegationPattern.md) +- [pmset](concepts/pmset.md) +- [POC-Scoping](concepts/POC-Scoping.md) +- [Pod-Security-Context](concepts/Pod-Security-Context.md) +- [PodcastPositioning](concepts/PodcastPositioning.md) +- [Policy-as-Code](concepts/Policy-as-Code.md) +- [Pomodoro-Technique](concepts/Pomodoro-Technique.md) +- [Population-Stability-Index](concepts/Population-Stability-Index.md) +- [Portage-Salarial](concepts/Portage-Salarial.md) +- [Portfolio-ROI](concepts/Portfolio-ROI.md) +- [Post-Processing](concepts/Post-Processing.md) +- [PRD生成工作流](concepts/PRD生成工作流.md) +- [Pre-Build-Validation](concepts/Pre-Build-Validation.md) +- [Predictive-Maintenance](concepts/Predictive-Maintenance.md) +- [Private-Cloud](concepts/Private-Cloud.md) +- [Private-Context](concepts/Private-Context.md) +- [Proactive-Agent-Recommendation](concepts/Proactive-Agent-Recommendation.md) +- [Proactive-AI](concepts/Proactive-AI.md) +- [Problem-Management](concepts/Problem-Management.md) +- [Procedural-Level-Design](concepts/Procedural-Level-Design.md) +- [process-management](concepts/process-management.md) +- [ProductLedGrowth](concepts/ProductLedGrowth.md) +- [Progressive-Rollout](concepts/Progressive-Rollout.md) +- [ProjectState](concepts/ProjectState.md) +- [Prometheus告警规则](concepts/Prometheus告警规则.md) +- [PromQL](concepts/PromQL.md) +- [Propp-Morphology](concepts/Propp-Morphology.md) +- [Proxy-Editing](concepts/Proxy-Editing.md) +- [proxychains](concepts/proxychains.md) +- [Public-Cloud](concepts/Public-Cloud.md) +- [PUID-PGID](concepts/PUID-PGID.md) +- [Pull-Request-Governance](concepts/Pull-Request-Governance.md) +- [Purpose-Built-Databases](concepts/Purpose-Built-Databases.md) +- [Quality-Gate](concepts/Quality-Gate.md) +- [Quality-Scoring-Algorithm](concepts/Quality-Scoring-Algorithm.md) +- [QualityAdjustedCoverage](concepts/QualityAdjustedCoverage.md) +- [QualitySwitch](concepts/QualitySwitch.md) +- [RAG](concepts/RAG.md) +- [Reality-Signal](concepts/Reality-Signal.md) +- [RealityKit-SwiftUI-Integration](concepts/RealityKit-SwiftUI-Integration.md) +- [ReAuditTriggers](concepts/ReAuditTriggers.md) +- [Reciprocal-Rank-Fusion](concepts/Reciprocal-Rank-Fusion.md) +- [RecruitmentFunnelAnalyzer](concepts/RecruitmentFunnelAnalyzer.md) +- [Recurring-Task](concepts/Recurring-Task.md) +- [Recurring-Tasks](concepts/Recurring-Tasks.md) +- [Recursive-Self-Optimization](concepts/Recursive-Self-Optimization.md) +- [Redis缓存](concepts/Redis缓存.md) +- [Reentrancy](concepts/Reentrancy.md) +- [Reference-Architecture](concepts/Reference-Architecture.md) +- [Release-Management](concepts/Release-Management.md) +- [Reliability-Engineering](concepts/Reliability-Engineering.md) +- [ReliabilityBaseline](concepts/ReliabilityBaseline.md) +- [Remote-SSH](concepts/Remote-SSH.md) +- [RemoteDevelopment](concepts/RemoteDevelopment.md) +- [RemoteRescuePattern](concepts/RemoteRescuePattern.md) +- [Renovate-Bot](concepts/Renovate-Bot.md) +- [Replication-Graph](concepts/Replication-Graph.md) +- [Resource-Allocation](concepts/Resource-Allocation.md) +- [ResponsiveSearchAds](concepts/ResponsiveSearchAds.md) +- [Retrieval](concepts/Retrieval.md) +- [Reviewer](concepts/Reviewer.md) +- [RFM-Analysis](concepts/RFM-Analysis.md) +- [Rightsizing](concepts/Rightsizing.md) +- [Risk-Mitigation](concepts/Risk-Mitigation.md) +- [ROI](concepts/ROI.md) +- [Rollback-Rate](concepts/Rollback-Rate.md) +- [Root-Cause-Analysis](concepts/Root-Cause-Analysis.md) +- [RPC-Remote-Procedure-Call](concepts/RPC-Remote-Procedure-Call.md) +- [RPO](concepts/RPO.md) +- [RSS-Aggregation](concepts/RSS-Aggregation.md) +- [RTO](concepts/RTO.md) +- [RuntimeVirtualTexturing](concepts/RuntimeVirtualTexturing.md) +- [S3-兼容对象存储](concepts/S3-兼容对象存储.md) +- [Safeguard-Steps](concepts/Safeguard-Steps.md) +- [Sandboxed-Persona](concepts/Sandboxed-Persona.md) +- [SAST](concepts/SAST.md) +- [Savings-Plans](concepts/Savings-Plans.md) +- [SCA](concepts/SCA.md) +- [Scalability](concepts/Scalability.md) +- [Scheduled-Reminder](concepts/Scheduled-Reminder.md) +- [Scheduled-Task-Flywheel](concepts/Scheduled-Task-Flywheel.md) +- [Scholar-Skill](concepts/Scholar-Skill.md) +- [SCRM](concepts/SCRM.md) +- [Scrum](concepts/Scrum.md) +- [SDDC](concepts/SDDC.md) +- [SE-Linux-Enforcing](concepts/SE-Linux-Enforcing.md) +- [Second-Renaissance](concepts/Second-Renaissance.md) +- [Secrets-Management](concepts/Secrets-Management.md) +- [Security-and-Compliance](concepts/Security-and-Compliance.md) +- [Self-Education](concepts/Self-Education.md) +- [Self-Healing-Systems](concepts/Self-Healing-Systems.md) +- [self-hosted-password-manager](concepts/self-hosted-password-manager.md) +- [Self-Improving-Skill](concepts/Self-Improving-Skill.md) +- [Self-Interest](concepts/Self-Interest.md) +- [Self-Referential-Computation](concepts/Self-Referential-Computation.md) +- [Self-Sufficiency](concepts/Self-Sufficiency.md) +- [Semantic-Deduplication](concepts/Semantic-Deduplication.md) +- [Semantic-Index-Infrastructure](concepts/Semantic-Index-Infrastructure.md) +- [Semantic-Search](concepts/Semantic-Search.md) +- [Semantic-Versioning](concepts/Semantic-Versioning.md) +- [Semantic-Zoom](concepts/Semantic-Zoom.md) +- [SemanticRouting](concepts/SemanticRouting.md) +- [Sequential-Handoff](concepts/Sequential-Handoff.md) +- [Sequential-Thinking](concepts/Sequential-Thinking.md) +- [Server-Authoritative-Model](concepts/Server-Authoritative-Model.md) +- [ServerAuthority](concepts/ServerAuthority.md) +- [Serverless-Computing](concepts/Serverless-Computing.md) +- [Service-Control-Policies-SCPs](concepts/Service-Control-Policies-SCPs.md) +- [SES-Sandbox-Mode](concepts/SES-Sandbox-Mode.md) +- [Shader](concepts/Shader.md) +- [ShadowTraffic](concepts/ShadowTraffic.md) +- [SHAP](concepts/SHAP.md) +- [Shared-Memory-Architecture](concepts/Shared-Memory-Architecture.md) +- [Shared-Responsibility-Model](concepts/Shared-Responsibility-Model.md) +- [SharedStateCoordination](concepts/SharedStateCoordination.md) +- [Shift-Left-Security](concepts/Shift-Left-Security.md) +- [Shift-Right-Security](concepts/Shift-Right-Security.md) +- [Signal-Based-Selling-Framework](concepts/Signal-Based-Selling-Framework.md) +- [Single-Control-Plane](concepts/Single-Control-Plane.md) +- [Six-Sigma](concepts/Six-Sigma.md) +- [SKAdNetwork](concepts/SKAdNetwork.md) +- [SLS](concepts/SLS.md) +- [SmartBidding](concepts/SmartBidding.md) +- [SnapMirror](concepts/SnapMirror.md) +- [Social-Media-Monitoring](concepts/Social-Media-Monitoring.md) +- [Socket-登录](concepts/Socket-登录.md) +- [SOCKS5代理](concepts/SOCKS5代理.md) +- [Software-Assurance-Maturity-Model](concepts/Software-Assurance-Maturity-Model.md) +- [Solution-Architecture](concepts/Solution-Architecture.md) +- [SOUL.md](concepts/SOUL.md.md) +- [Source-Grounding](concepts/Source-Grounding.md) +- [Spatial-Computing](concepts/Spatial-Computing.md) +- [Spatial-Psychology](concepts/Spatial-Psychology.md) +- [Spatial-Widgets](concepts/Spatial-Widgets.md) +- [SpatialAIOps](concepts/SpatialAIOps.md) +- [SpatialAudio](concepts/SpatialAudio.md) +- [Speed-Ramping](concepts/Speed-Ramping.md) +- [Speedrun-Design](concepts/Speedrun-Design.md) +- [Split](concepts/Split.md) +- [Spot-Instances](concepts/Spot-Instances.md) +- [SprintPlanning](concepts/SprintPlanning.md) +- [SSE-Server-Sent-Events](concepts/SSE-Server-Sent-Events.md) +- [StackSets-Deployment-Visibility](concepts/StackSets-Deployment-Visibility.md) +- [Stakeholder-Alignment](concepts/Stakeholder-Alignment.md) +- [Standard-Change](concepts/Standard-Change.md) +- [STARFramework](concepts/STARFramework.md) +- [Startup-MVP-Pipeline](concepts/Startup-MVP-Pipeline.md) +- [Statistical-Process-Control](concepts/Statistical-Process-Control.md) +- [Strategic-Portfolio-Management](concepts/Strategic-Portfolio-Management.md) +- [Strategic-Question-Answer](concepts/Strategic-Question-Answer.md) +- [Streak-Tracking](concepts/Streak-Tracking.md) +- [Stretched-Cluster](concepts/Stretched-Cluster.md) +- [StructuredInterview](concepts/StructuredInterview.md) +- [StudyVault](concepts/StudyVault.md) +- [Sub-Agent-Race-Condition](concepts/Sub-Agent-Race-Condition.md) +- [Substrate](concepts/Substrate.md) +- [SwiftUI-Volumetric-APIs](concepts/SwiftUI-Volumetric-APIs.md) +- [symbolic-link](concepts/symbolic-link.md) +- [System-Economy](concepts/System-Economy.md) +- [system-monitoring](concepts/system-monitoring.md) +- [systemd](concepts/systemd.md) +- [Tag-Validation-Tool](concepts/Tag-Validation-Tool.md) +- [Task-Query](concepts/Task-Query.md) +- [TaskAutomation](concepts/TaskAutomation.md) +- [Taylorism](concepts/Taylorism.md) +- [TCP隧道](concepts/TCP隧道.md) +- [Technical-Architecture](concepts/Technical-Architecture.md) +- [Technical-Objection-Handling](concepts/Technical-Objection-Handling.md) +- [Telegram-Trigger](concepts/Telegram-Trigger.md) +- [Telephony-Integration](concepts/Telephony-Integration.md) +- [Template-Based-Production](concepts/Template-Based-Production.md) +- [Terraform-Modules](concepts/Terraform-Modules.md) +- [Test-Mode](concepts/Test-Mode.md) +- [Text-and-Search](concepts/Text-and-Search.md) +- [Thought-Leadership](concepts/Thought-Leadership.md) +- [Threat-Modeling](concepts/Threat-Modeling.md) +- [Three-Tier-Review-Mechanism](concepts/Three-Tier-Review-Mechanism.md) +- [ThreeActProposalNarrative](concepts/ThreeActProposalNarrative.md) +- [TieredCampaignArchitecture](concepts/TieredCampaignArchitecture.md) +- [Time-Boxing](concepts/Time-Boxing.md) +- [Time-to-Market](concepts/Time-to-Market.md) +- [Todoist-API](concepts/Todoist-API.md) +- [Token-Light-Design](concepts/Token-Light-Design.md) +- [Tool-Calling](concepts/Tool-Calling.md) +- [TOOLS.md](concepts/TOOLS.md.md) +- [ToolWrapper](concepts/ToolWrapper.md) +- [Topic-Based-Routing](concepts/Topic-Based-Routing.md) +- [totp](concepts/totp.md) +- [Transactional-Analysis](concepts/Transactional-Analysis.md) +- [Transcript-Based-Summarization](concepts/Transcript-Based-Summarization.md) +- [TranscriptProcessing](concepts/TranscriptProcessing.md) +- [Trauma-Informed-Analysis](concepts/Trauma-Informed-Analysis.md) +- [Tree-of-Thoughts](concepts/Tree-of-Thoughts.md) +- [Trend-To-Action](concepts/Trend-To-Action.md) +- [Trending-Topic-Operations](concepts/Trending-Topic-Operations.md) +- [TrendRiding](concepts/TrendRiding.md) +- [Trust-Scoring](concepts/Trust-Scoring.md) +- [tui](concepts/tui.md) +- [Tutor-Skills](concepts/Tutor-Skills.md) +- [Two-Way-Voice-Conversation](concepts/Two-Way-Voice-Conversation.md) +- [UCAS-System](concepts/UCAS-System.md) +- [UEFI-Only](concepts/UEFI-Only.md) +- [UEFI启动](concepts/UEFI启动.md) +- [ULS](concepts/ULS.md) +- [Unified-Inbox](concepts/Unified-Inbox.md) +- [UnityLobby](concepts/UnityLobby.md) +- [UnityRelay](concepts/UnityRelay.md) +- [USER.md](concepts/USER.md.md) +- [Value-Stream-Mapping](concepts/Value-Stream-Mapping.md) +- [Variables-YAML](concepts/Variables-YAML.md) +- [Vector-Embedding](concepts/Vector-Embedding.md) +- [Vendor-Lock-In](concepts/Vendor-Lock-In.md) +- [VFX](concepts/VFX.md) +- [Vibe-Coding](concepts/Vibe-Coding.md) +- [Video-Hook](concepts/Video-Hook.md) +- [ViralLoop](concepts/ViralLoop.md) +- [Visual-Coherence-Engine](concepts/Visual-Coherence-Engine.md) +- [Visual-Debugging](concepts/Visual-Debugging.md) +- [vLLM](concepts/vLLM.md) +- [VMware-Cloud-on-AWS](concepts/VMware-Cloud-on-AWS.md) +- [Voice-Interface](concepts/Voice-Interface.md) +- [Voice-Notification-Channel](concepts/Voice-Notification-Channel.md) +- [VPC-Endpoint](concepts/VPC-Endpoint.md) +- [Vulnerability-Scanning](concepts/Vulnerability-Scanning.md) +- [Wake-on-LAN](concepts/Wake-on-LAN.md) +- [Wayland](concepts/Wayland.md) +- [Web-Search-Aggregation](concepts/Web-Search-Aggregation.md) +- [Webhook](concepts/Webhook.md) +- [Webhook-Proxy-Pattern](concepts/Webhook-Proxy-Pattern.md) +- [WEBHOOK_URL](concepts/WEBHOOK_URL.md) +- [WebXR](concepts/WebXR.md) +- [Weekly-Pattern-Analysis](concepts/Weekly-Pattern-Analysis.md) +- [What-If-Simulation](concepts/What-If-Simulation.md) +- [WinThemes](concepts/WinThemes.md) +- [Workflow-Engineering](concepts/Workflow-Engineering.md) +- [Workflow-Registry](concepts/Workflow-Registry.md) +- [Workflow-Tree-Spec](concepts/Workflow-Tree-Spec.md) +- [Workspace](concepts/Workspace.md) +- [WorldPartition](concepts/WorldPartition.md) +- [X11](concepts/X11.md) +- [Xinchuang](concepts/Xinchuang.md) +- [Y-Combinator](concepts/Y-Combinator.md) +- [Zero-Friction-Capture](concepts/Zero-Friction-Capture.md) +- [Zero-Trust](concepts/Zero-Trust.md) +- [Zero-Trust-Architecture](concepts/Zero-Trust-Architecture.md) +- [Zettelkasten](concepts/Zettelkasten.md) +- [一人公司](concepts/一人公司.md) +- [上下文刷新](concepts/上下文刷新.md) +- [上下文压缩](concepts/上下文压缩.md) +- [下沉市场](concepts/下沉市场.md) +- [个人品牌](concepts/个人品牌.md) +- [九宫格法](concepts/九宫格法.md) +- [云盘挂载](concepts/云盘挂载.md) +- [交接协议](concepts/交接协议.md) +- [产品四层级体系](concepts/产品四层级体系.md) +- [价格锚定与诱饵效应](concepts/价格锚定与诱饵效应.md) +- [全盘镜像备份](concepts/全盘镜像备份.md) +- [内容矩阵](concepts/内容矩阵.md) +- [内网穿透](concepts/内网穿透.md) +- [写入纪律](concepts/写入纪律.md) +- [单一职责原则](concepts/单一职责原则.md) +- [反向代理](concepts/反向代理.md) +- [合成监控](concepts/合成监控.md) +- [启动序列](concepts/启动序列.md) +- [四个心理陷阱](concepts/四个心理陷阱.md) +- [固件刷入](concepts/固件刷入.md) +- [固定机位](concepts/固定机位.md) +- [图床](concepts/图床.md) +- [均衡分发算法](concepts/均衡分发算法.md) +- [增量备份](concepts/增量备份.md) +- [天才地带](concepts/天才地带.md) +- [容器资源限制](concepts/容器资源限制.md) +- [容器重启策略](concepts/容器重启策略.md) +- [工作流自动化](concepts/工作流自动化.md) +- [并发编程](concepts/并发编程.md) +- [底层能力](concepts/底层能力.md) +- [微服务架构](concepts/微服务架构.md) +- [思维蒸馏（女娲造人术）](concepts/思维蒸馏（女娲造人术）.md) +- [技术图生成](concepts/技术图生成.md) +- [挂载点检查](concepts/挂载点检查.md) +- [指纹浏览器](concepts/指纹浏览器.md) +- [接码平台](concepts/接码平台.md) +- [播客生成](concepts/播客生成.md) +- [故障转移](concepts/故障转移.md) +- [数字导师](concepts/数字导师.md) +- [数据可视化](concepts/数据可视化.md) +- [文档问答](concepts/文档问答.md) +- [时序数据库](concepts/时序数据库.md) +- [本地化部署](concepts/本地化部署.md) +- [桥接网络](concepts/桥接网络.md) +- [模块化编程](concepts/模块化编程.md) +- [每日复盘机制](concepts/每日复盘机制.md) +- [永久挂载](concepts/永久挂载.md) +- [消息队列](concepts/消息队列.md) +- [混合搜索](concepts/混合搜索.md) +- [版本控制](concepts/版本控制.md) +- [用户权限](concepts/用户权限.md) +- [直播带货](concepts/直播带货.md) +- [硬件转码](concepts/硬件转码.md) +- [私域运营](concepts/私域运营.md) +- [端口映射](concepts/端口映射.md) +- [策略组分流](concepts/策略组分流.md) +- [系统睡眠管理](concepts/系统睡眠管理.md) +- [老铁经济](concepts/老铁经济.md) +- [舆情监控](concepts/舆情监控.md) +- [虚拟信用卡](concepts/虚拟信用卡.md) +- [裸机恢复](concepts/裸机恢复.md) +- [订阅机制](concepts/订阅机制.md) +- [设备直通](concepts/设备直通.md) +- [语义形状词汇表](concepts/语义形状词汇表.md) +- [语义搜索](concepts/语义搜索.md) +- [语义箭头系统](concepts/语义箭头系统.md) +- [账号隔离](concepts/账号隔离.md) +- [超级个体](concepts/超级个体.md) +- [跨境支付](concepts/跨境支付.md) +- [软链接策略](concepts/软链接策略.md) +- [输入-处理-输出模型](concepts/输入-处理-输出模型.md) +- [过渡固件](concepts/过渡固件.md) +- [进程管理](concepts/进程管理.md) +- [逻辑备份](concepts/逻辑备份.md) +- [销售漏斗](concepts/销售漏斗.md) +- [首尾针动画](concepts/首尾针动画.md) +- [품의](concepts/품의.md) + +## Syntheses diff --git a/wiki/log.md b/wiki/log.md index 02c25cb7..01a46a49 100644 --- a/wiki/log.md +++ b/wiki/log.md @@ -1,3463 +1,4048 @@ -## [2026-05-05] ingest | Tool Evaluator Agent Personality -- Source file: Agent/agency-agents/testing/testing-tool-evaluator.md -- Status: ✅ 成功摄入 -- Summary: Tool Evaluator——The Agency Testing 部门的技术评估与战略工具采纳专家，专注于 ROI 导向的工具分析、竞争对比和战略技术采纳建议。核心理念：量化一切可量化的，成本-功能-风险三维权衡。核心能力：7维加权评分体系（功能25%/可用性20%/性能15%/安全15%/集成10%/支持8%/成本7%）、4阶段工作流（需求收集→全面测试→财务风险分析→实施规划）、TCO/ROI 量化计算框架。Python 框架：pandas + numpy + requests + dataclass 评分模型。成功指标：90%+ 推荐准确性，85%+ 6个月采用率，20%+ 成本优化，25%+ ROI。 -- Concepts created: TotalCostOfOwnership, ReturnOnInvestment, ServiceLevelAgreement, UserAcceptanceTesting, ChangeManagement, WeightedScoringModel -- Entities created: 无（Tool Evaluator Agent 为单来源，不满足 ≥2 次创建阈值） -- Source page: wiki/sources/testing-tool-evaluator.md -- Notes: 无内容冲突。index.md 原占位条目已替换为完整摘要；overview.md Testing 部门已有 testing-evidence-collector / testing-test-results-analyzer / testing-performance-benchmarker / testing-reality-checker / testing-workflow-optimizer / testing-api-tester 覆盖，testing-tool-evaluator 补充了战略评估维度，与 testing-reality-checker 互补（量化评分 vs 现实核查）。与 testing-evidence-collector / testing-test-results-analyzer / testing-performance-benchmarker 的协同关系已在 Source Page Connections 节记录。 - -## [2026-05-05] ingest | Test Results Analyzer Agent Personality -- Source file: Agent/agency-agents/testing/testing-test-results-analyzer.md -- Status: ✅ 成功摄入 -- Summary: Test Results Analyzer——The Agency Testing 部门的测试结果分析与质量情报专家 Agent，通过统计分析方法、机器学习预测模型和可视化报告将原始测试数据转化为战略决策依据。核心理念：数据驱动的质量决策，所有结论必须通过统计方法验证。核心能力：测试覆盖率分析、失败模式统计分类、基于 RandomForest 的缺陷易发性预测、发布就绪多维度评估、质量投资 ROI 分析。Python 框架：pandas + numpy + scipy.stats + sklearn RandomForestClassifier + matplotlib/seaborn。成功指标：质量风险预测准确率 95%+、24 小时内报告交付、干系人满意度 4.5/5。 -- Concepts created: 无（Key Concepts 均为单来源特定方法论，不满足可独立复用阈值） -- Entities created: 无（Key Entities 均为单来源技术栈，不满足 ≥2 次创建阈值） -- Source page: wiki/sources/testing-test-results-analyzer.md -- Notes: 无内容冲突。index.md 已添加条目；overview.md Testing 部门新增 testing-test-results-analyzer 段落。与 testing-performance-benchmarker 的协同关系已在 Source Page 和 overview.md 中记录（Performance Benchmarker 提供性能维度数据，Test Results Analyzer 提供整体质量情报视图）。 - -## [2026-05-05] ingest | Testing Evidence Collector Agent Personality -- Source file: Agent/agency-agents/testing/testing-evidence-collector.md -- Status: ✅ 成功摄入 -- Summary: EvidenceQA——The Agency Testing 部门的截图驱动型 QA Agent，核心理念"截图不会撒谎"，以 Playwright 自动化截图作为唯一可靠的质量评估依据。强制默认发现 3-5+ 问题，"零问题"报告为红色警报。质量评级默认 FAILED，不接受无视觉证据支撑的声称。提供标准化 QA 报告模板（Reality Check Results / Visual Evidence Analysis / Interactive Testing Results / Issues Found / Honest Quality Assessment）。 -- Concepts created: 无（Key Concepts 均为单来源特定方法论，不满足可独立复用阈值） -- Entities created: 无（Key Entities 均为单来源 Agent，不满足 ≥2 次创建阈值） -- Source page: wiki/sources/testing-evidence-collector.md -- Notes: 无内容冲突。index.md 已添加条目；overview.md Testing 部门已有相关 Testing Agent 覆盖，无需额外修订。与声称"零问题"报告的冲突已在 Source Page Contradictions 节记录。与 testing-reality-checker / testing-test-results-analyzer / testing-performance-benchmarker 的协同关系已在 Source Page Connections 节记录。 - -## [2026-05-05] ingest | Performance Benchmarker Agent Personality -- Source file: Agent/agency-agents/testing/testing-performance-benchmarker.md -- Status: ✅ 成功摄入 -- Summary: Performance Benchmarker——The Agency Testing 部门的性能测试与优化专家 Agent，通过系统性性能测试确保系统以 95% 置信度满足 SLA 要求。核心理念：量化一切可量化的，用数据证明优化价值。核心能力：负载/压力/耐力/可扩展性测试，Core Web Vitals 优化（LCP < 2.5s / FID < 100ms / CLS < 0.1），k6 性能测试框架，统计置信区间分析，容量规划与成本-性能权衡。成功指标：95% 系统持续满足性能 SLA，Core Web Vitals 达到"良好"评级（90th percentile），关键用户体验指标改善 25%，支持 10x 当前负载。 -- Concepts created: 无（所有 Key Concepts 均为单来源特定概念，不满足独立复用阈值） -- Entities created: 无（所有 Key Entities 均为单来源 Agent，不满足 ≥2 次创建阈值） -- Source page: wiki/sources/testing-performance-benchmarker.md -- Notes: 无内容冲突。index.md 原占位条目已替换为完整摘要；overview.md Testing 部门已新增 testing-performance-benchmarker 段落。与 testing-reality-checker 的互补张力（指标量化 vs 用户感受）已在 Source Page Contradictions 节记录。 - -## [2026-05-05] ingest | Testing Reality Checker Agent Personality -- Source file: Agent/agency-agents/testing/testing-reality-checker.md -- Status: ✅ 成功摄入 -- Summary: Testing Reality Checker——The Agency Testing 部门的最后一道防线 Agent，通过自动化截图证据截断"幻想型认证"，要求压倒性视觉证明才授予生产就绪状态。默认"NEEDS WORK"，强制三步验证流程（Reality Check 命令 → QA 交叉验证 → 端到端截图分析）。C+/B- 评级属正常；第一次实现通常需要 2-3 轮修订。 -- Concepts created: 无（所有 Key Concepts 均为单来源特定概念，不满足独立复用阈值） -- Entities created: 无（所有 Key Entities 均为单来源 Agent，不满足 ≥2 次创建阈值） -- Source page: wiki/sources/testing-reality-checker.md -- Notes: 无内容冲突。index.md 原占位条目已替换为完整摘要；overview.md Testing 部门已新增 testing-reality-checker 段落。与 testing-workflow-optimizer 的潜在张力（效率 vs 真实性）和与 testing-api-tester 的互补关系（截图 vs 接口）已在 Source Page Contradictions 节记录。 - -## [2026-05-05] ingest | Workflow Optimizer Agent Personality -- Source file: Agent/agency-agents/testing/testing-workflow-optimizer.md -- Status: ✅ 成功摄入 -- Summary: Workflow Optimizer——The Agency Testing 部门的流程优化与工作流自动化专家 Agent，基于系统思维方法论分析、优化和自动化跨业务功能的工作流。核心理念：找到瓶颈，修复流程，其余自动化。四阶段工作流（现状分析→优化设计→实施规划→自动化执行），融合 Lean/Six Sigma/Kaizen/统计过程控制/变更管理/人本设计六大方法论体系。核心交付物：WorkflowOptimizer Python 框架。成功指标：40% 周期时间改善、60% 常规任务自动化率、75% 流程错误减少、90% 优化流程 6 个月内成功采纳、30% 员工满意度提升。 -- Concepts created: [[Lean]], [[Six-Sigma]], [[Kaizen]], [[Value-Stream-Mapping]], [[Statistical-Process-Control]], [[Human-Centered-Design]], [[Design-Thinking]]（共 7 个，其中 Change-Management 已存在） -- Entities created: 无（The Agency 已在 entities/ 中存在；各工具仅出现 1 次，不满足 ≥2 次创建阈值） -- Source page: wiki/sources/testing-workflow-optimizer.md -- Notes: 无内容冲突。index.md 原占位条目已替换为完整摘要；overview.md Testing 部门已新增 testing-workflow-optimizer 段落；7 个新 Concept 页面已创建并添加到 index.md。与 specialized-workflow-architect（设计与执行的分层关系）和 product-behavioral-nudge-engine（自动化 vs 人机交互互补张力）已在 Source Page Contradictions 节记录。 - -## [2026-05-05] ingest | API Tester Agent Personality -- Source file: Agent/agency-agents/testing/testing-api-tester.md -- Status: ✅ 成功摄入 -- Summary: API Tester Agent——The Agency Testing 部门的 API 测试专家智能体人格定义，涵盖功能、性能、安全三大维度的全面 API 质量保障方法论与自动化实现框架。核心理念"Breaks your API before your users do"，通过 Playwright/REST Assured/k6 框架实现 95%+ API 端点覆盖率，CI/CD 流水线集成，性能 SLA（95p < 200ms、10x 负载、< 0.1% 错误率），OWASP API Security Top 10 安全验证。 -- Concepts created: 无（API Testing、Performance Testing、Security Testing、Contract Testing、CI/CD Integration、OWASP API Security Top 10 等概念均已在本文档出现，未达独立创建阈值） -- Entities created: 无（Playwright、REST Assured、k6、perf_hooks 等工具均仅在本文档出现，未达创建阈值） -- Source page: wiki/sources/testing-api-tester.md -- Notes: 无内容冲突。index.md 和 overview.md 已更新。新增 Testing 部门 section 到 overview.md。 -- Source file: Agent/agency-agents/integrations/opencode/README.md -- Status: ✅ 成功摄入 -- Summary: OpenCode Integration——The Agency Agent roster 与 OpenCode 编辑器的子 Agent 集成方案，通过 `./scripts/install.sh --tool opencode` 安装，将 .md 格式 Agent 转换为 OpenCode 的 `.opencode/agents/` 格式。核心机制：`mode: subagent` 使 Agent 仅在 `@agent-name` 触发时出现，不在 Tab 循环中占位；命名颜色自动映射为十六进制颜色代码。支持项目级和全局级两种安装范围。与 [[readme|Cursor Integration]]（.mdc）、[[github-copilot|GitHub Copilot Integration]]、[[windsurf-integration|Windsurf Integration]] 同属 The Agency 多 IDE 集成生态。 -- Concepts created: 无（Subagent、OpenCode 仅在本文档出现1次，未达创建阈值） -- Entities updated: 无（[[The Agency]] 已在其他来源中覆盖，无需新建 OpenCode entity） -- Source page: wiki/sources/readme.md -- Notes: 无内容冲突。index.md 和 overview.md 已更新。 - -## [2026-05-04] ingest | Kimi Code CLI Integration -- Source file: Agent/agency-agents/integrations/kimi/README.md -- Status: ✅ 成功摄入 -- Summary: Kimi Code CLI Integration——将 Agency agents 项目转换为 Kimi Code CLI 可用的 agent specification，通过 `convert.sh` 和 `install.sh` 脚本生成 `agent.yaml` + `system.md` 目录结构，安装到 `~/.config/kimi/agents/`。使用 `--agent-file` 标志激活，支持 `extend: default` 继承 Kimi 内置工具集。与 [[readme|Cursor Integration]] 和 [[github-copilot|GitHub Copilot Integration]] 同属 The Agency 多 IDE/CLI 集成生态。 -- Concepts created: 无（YAML配置文件、Agent规范、SystemPrompt 均仅在本文档出现1次，未达创建阈值） -- Entities created: 无（Kimi Code CLI、Moonshot AI 均仅在本文档出现1次，未达创建阈值） -- Source page: wiki/sources/kimi.md -- Notes: 无内容冲突。index.md 和 overview.md 已更新。 - -## [2026-05-04] ingest | Antigravity Integration -- Source file: Agent/agency-agents/integrations/antigravity/README.md -- Status: ✅ 成功摄入 -- Summary: Antigravity Integration——The Agency Agent roster 与 Antigravity/Gemini 的集成方案，通过 `./scripts/install.sh --tool antigravity` 将全部 Agent roster 转换为 Antigravity SKILL.md 文件，复制到 `~/.gemini/antigravity/skills/`。所有 skill slug 统一使用 `agency-` 前缀避免命名冲突。用户可通过自然语言激活对应 agent。与 [[Cursor Integration]]（.mdc 规则）、[[Windsurf Integration]]（.windsurfrules）、[[GitHub Copilot Integration]]（原生兼容）共同构成 The Agency 的完整多平台集成生态。 -- Concepts updated: 无需更新（SKILL.md Format、Antigravity Skills、Skill Prefix Convention 等概念已在其他来源中覆盖） -- Entities created: 无（Antigravity/Gemini、Agency Agents 均已在其他来源中出现，无需新建） -- Source page: wiki/sources/antigravity-integration.md -- Notes: 无内容冲突。index.md 和 overview.md 已更新。与 [[Cursor Integration]] 在"多 IDE 集成覆盖"定位上存在功能重叠，已在 Contradictions 节标注区分（前者 GUI 编辑器生态，后者 Gemini 生态）。 - -## [2026-05-03] ingest | Windsurf Integration -- Source file: Agent/agency-agents/integrations/windsurf/README.md -- Status: ✅ 成功摄入 -- Summary: Windsurf Integration——The Agency Agent roster 与 Windsurf 编辑器的集成方案，通过 `.windsurfrules` 文件将 Agent roster 聚合为单一规则文件，install.sh 从项目根目录安装，项目级生效。在 prompt 中按名称引用 Agent 即可激活。与 [[Cursor Integration]]（.mdc）和 [[Aider Integration]]（CONVENTIONS.md）同为项目级 IDE 集成，共同构成 The Agency 的多 IDE 覆盖体系。 -- Concepts updated: [[Agent-Activation-Pattern]]（补充 Windsurf 应用场景）、[[Project-Scoped-Tools]]（替代 Project-Scoped-Integration，与 integrations-readme.md 保持一致） -- Entities created: [[Windsurf]]（Windsurf.md，Codeium 开发的 AI 代码编辑器，跨 3 个 source 页面出现） -- Source page: wiki/sources/windsurf-integration.md -- Notes: 无内容冲突。index.md 和 overview.md 已更新。slug 避免与同名 readme.md 冲突（已有多条同名占位条目），采用 windsurf-integration.md。 - -## [2026-04-26] ingest | Gemini CLI Integration -- Source file: Agent/agency-agents/integrations/gemini-cli/README.md -- Status: ✅ 成功摄入 -- Summary: Gemini CLI Integration——将 61 个 Agency Agents 打包为 Gemini CLI 扩展插件，安装到 `~/.gemini/extensions/agency-agents/`，安装后可在 Gemini CLI 中通过自然语言按名称激活 Agent skill（如 `frontend-developer`）。 -- Entities created: 无（Agency Agents 已在其他来源中出现，无需新建；Agent Skill 和 Extension 机制未达到 ≥2 次出现阈值） -- Concepts created: 无 -- Source page: wiki/sources/gemini-cli.md -- Notes: 无内容冲突。 - -## [2026-05-03] ingest | Cursor Integration -- Source file: Agent/agency-agents/integrations/cursor/README.md -- Status: ✅ 成功摄入 -- Summary: Cursor Integration——将 Agency roster 中的 agent 转换为 Cursor `.mdc` 规则文件，安装到项目根目录的 `.cursor/rules/` 下，**项目级别生效**。支持 `@agent-slug` 引用特定 agent，或通过 `alwaysApply: true` 设为常驻规则。与 Aider Integration 形成 IDE 集成互补。 -- Entities created: 无（Agency Agents 和 Cursor 未达到 ≥2 次出现阈值） -- Concepts created: 无（Cursor.mdc Rules/Agency Roster/Project-Scoped Rules 仅出现 1 次，不满足 ≥2 次阈值，均以 wikilink 形式记录于 Source page） -- Source page: wiki/sources/readme.md -- Notes: 无内容冲突。overview.md 已新增 Cursor Integration 段落于 The Agency 贡献指南段落后。与 [[Aider Integration]] 存在功能重叠（两个工具都将 Agency agents 集成到不同 IDE），已在 Source page Contradictions 节记录。 - -## [2026-05-03] ingest | OpenClaw Integration -- Source file: Agent/agency-agents/integrations/openclaw/README.md -- Status: ✅ 成功摄入 -- Summary: The Agency Agent 与 OpenClaw 多智能体框架的集成方案——通过 convert.sh 将 Agent 转换为 OpenClaw workspace（含 SOUL.md/AGENTS.md/IDENTITY.md），install.sh 复制到 ~/.openclaw/agency-agents/，openclaw gateway restart 使 Agent 通过 agentId 可用。slug 采用 openclaw-integration.md 以避免与同名 Aider Integration 的 readme.md 冲突。 -- Entities created: 无（OpenClaw/The-Agency/OpenClaw-Gateway 在 overview.md 已出现多次，不满足新建阈值） -- Concepts created: 无（OpenClaw-Workspace/Workspace-Based-Agent/Agent-Conversion 仅在源页面内出现 1 次，不满足 ≥2 次阈值，均以 wikilink 形式记录于 Source page） -- Source page: wiki/sources/openclaw-integration.md -- Notes: 无内容冲突。overview.md 已有 OpenClaw 相关内容，无需修订。integrations-readme.md 已有 OpenClaw wikilink，无需重复创建 Entity 页面。 - -## [2026-05-02] ingest | MCP Memory Integration -- Source file: Agent/agency-agents/integrations/mcp-memory/README.md -- Status: ✅ 成功摄入 -- Summary: MCP Memory Integration——通过在 Agent 提示词中加入标准化的 Memory Integration 段落，为 The Agency 中任意 Agent 添加跨会话持久记忆能力。MCP Memory Server 提供 remember/recall/rollback/search 四个核心工具。Rollback 是杀手级功能：QA 失败或架构决策出错时恢复到已知良好状态，无需手动 undo。无代码修改，仅需在 prompt 中加入标准化指令段。 -- Entities created: 无（The-Agency 已存在于 entities/，Backend-Architect/Startup-MVP-Workflow 仅出现 1 次，均不满足 ≥2 次阈值） -- Concepts created: 无（Cross-Session-Memory/Handoff-Continuity/Rollback/Memory-Integration-Pattern/MCP-Memory-Tools/Checkpoint 均仅出现 1 次，均不满足 ≥2 次阈值，均以 wikilink 形式记录于 Source page） -- Source page: wiki/sources/mcp-memory-integration.md -- Notes: 无内容冲突。index.md 和 overview.md 已更新（新增 MCP Memory Integration 段落于 The Agency 段落后）。 - -## [2026-05-02] ingest | Claude Code Integration -- Source file: Agent/agency-agents/integrations/claude-code/README.md -- Status: ✅ 成功摄入 -- Summary: The Agency Agent 资产与 Claude Code 的原生集成方案。The Agency 从一开始就为 Claude Code 构建，无需任何格式转换，Agent 天然使用 `.md` + YAML frontmatter 格式。通过 install.sh 或手动复制将 Agent 部署到 `~/.claude/agents/`，在 Claude Code 会话中通过名称引用即可激活对应 Agent。 -- Entities created: 无（Claude Code/The Agency 均仅出现 1 次，不满足 ≥2 次阈值，以 wikilink 形式记录于 Source page） -- Concepts created: 无（Agent-Activation-Pattern 仅出现 1 次，不满足 ≥2 次阈值） -- Source page: wiki/sources/claude-code-integration.md -- Notes: 无内容冲突。slug 冲突解决：原 Aider Integration 已占用 `readme.md`，Claude Code README 同名，故采用 `claude-code-integration.md`。overview.md 无需修订（内容属配置说明，集成概述由 integrations-readme.md 覆盖）。 - -## [2026-05-02] ingest | Aider Integration -- Source file: Agent/agency-agents/integrations/aider/README.md -- Status: ✅ 成功摄入 -- Summary: Aider 编辑器集成 The Agency Agent 资产的安装与使用指南。核心机制：通过 install.sh 将 Agent 配置转换为 Aider 可读的 CONVENTIONS.md 文件，Aider 自动读取并激活 Agent 角色。 -- Entities created: 无（Aider 仅出现 2 次，未达到 ≥2 次阈值，以 wikilink 形式记录于 Source page） -- Concepts created: 无（CONVENTIONS.md/Project-Scoped-Integration 仅出现 1 次，不满足 ≥2 次阈值） -- Source page: wiki/sources/readme.md -- Notes: 无内容冲突。index.md 占位条目已替换为完整条目。overview.md 无需修订（The Agency 集成生态已有 integrations-readme.md 覆盖）。integrations-readme.md 已有 Aider wikilink，无需重复创建 Entity 页面。 - -## [2026-05-02] ingest | The Agency Integrations README -- Status: ✅ 成功摄入 -- Summary: The Agency 多智能体编码系统与 11 种主流 Agentic Coding 工具的集成指南。覆盖 Claude Code（原生）、GitHub Copilot（原生）、Antigravity、Gemini CLI（需 convert）、OpenCode（项目级）、OpenClaw（需 convert）、Cursor（项目级）、Aider（项目级）、Windsurf（项目级）、Kimi Code（需 convert）、Qwen Code（需 convert）。统一通过 install.sh 和 convert.sh 脚本实现跨平台部署。 -- Entities created: 无（各工具实体均仅出现 1 次，不满足 ≥2 次创建阈值） -- Concepts created: 无（Project-Scoped-Tools/Global-Scoped-Tools 仅出现 1 次） -- Source page: wiki/sources/integrations-readme.md -- Notes: 无内容冲突。index.md 和 log.md 已更新，overview.md 无需修订（已含 The Agency 段落）。 - -## [2026-05-02] ingest | Academic Geographer -- Source file: Agent/agency-agents/academic/academic-geographer.md -- Status: ✅ 成功摄入 -- Summary: Academic Geographer——AI Agent 中的地理学家角色，专注于物理与人文地理的系统性建模，为虚拟世界构建地理连贯性。核心理念："Geography is destiny — where you are determines who you become"。通过严格地理连贯性规则（河流不分叉、气候成系统、地理非装饰）、五步工作流（板块构造→气候→水文→生物群落→人类定居）、交付物模板驱动 Agent 行为。理论基础涵盖 Koppen 气候分类、Christaller 中心地理论、Mackinder 心脏地带理论、雨影效应等。 -- Entities created: [[Jared-Diamond]], [[Acemoglu]], [[Mackinder]] -- Concepts created: [[Geographic-Coherence]], [[Environmental-Determinism]], [[Mackinder-Heartland-Theory]] -- Source page: wiki/sources/academic-geographer.md -- Notes: 与 [[academic-historian]]（历时性时间维度）、[[academic-anthropologist]]（共时性文化系统）、[[academic-narratologist]]（叙事维度）共同构成"人文社科 AI 研究者矩阵"，已在 overview.md 添加独立段落。Entity/Concept 页面已创建。无已知内容冲突。 - -## [2026-05-02] ingest | Academic Narratologist -- Source file: Agent/agency-agents/academic/academic-narratologist.md -- Status: ✅ 成功摄入 -- Summary: Narratologist Agent——以叙事理论框架驱动故事结构分析的学术型 AI Agent。将俄罗斯形式主义、法国结构主义、认知叙事学等学术传统注入 Agent，使其能像专业叙事理论家一样分析故事结构、角色弧光、主题表达，并提供有命名框架依据的叙事建议。核心理念："每个故事都是一个论证"；核心原则：大多数叙事问题存在于讲述层面（sjuzhet）而非故事层面（fabula），诊断应优先于处方；每个建议必须引用至少一个命名理论框架。 -- Concepts created: [[Fabula-Sjuzhet]], [[Propp-Morphology]], [[Character-Arc]], [[Narrative-Debt]] -- Source page: wiki/sources/academic-narratologist.md -- Notes: 与 [[academic-anthropologist]]（共时性文化系统）、[[academic-historian]]（历时性时间分析）、[[academic-geographer]]（空间维度）共同构成"人文社科 AI 研究者矩阵"，已在 overview.md 添加独立段落。Entity 方面，Academic Anthropologist 条目曾标注 academic-narratologist 为 source missing，现已补全。该文档为 Agent 角色设定，无外部内容冲突。 - -- Source file: Agent/agency-agents/academic/academic-anthropologist.md -- Status: ✅ 成功摄入 -- Summary: Academic Anthropologist——基于文化人类学理论构建文化自洽社会的 AI Agent 设计框架。将田野调查方法论注入 Agent，使其能设计有社会学意义的亲属制度、交换系统、仪式信仰和权力结构。核心理念：每个文化元素必须有社会功能，先问"这个实践解决了什么问题"而非"这个仪式看起来酷不酷"。理论基础：结构人类学（列维-斯特劳斯）、象征人类学（格尔茨"厚描"）、实践理论（布迪厄）、仪式分析（特纳/范热内普）、经济人类学（莫斯/波拉尼）。关键原则：避免文化拼贴（culture salad）、不跳过亲属制度设计、无乌托邦（每个文化都有内部张力）。 -- Concepts created: [[Thick-Description]], [[Liminality]], [[Gift-Economy]], [[Cultural-Coherence]], [[Rites-of-Passage]] -- Entities identified (not yet created): [[Claude-Lévi-Strauss.md]], [[Clifford-Geertz.md]], [[Pierre-Bourdieu.md]], [[Victor-Turner.md]], [[Arnold-van-Gennep.md]], [[Marcel-Mauss.md]], [[Mary-Douglas.md]], [[Émile-Durkheim.md]], [[Bronislaw-Malinowski.md]], [[Karl-Polanyi.md]], [[Marvin-Harris.md]] -- Source page: wiki/sources/academic-anthropologist.md -- Notes: 与 [[academic-historian]]（历时性视角）、[[academic-geographer]]（空间维度）、[[academic-narratologist]]（叙事维度）共同构成"人文社科 AI 研究者矩阵"。Entity/Concept 页面已识别但未实际创建，可作为后续补充。无已知内容冲突。 - -## [2026-04-26] ingest | Academic Psychologist -- Source file: Agent/agency-agents/academic/academic-psychologist.md -- Status: ✅ 成功摄入 -- Summary: Academic Psychologist——The Agency 学术部门的临床与研究心理学家人格智能体，为角色塑造提供心理学可信度支撑。基于 Big Five、依恋理论、Vaillant 防御机制层级、Karpman 戏剧三角、CBT 认知扭曲、社会心理学经典实验等多种理论与实证框架，对角色进行多维度心理画像。核心原则：拒绝将角色病理化，区分流行心理学与循证心理学，承认文化情境与创伤响应的多样性。 -- Concepts created: [[Big-Five-Personality]], [[Attachment-Theory]], [[Defense-Mechanisms]], [[Cognitive-Distortions]], [[Karpman-Drama-Triangle]], [[Transactional-Analysis]], [[Trauma-Informed-Analysis]] -- Source page: wiki/sources/academic-psychologist.md - -## [2026-04-25] ingest | Historian Agent Personality -- Source file: Agent/agency-agents/academic/academic-historian.md -- Status: ✅ 成功摄入 -- Summary: Historian Agent——AI Agent 角色设定，扮演具有跨时代研究能力的历史学家，为创意项目提供历史真实性验证、时代背景丰富化和历史迷思纠正。核心理念：物质条件决定论（先理解经济基础再谈政治军事）、主动挑战欧洲中心主义、每条论断必须标注置信度和来源类型。方法论：Annales 学派、长时段分析（longue durée）、微观史、比较史、反事实推理、史料批判。五步工作流：定位时空坐标→核查物质基础→叠加社会结构→评估论断→标注置信度。典型交付物：Period Authenticity Report、Historical Coherence Check。 -- Concepts created: [[Annales-School]], [[Longue-Duree]] -- Source page: wiki/sources/academic-historian.md -- Notes: 与 [[academic-geographer]]（空间维度）、[[academic-anthropologist]]（共时性文化系统）、[[academic-narratologist]]（叙事维度）共同构成"人文社科 AI 研究者矩阵"。无已知内容冲突——主要纠正通俗历史迷思而非与已有 Wiki 内容矛盾。 -- Notes: index.md 中原有 "source missing" 占位条目（2026-04-20）已替换为完整条目。Academic 部门未在 overview.md 单独设节，相关心理框架已融入 Wiki 的 Agent 心理学知识体系。7 个 Concept 页面已创建并添加到 index.md。所有 Key Entities（Erikson/Piaget/Bowlby/Aaron Beck/Karpman/Vaillant/Milgram/Zimbardo/Herman/van der Kolk/Porges/Eysenck/Lazarus）均仅出现 1 次，不足 Entity 建页阈值（≥2 次），以 wikilink 形式记录于 Source page。与 [[multi-agent-system-reliability]] 在"确定性 vs 概率性"上的张力已记录于 Contradictions 部分。 - -## [2026-04-26] ingest | Behavioral Nudge Engine -- Source file: Agent/agency-agents/product/product-behavioral-nudge-engine.md -- Status: ✅ 成功摄入 -- Summary: Behavioral Nudge Engine——基于行为心理学原理的智能用户推动引擎，通过个性化交互节奏和激励策略最大化软件用户完成任务的可能性。核心四阶段工作流：偏好发现→任务拆解→精准推送→即时庆祝。支持 SMS/Email/应用内横幅等多渠道触达，利用默认偏差、微任务冲刺（5分钟）和游戏化机制持续驱动用户行为。有效降低认知负荷、提升任务完成率、减少平台流失。 -- Entities created: [[BehavioralNudgeEngine.md]] -- Concepts created: [[Behavioral-Psychology.md]], [[Cognitive-Load-Reduction.md]], [[Default-Bias.md]], [[Gamification.md]], [[Momentum-Nudge.md]], [[Pomodoro-Technique.md]] -- Source page: wiki/sources/product-behavioral-nudge-engine.md -- Notes: index.md Sources 节更新原 expected 条目为正式标题；Entities 新增 Behavioral Nudge Engine 条目；Concepts 新增 5 个行为心理学相关概念页面；无已知内容冲突。 - -## [2026-04-26] ingest | Product Sprint Prioritizer Agent -- Source file: Agent/agency-agents/product/product-sprint-prioritizer.md -- Status: ✅ 成功摄入 -- Summary: Product Sprint Prioritizer——The Agency 产品部门的冲刺规划与优先级排序专家 Agent，专注于敏捷冲刺规划、特性优先级排序和资源分配，通过数据驱动的优先级框架（RICE/MoSCoW/Kano/Value vs. Effort）最大化团队交付价值。核心方法：6 冲刺滚动平均团队速率预测（偏差 < 15%）；冲刺前五步准备（Backlog Refinement → 依赖分析 → 容量评估 → 风险识别 → 干系人审查）；技术债务与新功能 ROI 平衡建模；风险评分（概率 × 影响矩阵）定期重新评估。成功指标：承诺故事点交付率 90%+、干系人满意度 4.5/5、时间线偏差 ±10%、技术债务占比 < 20%。 -- Entities created: 无（TheAgency 已存在；ProductManagerAgent 仅在连接关系中出现，通过 Source Page Key Entities 保留） -- Concepts created: [[SprintPlanning.md]]（Sprint Planning 在 7 个页面中被提及，满足独立创建条件） -- Source page: wiki/sources/product-sprint-prioritizer.md -- Notes: index.md Sources 节新增条目置于最前；overview.md Product 部门新增 [[product-sprint-prioritizer]] 条目置于 [[product-manager]] 之后；与 [[product-feedback-synthesizer]] 存在潜在张力（短期迭代优先级 vs 长期用户价值路线图），已在双方 Source Page Contradictions 节记录，建议分工：Sprint Planning 层面优先 Sprint Prioritizer，产品路线图层面优先 Feedback Synthesizer。 - -## [2026-04-26] ingest | Product Trend Researcher Agent -- Source file: Agent/agency-agents/product/product-trend-researcher.md -- Status: ✅ 成功摄入 -- Summary: Product Trend Researcher——The Agency Product 部门的专家级市场情报分析师，专注于新兴趋势识别、竞争分析和机会评估。核心方法：七步趋势识别流程（信号收集→模式识别→上下文分析→影响评估→验证→预测→可操作性）；50+ 数据源实时聚合，统计验证弱信号检测，提前 3-6 个月识别主流采纳前趋势；TAM/SAM/SOM 三层市场量化；竞争情报框架（直接/间接/新兴/技术/替代）。成功指标：80%+ 准确率 6 个月趋势预测、90% 洞察转化战略决策、48h 紧急响应、15+ 验证来源。 -- Entities created: 无（TheAgency 已存在；ProductManagerAgent/AgentsOrchestrator 仅出现 1-2 次，通过 Source Page Key Entities 保留） -- Concepts created: 无（TrendLifecycleMapping/AdoptionCurveAnalysis/TAM-SAM-SOM/CompetitiveIntelligence/WeakSignalDetection/TechnologyScouting/SocialListening 均为标准领域抽象，各仅出现 1 次，待后续批次独立创建；已在 Source Page Key Concepts 节以 [[wikilink]] 格式标注） -- Source page: wiki/sources/product-trend-researcher.md -- Notes: index.md Sources 节新增条目置于最前；overview.md Product 部门新增 [[product-trend-researcher]] 条目置于 [[product-manager]] 之前；与 [[Agents-Orchestrator]] 存在潜在张力（Trend Researcher 需要时间积累弱信号 vs Orchestrator 要求阶段质量门强制推进），已记录于 Source Page Contradictions 节。 -- Source file: Agent/agency-agents/product/product-manager.md -- Status: ✅ 成功摄入 -- Summary: Product Manager Agent (Alex)——The Agency 产品部门的核心战略 Agent，10+ 年 B2B SaaS/消费者应用/平台业务经验，Outcome-Driven 产品管理方法论。核心交付物：PRD/Opportunity Assessment/Now-Next-Later 路线图/GTM Brief/Sprint Health Snapshot。六阶段工作流：Discovery → Framing → Definition → Delivery → Launch → Measurement。关键原则：功能即假设、发布即实验；路线图是赌注清单而非承诺；经常说不保护团队焦点。 -- Entities created: 无（Alex/PM persona 仅出现 1 次；B2B SaaS/Consumer Apps/Platform Businesses 属宽泛业务分类，无需单独创建 Entity） -- Concepts created: 无（RICE/NorthStarMetric/PRD/GTMBrief/SprintHealth 均属具体执行模板，不满足"可抽象、可复用"条件；已在 Source Page Key Concepts 节以 [[wikilink]] 格式标注，待后续独立创建） -- Source page: wiki/sources/product-manager.md -- Notes: 与 [[product-feedback-synthesizer]] 互补（反馈收集 vs 产品决策）；与 [[Senior Project Manager Agent]] 属产品-项目协作层级（PM 偏战略，Senior PM 偏执行任务分解），无冲突 - -- Source file: Agent/agency-agents/product/product-feedback-synthesizer.md -- Status: ✅ 成功摄入 -- Summary: Product Feedback Synthesizer——The Agency Product 部门的用户反馈综合分析专家 Agent，专精于从多渠道（调查/访谈/工单/评论/社交媒体）收集、分析和综合用户反馈，将海量用户声音蒸馏为可量化的产品决策依据。核心能力：NLP 情感分析与满意度建模（RICE/MoSCoW/Kano 优先级框架）、用户旅程映射、流失预测与早期预警系统。核心理念：定性反馈 → 定量优先级 → 数据驱动路线图。成功指标：24h 内处理关键问题、90%+ 主题准确率、85% 综合反馈产生可衡量决策、NPS 提升 10+ 分。 -- Concepts created: 无（NPS/RICE/MoSCoW/Kano/SentimentAnalysis/UserJourneyMapping/ChurnPrediction/VoC/FeedbackLoop 各仅在本文出现 1 次，待后续批次独立创建；已在 Source Page Key Concepts 节以 [[wikilink]] 格式标注） -- Entities created: 无（The Agency 仅在本文出现 1 次，通过 Source Page Key Entities 保留） -- Source page: wiki/sources/product-feedback-synthesizer.md -- Notes: index.md 中原有 "source missing" 占位条目（2026-04-20）已替换为完整条目；overview.md 新增 "### The Agency — Product 部门" 章节并添加 product-feedback-synthesizer 条目置于 Finance 部门之前；与 [[product-sprint-prioritizer]] 存在优先级框架差异（价值优先 vs 资源约束），已记录于 Source Page Contradictions 节。 - -## [2026-04-25] ingest | Specialized Developer Advocate -- Source file: Agent/agency-agents/specialized/specialized-developer-advocate.md -- Status: ✅ 成功摄入 -- Summary: Developer Advocate Agent——The Agency Specialized 部门的开发者关系工程师，通过 DX 工程审计（Time-to-First-Success）、技术内容创作、社区运营（GitHub/Discord/Slack 响应）、产品反馈闭环（Voice of Developer 报告）推动平台采用。核心理念：Authentic 技术参与（"You don't do marketing — you do developer success"）；DX 改善复合效应优于内容发布；AstroTurf 永久性摧毁开发者信任。成功指标：首次成功 ≤15min、GitHub 响应 ≤24h、教程完成率 ≥50%、开发者 NPS ≥8/10。 -- Concepts created: 无（DeveloperExperienceEngineering/TechnicalContentCreation/CommunityBuilding/ProductFeedbackLoop/DeveloperOnboardingAudit 等均在源文档仅出现 1 次，待后续批次独立创建；已在 Source Page Key Concepts 节以 [[wikilink]] 格式标注） -- Entities created: 无（GitHub/StackOverflow/Discord/KubeCon/OpenTelemetry/The Agency 等各仅出现 1 次，通过 Source Page Key Entities 保留） -- Source page: wiki/sources/specialized-developer-advocate.md -- Notes: index.md 中原有 "source missing" 占位条目（2026-04-20）已替换为完整条目；overview.md Specialized 部门新增 Developer Advocate 条目置于 report-distribution-agent 之后；无重大内容冲突，仅与 [[specialized-workflow-architect]] 存在设计哲学层面的潜在张力（DX 质量优先 vs 快速交付），已记录于 Source Page Contradictions 节。 - -## [2026-04-25] ingest | Automation Governance Architect -- Source file: Agent/agency-agents/specialized/automation-governance-architect.md -- Status: ✅ 成功摄入 -- Summary: Automation Governance Architect——企业自动化治理架构师，负责在实施前评估业务自动化的价值、风险和可维护性。基于 n8n 编排标准 + 四维决策框架（时间节省、数据关键性、外部依赖风险、可扩展性），通过 APPROVE/APPROVE AS PILOT/PARTIAL AUTOMATION ONLY/DEFER/REJECT 五种裁决防止低价值或高风险自动化进入生产，同时推动高价值自动化的标准化落地。核心原则：技术可行不等于值得自动化；简单健壮优于精巧脆弱；每个推荐必须包含降级方案和责任人；无文档和测试证据不得标记为完成。 -- Concepts created: AutomationGovernance, DecisionFramework, N8nWorkflowStandard, ReliabilityBaseline, IntegrationGovernance, ReAuditTriggers -- Entities created: 无（n8n 仅出现 1 次，不满足"出现 ≥2 次"条件，通过 Source Page Key Entities 保留） -- Source page: wiki/sources/automation-governance-architect.md -- Notes: index.md 中原有 "source missing" 占位条目（2026-04-20）已替换为完整条目；overview.md compliance-auditor 条目中已引用 [[automation-governance-architect]]，无需额外修订；无重大内容冲突，仅与 [[specialized-workflow-architect]] 存在设计哲学层面的潜在张力（治理优先 vs 快速交付），已记录于 Source Page Contradictions 节。 - -## [2026-04-25] ingest | Report Distribution Agent -- Source file: Agent/agency-agents/specialized/report-distribution-agent.md -- Status: ✅ 成功摄入 -- Summary: Report Distribution Agent——The Agency Specialized 部门的销售报告自动分发 Agent，基于区域路由参数将合并报告精准送达对应业务员和管理层，支撑工作日 8:00 AM 定时日报和周一 7:00 AM 周报分发，99%+ 定时送达率。核心能力：区域路由（业务员仅收到其区域数据）、公司级汇总报告（管理员/经理）、HTML 邮件格式化、SMTP 传输、分发日志审计（sent/failed 状态 + 时间戳）、失败重试 + 容错继续分发。属销售数据管道的分发层，上游对接 Data Consolidation Agent。 -- Concepts created: 无（Territory Routing/SMTP Transport/Audit Trail/Scheduled Distribution 各仅在本文出现 1 次，暂不单独建 Concept 页面；已在 Source Page Key Concepts 节以 [[wikilink]] 格式标注） -- Entities created: 无（STGCRM/Data Consolidation Agent 各仅出现 1 次，通过 Source Page Key Entities 保留） -- Source page: wiki/sources/report-distribution-agent.md -- Notes: index.md 中原有 "source missing" 占位条目（2026-04-20）已替换为完整条目；overview.md Specialized 部门新增 Report Distribution Agent 条目置于 data-consolidation-agent 之后；无内容冲突（与 [[specialized-document-generator]]（文档生成）和 [[data-consolidation-agent]]（数据整合）均为互补关系，无矛盾）。 -- Source file: Agent/agency-agents/specialized/data-consolidation-agent.md -- Status: ✅ 成功摄入 -- Summary: Data Consolidation Agent——The Agency Specialized 部门的销售数据整合专家 Agent，将分散的销售提取数据聚合为实时仪表盘。核心能力：并行多维度查询（地区/代表/管道/时间维度）、实时达成率计算（revenue/quota * 100，处理除零）、MTD/YTD/Year End 多时间视图、< 1 秒加载 + 60 秒自动刷新、零数据不一致保证。 -- Concepts created: 无（Dashboard Report/Territory Report/Sales Attainment/Pipeline Snapshot/Metric Aggregation 均通过 Source Page 内 [[wikilink]] 形式表达，未单独建 Concept 页面） -- Entities created: 无（Sales Data Extraction Agent/Report Distribution Agent/Sales Pipeline Analyst/Sales Coach Agent 各仅出现 1 次，通过 Source Page Key Entities 保留） -- Source page: wiki/sources/data-consolidation-agent.md -- Notes: index.md 消除原 "source missing" 占位条目，替换为完整条目；overview.md 新增 Data Consolidation Agent 条目（置于 Specialized 部门末尾，与现有 Sales Pipeline Analyst/Sales Coach Agent 链接建立关系）；无内容冲突（与 Sales Pipeline Analyst 共享数据源但职责互补，与 Report Distribution Agent 构成顺序管道）。 -- Source file: Agent/agency-agents/specialized/supply-chain-strategist.md -- Status: ✅ 成功摄入 -- Summary: Supply Chain Strategist——The Agency Specialized 部门的中国制造业供应链全链路专家 Agent，帮助企业建立高效、有韧性、可持续的供应链体系。核心：供应商 ABC 分级管理 + Kraljic 矩阵采购策略 + TCO 全成本分析 + 库存优化模型（EOQ/ROP/安全库存/VMI/JIT）+ 供应链数字化成熟度 L1-L5 五级评估 + RBA/SA8000/CMRT 合规体系。典型成就：紧固件品类年采购成本降低 12%（节省 ¥870,000）。 -- Concepts created: 无（Kraljic Matrix/TCO/EOQ/RBA/SA8000 等均在源文档仅出现 1 次，待后续批次独立创建；已在 Source Page Key Concepts 节以 [[wikilink]] 格式标注） -- Entities created: 无（1688/Canton Fair/SGS/TUV 等各渠道平台在源文档均仅出现 1 次，待后续批次独立创建；已在 Source Page Key Entities 节以 [[wikilink]] 格式标注） -- Source page: wiki/sources/supply-chain-strategist.md -- Notes: index.md 新增 Supply Chain Strategist Agent 条目，同时替换原有 "source missing" 占位条目（2026-04-20 supply-chain-strategist）为完整条目；overview.md Specialized 部门新增 Supply Chain Strategist 条目置于 zk-steward 之后；无内容冲突检测（与 [[specialized-french-consulting-market]] 为 Specialized 部门内的不同垂直领域，无直接矛盾）。 - -## [2026-04-25] ingest | ZK Steward Agent -- Source file: Agent/agency-agents/specialized/zk-steward.md -- Status: ✅ 成功摄入 -- Summary: ZK Steward——AI 时代 Luhmann Zettelkasten 知识库管家，以 Niklas Luhmann 的卡片盒方法论为默认视角，融合多领域专家心智模型（Feynman/Karpathy/Munger/Ogilvy 等），通过原子笔记+ Luhmann 四原则验证门+领域专家切换实现有机知识网络增长。 -- Concepts created: [[Zettelkasten]]（卡片盒知识管理法）、[[Luhmann-四原则]]（原子性/连接性/有机增长/持续对话验证门）、[[Domain-Thinking]]（领域专家三维切换机制）、[[Gegenrede]]（德语反诘，跨学科反问机制）、[[Link-Proposer]]（链接提议器三步流程）、[[Daily-Log]]（Intent/Changes/Open loops 每日日志） -- Entities created: [[Niklas-Luhmann]]（德国社会学家，Zettelkasten 发明者）、[[zk-steward-companion]]（GitHub 配套技能库） -- Source page: wiki/sources/zk-steward.md -- Notes: index.md 中原有 "source missing" 占位条目（2026-04-20）已替换为完整条目；overview.md Specialized 部门新增 ZK Steward 条目置于 specialized-korean-business-navigator 之后；entities/ 和 concepts/ 目录已创建并填充 2 个 Entity + 6 个 Concept 页面；无内容冲突检测（与 [[Second-Brain]] 为互补关系，详见 Contradictions 部分）。 - -## [2026-04-25] ingest | Korean Business Navigator -- Source file: Agent/agency-agents/specialized/specialized-korean-business-navigator.md -- Status: ✅ 成功摄入 -- Summary: Korean Business Navigator——The Agency Specialized 部门的韩国商业文化导航 Agent，帮助外国专业人员解码韩国商业隐性规则。核心洞察：品의流程耗时 6-16 周，永远不要在第一次会议要求时间线；韩国"yes"≠同意，沉默=内部讨论进行中；成交发生在会议室外的走廊。六阶段品의时间线（소개→미팅→내부검토→품의서→결재→계약）、Nunchi 解码表（含"검토해보겠습니다"=婉拒等5+信号）、KakaoTalk 分阶段消息模板、韩国企业职级体系、Proof Project 策略。 -- Concepts created: [[품의]]（韩国共识审批流程，含六阶段时间线及品의서/결재라인规范）、[[Nunchi]]（韩国文化"读心术"，含6+常用商业解码表） -- Entities created: [[KakaoTalk]]（韩国主流即时通讯平台，商务沟通核心渠道；群聊必须韩语、9AM-7PM KST商务时间、24h只读不回会被注意） -- Source page: wiki/sources/specialized-korean-business-navigator.md -- Notes: index.md 中原有 "source missing" 占位条目（2026-04-20）已移除并替换为完整条目；overview.md Specialized 部门新增 Korean Business Navigator 条目置于 specialized-french-consulting-market 之后；index.md 新增 Entities 条目（KakaoTalk）和 Concepts 条目（품의、Nunchi）；无内容冲突（与 Cultural Intelligence Strategist 为互补关系，已在 overview.md 建立链接）。 - -## [2026-04-25] ingest | French Consulting Market Navigator -- Source file: Agent/agency-agents/specialized/specialized-french-consulting-market.md -- Status: ✅ 成功摄入 -- Summary: French Consulting Market Navigator——The Agency Specialized 部门的法国 IT 咨询市场（ESN/SI）生态导航 Agent，帮助独立顾问最大化 TJM 税后净收入。核心洞察：ESN Margin 25-40% 不透明；Portage Salarial vs Micro-Entrepreneur 税后收益差距 338€/天（社保保护价格）；付款延迟结构性 60-90 天；Malt 公开定价即为市场锚点。五大平台对比 + 三层 ESN 分层定价 + TJM 阶梯锚定谈判四步法。 -- Concepts created: [[Portage-Salarial]]（Portage Salarial 机制完整解析：管理费5-10%、雇主/雇员社保合计~67%、700€/天→208€/天净）、[[ESN]]（Entreprise de Services Numériques 三级分类及 Margin 架构详解） -- Entities created: 无（平台 Malt/collective.work/Comet/Crème/Free-Work 及 ESN Cloudity/Accenture 仅出现1次，通过 Source Page Key Entities 保留） -- Source page: wiki/sources/specialized-french-consulting-market.md -- Notes: index.md 中原有 "source missing" 占位条目（2026-04-20）已替换为完整条目；overview.md Specialized 部门新增 specialized-french-consulting-market 条目置于 study-abroad-advisor 之后；Portage-Salarial 和 ESN 均已存在于 wiki/concepts/，无需重复创建，仅补充了本次来源的 sources 字段 - -## [2026-04-25] ingest | Blockchain Security Auditor -- Source file: Agent/agency-agents/specialized/blockchain-security-auditor.md -- Status: ✅ 成功摄入 -- Summary: Blockchain Security Auditor——The Agency Specialized 部门的智能合约安全审计 Agent，专职发现 DeFi 协议与区块链应用中的漏洞。自动化静态分析（Slither/Mythril/Echidna）+ 人工逐行审查 + 属性化模糊测试 + 经济博弈建模五步工作流。每个发现必须包含可复现 PoC；自动化工具只能捕获约 30% 的真实漏洞；OpenZeppelin 误用本身是漏洞类型。 -- Concepts created: [[Reentrancy]]（重入攻击，含单函数/跨函数/只读/ERC-777钩子四种模式及完整防御机制）、[[Oracle-Manipulation]]（预言机操纵，含AMM/TWAP/Chainlink三类模式及修复方案） -- Entities created: [[The-DAO-2016]]（2016年360万ETH重入攻击）、[[Euler-Finance]]（2023年1.97亿美元donate-to-reserves攻击）、[[Nomad-Bridge]]（2022年1.9亿美元未初始化代理漏洞）、[[Curve-Finance]]（2023年7000万美元Vyper编译器bug） -- Source page: wiki/sources/blockchain-security-auditor.md -- Notes: overview.md 同步更新；index.md 消除了原 source missing 标记并补全了摘要 - -## [2026-04-25] ingest | Agents Orchestrator -- Source file: Agent/agency-agents/specialized/agents-orchestrator.md -- Status: ✅ 成功摄入 -- Summary: Agents Orchestrator——AI 多智能体开发流水线编排器，自主管理从规格到交付的完整开发流程。四阶段流水线（PM→ArchitectUX→[Dev↔QA循环]→最终集成），基于截图证据的质量门控，最大3次重试上限。 -- Concepts created: 无（Dev-QA-Loop、Quality-Gate 等概念均通过 Source Page 内 wikilinks 形式表达，未单独建 Concept 页面） -- Entities created: 无（ArchitectUX、EvidenceQA、TestingRealityChecker、ProjectManagerSenior 等在现有 wiki 中已作为 wikilinks 使用，无需新建 Entity 页面） -- Source page: wiki/sources/agents-orchestrator.md -- Notes: index.md 中原有 "source missing" 占位条目（2026-04-20）已替换为完整条目；overview.md Specialized 部门新增 Agents-Orchestrator 条目置于 identity-graph-operator 之后；与 specialized-workflow-architect 的职责关系已记录于 Contradictions 部分（设计层 vs 执行层，不存在功能重叠）。 - -## [2026-04-25] ingest | MCP Builder Agent -- Source file: Agent/agency-agents/specialized/specialized-mcp-builder.md -- Status: ✅ 成功摄入 -- Summary: MCP Builder Agent——AI Agent 的 MCP（Model Context Protocol）服务器开发专家，设计、构建、测试和部署 MCP 服务器，为 AI Agent 提供自定义工具（Tools）、资源（Resources）和提示词模板（Prompts）能力。核心理念：工具命名即 UX，正确选用率目标 >90%；技术栈 TypeScript+Zod 或 Python+Pydantic；核心原则：无状态设计、结构化错误返回、环境变量密钥、边界验证、真实 Agent 测试。 -- Concepts created: 无（Key Concepts 中 10 个术语均为 Source Page 内可解释的协议/框架级概念，通过 wikilinks 形式表达，不具备跨页面复用价值，未单独建 Concept 页面） -- Entities created: 无（MCP SDK/FastMCP/Zod/Pydantic 仅出现 1 次，不满足 ≥2 次条件，通过 Key Entities 链接保留在 Source Page） -- Source page: wiki/sources/specialized-mcp-builder.md -- Notes: index.md 中原有 "source missing" 占位条目（2026-04-20）已替换为完整条目；overview.md Specialized 部门新增 MCP Builder Agent 条目置于 visionos-spatial-engineer 之后；无冲突内容检测。 - -## [2026-04-25] ingest | Compliance Auditor Agent -- Source file: Agent/agency-agents/specialized/compliance-auditor.md -- Status: ✅ 成功摄入 -- Summary: Compliance Auditor Agent——The Agency Specialized 部门的技术合规审计专家，专注 SOC 2、ISO 27001、HIPAA、PCI-DSS 认证审计全流程。五步工作流：Scoping → Gap Assessment → Remediation Support → Audit Support → Continuous Compliance。核心原则：不跟随的政策比没政策更危险、证据必须证明整个审计周期持续有效、技术控制优于管理控制、自动化证据收集从第一天建立。 -- Concepts created: 无（Key Concepts 中 6 个术语均为 Source Page 内可解释的术语，不具备跨页面复用价值，未单独建 Concept 页面） -- Entities created: 无（SOC-2/ISO-27001/HIPAA/PCI-DSS 均为框架级标准，在多个来源中出现但以 wikilinks 形式表达，未单独建 Entity 页面） -- Source page: wiki/sources/compliance-auditor.md -- Notes: index.md 中原有 "source missing" 占位条目（2026-04-20）已移除并替换为完整条目；overview.md Specialized 部门新增 Compliance Auditor 条目置于 healthcare-marketing-compliance 之后；与 [[specialized-model-qa]] 在证据定义上的差异已记录于 Contradictions 部分。 - -## [2026-04-25] ingest | Specialized Salesforce Architect -- Source file: Agent/agency-agents/specialized/specialized-salesforce-architect.md -- Status: ✅ 成功摄入 -- Summary: Salesforce 企业级解决方案架构师 Agent — 多云架构设计（Sales/Service/Marketing/Commerce/Data Cloud/Agentforce）、企业集成模式（REST/Platform Events/CDC/MuleSoft）、数据模型设计与治理、Governor Limit 预算规划、CI/CD 部署策略（Salesforce DX/DevOps Center）。核心原则：Governor limits 不可协商、Bulkification 强制要求、Declarative-first、Trigger 只委托不分发、集成模式必须处理失败场景。 -- Concepts created: 无（技术术语通过 Source Page Key Concepts + wikilinks 表达，未单独建页面） -- Source page: wiki/sources/specialized-salesforce-architect.md -- Notes: 无冲突内容检测；MuleSoft、Shield Platform Encryption、DevOps Center 作为 Key Entities 链接保留在 Source Page；Platform Events vs CDC 对比表已提取为 Key Claims - -## [2026-04-25] ingest | Model QA Specialist -- Source file: Agent/agency-agents/specialized/specialized-model-qa.md -- Status: ✅ 成功摄入 -- Summary: Model QA Specialist——The Agency Specialized 部门的 ML/统计模型端到端独立审计专家 Agent，核心方法：10 大审计领域覆盖模型全生命周期（文档治理→数据重建→标签分析→分段评估→特征分析→模型复制→校准测试→性能监控→可解释性→业务影响），配套完整 Python 工具集（PSI 监控、Hosmer-Lemeshow 校准检验、SHAP 可解释性分析、PDP 偏依赖图、KS/AUC/Gini 判别指标）。核心原则：独立性、可复现性、证据链完整。成功指标：审计发现 95%+ 被确认有效、零部署后失败。 -- Concepts created: [[SHAP]]（特征归因可解释性框架）、[[Calibration-Testing]]（概率校准验证方法）、[[Discrimination-Metrics]]（判别能力指标体系 AUC/Gini/KS）、[[Partial-Dependence-Plots]]（偏依赖图）、[[Population-Stability-Index]]（群体稳定性指数）、[[Hosmer-Lemeshow-Test]]（校准拟合优度检验） -- Entities created: （The Agency Specialized 部门在多个来源中多次出现，本次检查 entities/ 目录已存在，未新建） -- Source page: wiki/sources/specialized-model-qa.md -- Notes: index.md 中原有 "source missing" 条目，本次摄入后已更新为完整条目。overview.md Specialized 部门新增 Model QA Specialist 条目置于 cultural-intelligence-strategist 之后。与 [[multi-agent-system-reliability]] 存在潜在张力（对抗辩论 vs 统计检验），已在 Contradictions 中记录。6 个 Concept 页面创建前已做去重检查，确认均不存在。与 specialized-workflow-architect（Reality Checker 验证）构成质量保障互补，已在 overview.md 建立链接关系。 - - -- Source file: Agent/agency-agents/specialized/corporate-training-designer.md -- Status: ✅ 成功摄入 -- Summary: Corporate Training Designer——The Agency Specialized 部门的企业培训体系架构师 Agent，核心方法：ADDIE 教学设计模型（分析→设计→开发→实施→评估）、Kirkpatrick 四级评估（反应→学习→行为→业务结果）、Bloom 认知六层次、Kolb 体验式学习圈、OMO 混合学习（线上认知→线下实践→社群持续）。核心价值观：优秀培训的衡量标准不是"教了什么"，而是"学员回去做了什么"。覆盖培训需求分析、课程体系设计、内容开发、内训师培养（TTT）、新员工培训、领导力发展（HIPO）、合规培训等全链路能力。 -- Concepts created: [[ADDIE-Model]]（ADDIE 教学设计模型）、[[Kirkpatrick-四级评估]]（培训效果四级评估框架）、[[Bloom-认知分类]]（认知六层次分类）、[[Kolb-体验式学习圈]]（体验式学习循环） -- Entities created: [[The-Agency]]（The Agency 多智能体系统组织，147 个 Agent 跨 12 部门） -- Source page: wiki/sources/corporate-training-designer.md -- Notes: index.md 中原有早期条目，本次为完整摄入。overview.md Specialized 部门新增 Corporate Training Designer 条目，并置于 Cultural Intelligence Strategist 之前（按摄取顺序）。4 个 Concept 页面创建前已做去重检查，确认均不存在。Corporate Training Designer 与 specialized-workflow-architect、cultural-intelligence-strategist 形成系统性设计能力互补，在 overview.md 中已建立链接关系。Corporate Training Designer 与其他 Agent 无明显内容冲突。 - -- Source file: Agent/agency-agents/specialized/specialized-cultural-intelligence-strategist.md -- Status: ✅ 成功摄入 -- Summary: Cultural Intelligence Strategist——The Agency Specialized 部门的文化包容性专家 Agent，核心职责：检测软件开发中的"隐性排斥"（Invisible Exclusion），包括 Western 默认命名结构、颜色语义冲突（红色=中国金融上涨）、性别二元假设、RTL 阅读方向等。通过四阶段工作流（盲点审计→自主研究→结构修正→解释原理）提供架构级文化智能解决方案。核心价值：将国际化从"亡羊补牢"提升为"架构前提条件"，拒绝表演性多元化，追求结构性包容。 -- Concepts created: [[Invisible-Exclusion]]（隐性排斥模式定义）、[[Architectural-Empathy]]（结构性同理心哲学）、[[Global-First-Architecture]]（国际化架构前提原则） -- Entities created: [[The-Agency]]（The Agency 多智能体系统组织，147 个 Agent 跨 12 部门） -- Source page: wiki/sources/specialized-cultural-intelligence-strategist.md -- Notes: index.md 中原有 "source missing" 条目，本次摄入后已更新为完整条目。overview.md Specialized 部门新增 Cultural Intelligence Strategist 条目。Concept 页面创建前已做去重检查，确认 Invisible-Exclusion、Architectural-Empathy、Global-First-Architecture 三个概念此前均不存在。与 [[InclusiveVisualsSpecialist]]（Design 部门包容性视觉专家）和 [[design-brand-guardian]]（品牌守护）存在跨部门协同与张力关系，已在 overview.md 和 source page Contradictions 中记录。 - -## [2026-04-25] ingest | Workflow Architect Agent Personality -- Source file: Agent/agency-agents/specialized/specialized-workflow-architect.md -- Status: ✅ 成功摄入 -- Summary: Workflow Architect——The Agency Specialized 部门的工作流设计专家 Agent，负责在代码编写前穷举建模系统所有路径。核心交付物：四视角工作流注册表（按工作流/按组件/按用户旅程/按状态）+ 工作流树规范格式（覆盖快乐路径+七类失败分支）+ 交接合同（Handoff Contract）+ 清理清单（Cleanup Inventory）。关键原则：不只为快乐路径设计，每个系统边界定义显式交接合同，Reality Checker 验证是 Draft 升为 Approved 的前置条件。Agent 协作协议：Reality Checker 验证→Backend Architect 实现→API Tester 生成测试用例→DevOps Automator 验证清理顺序。与 [[Designing-for-Agentic-AI]] 存在潜在冲突（确定性要求 vs LLM 概率性），已在 Contradictions 中记录。 -- Concepts created: [[Workflow-Registry]]（四视角工作流注册表）、[[Observable-States]]（四维度可观察状态）、[[Handoff-Contract]]（系统边界交接合同）、[[Workflow-Tree-Spec]]（结构化工作流树规范格式） -- Entities created: （Backend Architect/Reality Checker/API Tester/DevOps Automator/Security Engineer 在当前 sources 中出现次数均 < 2，暂不创建 Entity 页面） -- Source page: wiki/sources/specialized-workflow-architect.md -- Notes: index.md 中原有 "source missing" 条目，本次摄入后已更新为完整条目并修正日期。overview.md Specialized 部门新增 Workflow Architect 条目。Concept 页面创建前已做去重检查，Workflow-Engineering（已存在，定义侧重 AI 执行流程 vs 本文档侧重工作流规范格式）保留原页面，新增页面侧重建模规范维度。 - -## [2026-04-25] ingest | LSP/Index Engineer Agent Personality -- Source file: Agent/agency-agents/specialized/lsp-index-engineer.md -- Status: ✅ 成功摄入 -- Summary: LSP/Index Engineer——The Agency Specialized 部门的代码智能系统架构师 Agent，通过 graphd LSP 聚合器将 TypeScript/PHP/Go/Rust/Python 等多语言 LSP 客户端统一编排为语义图谱。核心交付物：多语言 LSP 并发编排 + 统一图谱模式（节点：文件/符号，边：contains/imports/calls/refs）+ nav.index.jsonl 语义索引 + WebSocket 实时增量推送 + 原子性图谱更新保证。性能北极星：/graph <100ms、/nav <60ms、WebSocket <50ms、100k+ 符号无性能降级。TypeScript 和 PHP 为默认生产就绪要求。 -- Concepts created: [[LSP-317-Specification]]（LSP 3.17 协议规范）、[[Semantic-Index-Infrastructure]]（语义索引基础设施）、[[Incremental-Graph-Update]]（增量图谱更新）、[[Performance-Contracts]]（性能契约） -- Entities created: [[The-Agency]]（The Agency 多智能体系统组织）、[[TypeScript-Language-Server]]（TypeScript 语言服务器）、[[Intelephense]]（PHP Intelephense LSP）、[[LSIF]]（Language Server Index Format） -- Source page: wiki/sources/lsp-index-engineer.md -- Notes: index.md 中原有 "source missing" 条目，本次摄入后已更新为完整条目。overview.md Specialized 部门新增 LSP/Index Engineer 条目，并同步更新 Conflict Areas（#12 LSP 图谱确定性 vs Workflow 穷举概率性）。4 个 Concept 页面创建前已做去重检查，确认 LSP-317-Specification、Semantic-Index-Infrastructure、Incremental-Graph-Update、Performance-Contracts 均不存在。与 [[specialized-workflow-architect]] 存在张力（确定性约束 vs LLM 概率性上限），已在 Contradictions 中记录。4 个 Entity 页面中 The-Agency 已在 overview.md 中被多次引用，新增 Entity 页面属首次正式创建。与 [[multi-agent-system-reliability]] 共享"架构约束优于提示词约束"思想，已在 overview.md 中建立链接。 - -## [2026-04-25] ingest | Agentic Identity & Trust Architect（补充摄入） -- Source file: Agent/agency-agents/specialized/agentic-identity-trust.md -- Status: ✅ 补充摄入（source page 已存在，本次补充 Concept 页面） -- Summary: Agentic Identity & Trust Architect——自主 Agent 身份认证与信任验证基础设施专家 Agent，解决多 Agent 环境中的身份伪造、授权冒用、审计日志篡改等安全威胁。核心方法：密码学身份体系（Ed25519）、零信任验证模型、惩罚型信任评分（初始1.0，证据链损坏扣0.5，结果失败率×0.4扣分，凭证超90天扣0.1）、append-only 哈希链式证据记录、多跳委托链验证（任意链节断裂则全链失效）、Fail-Closed 授权（无法验证时默认拒绝）、对等验证协议（Peer Verifier）。高级能力：算法敏捷性（后量子迁移预留抽象层）、NIST 后量子标准评估（ML-DSA/ML-KEM/SLH-DSA）、跨框架身份联邦（A2A/MCP/REST/SDK）。 -- Concepts created: [[Zero-Trust]]（永不信任，必须验证）、[[Evidence-Chain]]（哈希链式仅追加证据记录）、[[Trust-Scoring]]（基于可验证结果的惩罚型信任评分）、[[Delegation-Chain]]（多跳委托链验证）、[[Fail-Closed]]（失败默认拒绝授权）、[[Peer-Verification]]（对等验证协议）、[[Algorithm-Agility]]（密码学算法可升级性） -- Source page: wiki/sources/agentic-identity-trust.md -- Notes: 与 [[Identity Graph Operator]] 互补——前者处理 Agent 身份证明（密码学确定性），后者处理实体身份匹配（概率性），共同构成完整身份层。与 [[Designing-for-Agentic-AI]] 存在潜在冲突（零信任要求确定性 vs LLM 概率性），已在 Contradictions 中记录。本文件在 index.md中原标记为"source missing"，本次已补全为完整 source page。 -- Source file: Agent/agency-agents/specialized/specialized-document-generator.md -- Status: ✅ 成功摄入 -- Summary: Document Generator——The Agency Specialized 部门的程序化文档生成专家 Agent，通过代码方式（Python/Node.js）生成 PDF、PPTX、DOCX、XLSX 等专业文档。核心工具栈：PDF（reportlab/weasyprint/fpdf2）、PPTX（python-pptx/pptxgenjs）、XLSX（openpyxl/xlsxwriter/exceljs）、DOCX（python-docx/docx）。核心原则：样式系统优先、品牌一致性、数据驱动、无障碍设计、模板可复用。 -- Concepts created: 无（文档生成工具库不宜抽象为 Concept） -- Source page: wiki/sources/specialized-document-generator.md -- Notes: index 中已存在同名条目（来源缺失），本次摄入后标记为已解决。与 [[report-distribution-agent]]（文档分发）和 [[agents-orchestrator]]（工作流编排）存在潜在协同关系，建议后续摄入时补充连接。 - -- Source file: Agent/agency-agents/specialized/identity-graph-operator.md -- Status: ✅ 成功摄入 -- Summary: Identity Graph Operator——多智能体系统共享身份图谱运营专家 Agent，解决多 Agent 系统的身份孤岛问题（重复记录/冲突操作/级联错误）。核心方法：规范化（昵称扩展/E.164 电话/邮箱小写）→ 阻塞（blocking key 筛选候选）→ 评分（字段级加权）→ 聚类。merge/split 通过乐观锁执行，按置信度分级（>0.95 直接合并、0.6-0.95 提案审查、<0.6 创建新实体）。保留完整事件历史。 -- Concepts created: [[Identity-Resolution]]（身份解析四步流程框架）、[[Evidence-based-Merge-Proposal]]（证据驱动合并提案协议）、[[Blocking]]（阻塞分块技术）、[[Fuzzy-Matching]]（模糊匹配技术）、[[Confidence-Score]]（置信度评分与阈值决策） -- Source page: wiki/sources/identity-graph-operator.md -- Notes: 与 [[Designing-for-Agentic-AI]] 存在潜在冲突：确定性要求与 LLM 概率性行为如何协调，当前观点认为通过将核心逻辑从 LLM 推理分离来解决。index 中已存在同名 [[identity-graph-operator]] 条目（来源缺失），本次摄入后应标记为已解决。 - -## [2026-04-25] ingest | Accounts Payable Agent Personality -- Source file: Agent/agency-agents/specialized/accounts-payable-agent.md -- Status: ✅ 成功摄入 -- Summary: AccountsPayable Agent——The Agency 财务部门的自主支付运营专员 Agent，处理供应商付款、承包商发票和周期性账单，覆盖 ACH/Wire/Crypto/Stablecoin/Payment API 全支付通道。核心原则：幂等性优先（reference ID 去重，零重复付款）、审计全链路、最优通道路由（失败自动切换备选通道）、严格额度管控（超授权额度人工审批）。通过 tool calls 与 Contracts Agent、Project Manager Agent、HR Agent 集成。成功指标：零重复付款、< 2 分钟执行时间、100% 审计覆盖、60 秒 escalation SLA。 -- Concepts created: （文档内概念均为具体实现细节，不满足可独立复用条件，未创建 Concept 页面） -- Entities created: （各协作 Agent 在本文档中各仅出现 1 次，不满足出现 ≥ 2 次条件，未创建 Entity 页面） -- Source page: wiki/sources/accounts-payable-agent.md -- Notes: 无已知冲突。本文档为单一 Agent 设计文档，与 [[Accounts-Payable-Agent]] 协作的各 Agent 需在各自文档中补充对应协作关系。 - -## [2026-04-25] ingest | Specialized Civil Engineer Agent -- Source file: Agent/agency-agents/specialized/specialized-civil-engineer.md -- Status: ✅ 成功摄入 -- Summary: Civil Engineer Agent——全球设计标准覆盖的结构与土木工程专家 Agent，驾驭 Eurocode（EN 1990–1999 + 各国 National Annex）、ACI 318（LRFD/SD）、AISC 360、ASCE 7、GB/IS/AIJ 等全球主流建筑规范体系。核心方法：ULS+SLS 双重验证、多标准冲突处理（识别→记录→保守优先→Basis of Design）、岩土工程全流程。计算交付物：钢梁 AISC 360 LRFD 计算包、RC 梁 Eurocode EN 1992-1-1 计算包、Terzaghi 岩土地基承载力分析。六阶段工作流：项目范围→初步设计→详细计算→建造文档→规范合规→施工支持。 -- Concepts created: [[ULS]], [[SLS]], [[National-Annex]], [[LRFD]], [[Basis-of-Design]], [[BIM-Coordination]], [[Ductility-Class]] -- Entities created: [[Eurocode]], [[AISC-360]], [[ACI-318]], [[ASCE-7]], [[EN-1997]], [[AIJ]] -- Source page: wiki/sources/specialized-civil-engineer.md -- Notes: 无已知冲突。该 Agent 覆盖全球独立规范体系，各标准间差异已明确标注，不可混用。 - -- Source file: Agent/agency-agents/project-management/project-management-experiment-tracker.md -- Status: ✅ 成功摄入 -- Summary: Experiment Tracker Agent——The Agency 项目管理部门的实验追踪专家 Agent，专注于 A/B 测试、功能实验和假设验证的科学化管理。核心交付物：实验设计文档模板和实验结果报告模板。成功指标：95% 实验达统计显著性、每季度 15+ 实验、70% 成功率、80% 成功实验落地。高级能力：多臂老虎机、贝叶斯分析、因果推断、ML 模型 A/B 测试。 -- Concepts created: [[A/B-Testing]], [[Statistical-Significance]], [[Power-Analysis]], [[Hypothesis-Validation]], [[Experiment-Portfolio-Management]], [[Multi-Armed-Bandits]], [[Bayesian-Analysis]], [[Causal-Inference]] -- Entities created: [[Project-Management-Experiment-Tracker]] -- Source page: wiki/sources/project-management-experiment-tracker.md -- Notes: 与 [[Project-Management-Studio-Operations]] 存在潜在张力（实验节奏 vs 内容制作节奏），已记录于 Contradictions - -## [2026-04-25] ingest | Studio Operations Agent Personality -- Source file: Agent/agency-agents/project-management/project-management-studio-operations.md -- Status: ✅ 成功摄入 -- Summary: Studio Operations Agent——The Agency 项目管理部门的执行层 Agent，专注于工作室日常运营效率、流程优化和资源协调。核心交付物：SOP 模板（四步工作流：评估→协调→实施→监控）和运营效率报告模板。成功指标：95% 运营效率、99.5% 系统正常运行时间、年度成本降低 10%、支持响应时间 < 2 小时。 -- Concepts created: （本次未创建独立 Concept 页面——文档内各概念（Standard Operating Procedure/Operational Efficiency 等）均与 [[The Agency]] 生态强绑定，不满足可独立复用条件） -- Entities created: （本次未创建独立 Entity 页面——文档内唯一实体 [[The Agency]] 在 Wiki 中已有充分引用） -- Source page: wiki/sources/project-management-studio-operations.md -- Notes: 与 [[project-management-studio-producer]]（战略层）和 [[ProjectManagerSenior]]（任务分解层）构成完整项目管理体系层级；与 [[Project-Management-Jira-Workflow-Steward]] 和 [[Project-Management-Project-Shepherd]] 协同；index.md 中标记的 expected 条目已补全 - -## [2026-04-25] ingest | Senior Project Manager Agent Personality -- Source file: Agent/agency-agents/project-management/project-manager-senior.md -- Status: ✅ 成功摄入 -- Summary: Senior Project Manager——The Agency 项目管理部门的执行层 Agent，专注于将网站规格文档（site-setup.md）精准转化为 30-60 分钟可执行开发任务列表。核心方法：精确引用规格原则 + 务实范围控制（拒绝 luxury/premium 除非明确）+ 开发者优先任务描述。核心约束：不添加后台进程、不启动开发服务器、必须包含 Playwright 截图测试。 -- Concepts created: （本次未创建独立 Concept 页面——文档内各概念均仅出现 1 次，不满足 ≥ 2 次创建门槛） -- Entities created: （本次未创建独立 Entity 页面——文档内各实体均仅出现 1 次，不满足 ≥ 2 次创建门槛） -- Contradictions detected: 与 [[Project-Management-Project-Shepherd]] 存在职责边界张力——Senior PM 关注任务拆解细节，Shepherd 关注项目整体把控；两者形成执行层与规划层的协作关系，记录于 Source Page Contradictions 部分 -- Source page: wiki/sources/project-manager-senior.md -- Notes: index.md 占位符条目已替换（添加中文摘要）；overview.md 已补充 [[ProjectManagerSenior]] 独立段落，完善了项目管理层级的战略-执行协作关系描述 - -## [2026-04-25] ingest | Jira Workflow Steward Agent Personality -- Source file: Agent/agency-agents/project-management/project-management-jira-workflow-steward.md -- Status: ✅ 成功摄入 -- Summary: Jira Workflow Steward——交付纪律守护者 Agent，通过 Jira-Git 全链路绑定（Task→Branch→Commit→PR→Release）确保代码交付可审查、可回滚、可审计。核心机制：Jira Gate（无 Jira ID 则停止工作流）+ 分支策略（feature/bugfix/hotfix/release）+ Gitmoji 规范提交 + PR 模板 + Commit Hook 自动化验证。定位：Jira-linked commits 是质量工具而非合规打勾。 -- Concepts created: [[Jira-Git-Traceability]], [[Atomic-Commit]], [[Branch-Strategy]], [[Gitmoji-Commit]], [[Jira-Gate]], [[Pull-Request-Governance]], [[Delivery-Traceability]] -- Entities created: [[Jira-Workflow-Steward]], [[Gitmoji]] -- Contradictions detected: 与 [[Project-Management-Project-Shepherd]] 在职责边界存在互补张力——Steward 严格 gate（Jira ID 前置），若 Shepherd 未预创建任务则工作流中断，建议在 Shepherd 端增加预创建步骤；与 [[Project-Management-Studio-Producer]] 在交付粒度上属不同抽象层级（原子 commit vs 组合 Epic/Story），无直接冲突 -- Source page: wiki/sources/project-management-jira-workflow-steward.md -- Notes: 7 个 Concept 页面已创建并添加到 index.md；2 个 Entity 页面已创建（Jira-Workflow-Steward/Gitmoji）并添加到 index.md；source page 已添加与 Project-Management-Project-Shepherd 和 Studio-Producer 的跨文档矛盾记录；index.md 占位符条目已替换（2026-04-20 → 2026-04-25，添加中文摘要） - -## [2026-04-25] ingest | Project Shepherd Agent Personality -- Source file: Agent/agency-agents/project-management/project-management-project-shepherd.md -- Status: ✅ 成功摄入 -- Summary: Project Shepherd——AI Agent 项目管理人格，专职跨职能项目协调、时间线管理、干系人对齐与风险缓解。四阶段工作流：项目启动→团队组建→执行监控→质量交付。核心交付物：Project Charter 模板、Status Report 模板、风险缓解框架。成功指标：95% 按时交付、范围蔓延 < 10%、90% 风险提前缓解、干系人满意度 4.5/5。 -- Concepts created: （本次未创建独立 Concept 页面——文档内各概念均仅出现 1 次，不满足 ≥ 2 次创建门槛） -- Entities created: （本次未创建独立 Entity 页面——文档内各实体均仅出现 1 次，不满足 ≥ 2 次创建门槛） -- Contradictions detected: 无。本文档与 [[Project-Management-Studio-Operations]] 和 [[Project-Management-Senior]] 在项目管理层级上互补而非冲突，属层级差异。 -- Source page: wiki/sources/project-management-project-shepherd.md -- Notes: index.md 占位符条目已替换（2026-04-20 → 2026-04-25，添加中文摘要）；overview.md 第 65 行已包含 [[Project-Management-Project-Shepherd]] wikilink（项目管理层级链一环），无需额外修订 - -## [2026-04-25] ingest | Studio Producer Agent Personality -- Source file: Agent/agency-agents/project-management/project-management-studio-producer.md -- Status: ✅ 成功摄入 -- Summary: Studio Producer——The Agency 项目管理部门的高管级战略领导者 Agent，专注于创意愿景与商业目标对齐的组合管理。核心职责：战略组合规划（Tier 1/2/Innovation Pipeline 三级）、Portfolio ROI 管理（≥ 25%）、95% 按时交付率、高管级利益相关者沟通。四阶段工作流：战略规划→项目编排→领导力发展→绩效优化。 -- Concepts created: [[Strategic-Portfolio-Management]], [[Resource-Allocation]], [[Portfolio-ROI]], [[Innovation-Pipeline]], [[Stakeholder-Alignment]] -- Entities created: [[Studio-Producer]] -- Contradictions detected: 与 [[Project-Management-Studio-Operations]] 在战略（Producer）与运营（Operations）的权责边界存在张力，需通过 Portfolio Review 机制对齐；与 [[Project-Manager-Senior]] 的管理广度差异（组合 vs 单项目）属层级差异而非矛盾 -- Source page: wiki/sources/project-management-studio-producer.md -- Notes: 已在 overview.md 新增 "The Agency — Project Management 部门" 章节（位于 Paid Media 部门之前），包含 Studio Producer 完整段落及与其他项目管理 Agent 的层级关系描述；5 个 Concept 页面已创建；index.md 中 source 条目已替换（2026-04-20 → 2026-04-25）；Studio-Producer Entity 页面已创建并添加至 index.md - -## [2026-04-25] ingest | visionOS Spatial Engineer Agent Personality -- Source file: Agent/agency-agents/spatial-computing/visionos-spatial-engineer.md -- Status: ✅ 成功摄入 -- Summary: visionOS Spatial Engineer——Apple visionOS 26 原生空间计算 Agent，专注于 SwiftUI volumetric interfaces 和 Liquid Glass Design System 实现。核心能力：Liquid Glass 透明材质设计、Spatial Widgets、SwiftUI Volumetric APIs、RealityKit-SwiftUI 集成、Multi-Window Architecture、GPU 高效渲染。技术栈：SwiftUI / RealityKit / ARKit / Metal。 -- Concepts created: [[Liquid-Glass-Design-System]], [[Spatial-Widgets]], [[SwiftUI-Volumetric-APIs]], [[RealityKit-SwiftUI-Integration]], [[Multi-Window-Architecture]] -- Entities created: [[XR-Interface-Architect]], [[XR-Immersive-Developer]], [[XR-Cockpit-Interaction-Specialist]], [[macOS-Spatial-Metal-Engineer]] -- Contradictions detected: 与 [[XR-Immersive-Developer]] 在平台选择上存在差异（WebXR 跨平台 vs visionOS 原生独占），已记录于 Source Page Contradictions 部分；与 [[macOS-Spatial-Metal-Engineer]] 在技术栈选择上存在张力（SwiftUI 声明式 vs Metal 底层渲染），已记录为互补关系 -- Source page: wiki/sources/visionos-spatial-engineer.md -- Notes: index.md 已替换占位符条目（2026-04-20 → 2026-04-25，添加摘要描述）；overview.md 已新增独立段落（位于 macOS Spatial/Metal Engineer 段落后）；5 个 Concept 页面已创建并添加到 index.md；4 个 Entity 页面已创建（XR-Interface-Architect/XR-Immersive-Developer/XR-Cockpit-Interaction-Specialist/macOS-Spatial-Metal-Engineer）并添加到 index.md；相关 Entity 和 Concept 页面的 sources 列表已更新 - -## [2026-04-25] ingest | XR Interface Architect Agent Personality -- Source file: Agent/agency-agents/spatial-computing/xr-interface-architect.md -- Status: ✅ 成功摄入 -- Summary: XR Interface Architect——专注为 AR/VR/XR 沉浸式环境设计空间直觉化 UX/UI 的 AI Agent，支持 HUD / 浮动菜单 / 交互区域，支持四种输入模型（直接触摸/注视+捏合/控制器/手势），以人体工程学约束减少晕动症，构建座舱/仪表盘/可穿戴界面布局模板，运行可用性验证实验 -- Concepts created: [[SpatialInterfaceDesign]], [[MotionSicknessMitigation]], [[PresenceEnhancement]], [[MultimodalInput]], [[HUDDesign]] -- Entities created: [[XRImmersiveDeveloper]], [[XRCockpitInteractionSpecialist]] -- Contradictions detected: 无内容冲突；该 Agent 侧重界面设计与 UX，与侧重底层渲染工程的 [[macOS Spatial/Metal Engineer]] 不在同一问题域 -- Source page: wiki/sources/xr-interface-architect.md -- Notes: 更新了 overview.md 中 [[xr-cockpit-interaction-specialist]] 条目的层级关系描述（原文为 [[XR-Interface-Architect]]，现统一为小写 slug）；Entity 仅出现 1 次，不足独立建页阈值，通过 Sources 页面 Key Entities 建立链接 - -## [2026-04-25] ingest | Terminal Integration Specialist -- Source file: Agent/agency-agents/spatial-computing/terminal-integration-specialist.md -- Status: ✅ 成功摄入 -- Summary: Terminal Integration Specialist——专注于终端仿真、文本渲染优化和 SwiftTerm 集成的 Agent，服务于现代 Swift 应用程序（iOS/macOS/visionOS）。核心能力：VT100/xterm ANSI 转义序列完整支持、SwiftTerm 库集成、Core Graphics 文本渲染优化、SSH I/O 桥接（SwiftNIO SSH/NMSSH）、无障碍支持（VoiceOver/动态类型）。 -- Concepts created: [[VT100/xterm Standards]], [[SwiftTerm]], [[Core Graphics Optimization]], [[SSH I/O Bridging]], [[Scrollback Buffer]], [[Accessibility Integration]] -- Contradictions detected: 无明显内容冲突；该 Agent 专注于 Apple 平台和 SwiftTerm，与通用终端解决方案不在同一问题域 -- Source page: wiki/sources/terminal-integration-specialist.md -- Notes: 相关页面已建立连接：[[visionOS Spatial Engineer]] / [[macOS Spatial Metal Engineer]] / [[XR Interface Architect]] 均依赖终端集成能力；Entity 层面 SwiftTerm/SwiftNIO SSH/NMSSH/Core Graphics/Core Text 仅出现 1 次，不足独立建页阈值，通过 Sources 页面的 Key Entities 部分建立链接 - -## [2026-04-25] ingest | XR Immersive Developer Agent Personality -- Source file: Agent/agency-agents/spatial-computing/xr-immersive-developer.md -- Status: ✅ 成功摄入 -- Summary: XR Immersive Developer Agent——WebXR 沉浸式开发专家，基于 A-Frame/Three.js/Babylon.js 构建跨平台浏览器 AR/VR/XR 体验。核心能力：WebXR Device API 全套沉浸式支持（hand tracking / pinch / gaze / controller）、raycasting / hit testing / 实时物理交互、LOD / occlusion culling / shader tuning 性能优化、跨设备兼容层（Meta Quest / Vision Pro / HoloLens / mobile AR）。典型交付物：VR 训练模拟器、AR 可视化界面、空间界面。 -- Concepts created: [[Spatial-Computing]], [[WebXR]], [[Hand-Tracking]] -- Contradictions detected: 与 [[XR-Cockpit-Interaction-Specialist]] 在运动自由度设计上存在张力——后者强调固定视角约束（降低运动病），前者倾向开放空间沉浸体验；冲突点已记录于 overview.md 第 52 条及 [[xr-cockpit-interaction-specialist]] 来源页 Contradictions 节 -- Source page: wiki/sources/xr-immersive-developer.md -- Notes: Concept 页面 Spatial-Computing/WebXR/Hand-Tracking 已创建并添加到 index.md；overview.md 新增 xr-immersive-developer 独立段落（位于 Paid Media 部门之前）；Entity 层面，Meta Quest/Vision Pro/HoloLens/Mobile-AR 仅出现 1-2 次，不足独立建页阈值，通过 Sources 页面的 Key Entities 部分建立链接 - -## [2026-04-25] ingest | Sales Engineer Agent -- Source file: Agent/agency-agents/sales/sales-engineer.md -- Status: ✅ 成功摄入 -- Summary: Sales Engineer Agent——售前工程师 Agent，专注于在 B2B 技术评估中赢得技术决策。核心理念：技术决策先于商业合同，售前工程师必须将每一次技术对话连接到业务成果。核心能力：Demo Engineering（以影响力为导向的演示设计）+ POC Scoping（严格限定的概念验证）+ FIA Framework（Fact-Impact-Act 竞争定位）+ 技术异议解码 + 评估笔记维护。成功指标：技术赢率 70%+，POC 转化率 80%+，演示到下一步行动率 90%+，中位数 18 天技术决策。 -- Concepts created: [[Demo-Engineering]], [[POC-Scoping]], [[FIA-Framework]], [[Technical-Objection-Handling]], [[Aha-Moment]] -- Contradictions detected: 与 [[Sales Discovery Coach Agent]] 在技术发现阶段参与深度上存在张力——前者主张售前主导技术发现，后者主张销售发现以业务语言建立信任，已记录于 overview.md Conflict Areas 第 6 条 -- Source page: wiki/sources/sales-engineer.md -- Notes: 5 个新 Concept 页面已创建；overview.md 新增 sales-engineer 独立段落；index.md 新增 Sales Engineer Agent 条目；Conflict Areas 新增第 6 条；Entity 层面，Sales Engineer 与同团队其他 Agent 均仅出现 1-2 次，不足独立 Entity 建页阈值，已通过 Sources 页面的 Key Entities 部分建立链接 - -## [2026-04-25] ingest | Pipeline Analyst Agent -- Source file: Agent/agency-agents/sales/sales-pipeline-analyst.md -- Status: ✅ 成功摄入 -- Summary: Pipeline Analyst Agent——Revenue Operations 领域的 Pipeline 健康诊断与收入预测 AI Agent。核心框架：Pipeline Velocity =（合格机会数 × 平均 Deal 规模 × 胜率）/ 销售周期长度；质量调整覆盖度（高质量少量 Pipeline 优于大量低质量 Pipeline）；MEDDPICC Deal 健康评分（资格深度 + 互动强度 + 进展速度三维度 0-36 分）；多信号预测模型（历史转化 + Velocity 加权 + 互动调整 + 季节性 + AI 模式匹配）。预测输出 Commit（>90%）/Best Case（>60%）/Upside（<60%）三档。 -- Concepts created: [[MEDDPICC]], [[PipelineVelocity]], [[DealHealthScoring]], [[QualityAdjustedCoverage]] -- Contradictions detected: sales-coach.md 描述 MEDDPICC 为"六个维度"，正确为八个维度，已修正 -- Source page: wiki/sources/sales-pipeline-analyst.md -- Notes: Entity 层面，Pipeline Analyst 与 Sales Deal Strategist / Sales Account Strategist / Sales Coach 存在依赖关系，待相关 Source 页面完善后可进一步深化链接 - -## [2026-04-25] ingest | Outbound Strategist Agent -- Source file: Agent/agency-agents/sales/sales-outbound-strategist.md -- Status: ✅ 成功摄入 -- Summary: Outbound Strategist Agent——信号型出站销售策略师，将出站从"批量轰炸"转变为"精准触发"。核心理念：信号驱动出站转化率比无触发出站高 4-8 倍；信号半衰期 30 分钟，24 小时后失效，72 小时后竞争对手已成交。核心框架：三层信号分级体系（主动购买/组织变化/技术行为）+ 可证伪 ICP 定义 + 三层账户分级（Tier 1 深度多线程 / Tier 2 半个性化 / Tier 3 自动化轻定制）+ 8-12 触点 3-4 周多渠道序列。冷邮件回复率基准：泛化 1-3%、角色定制 5-8%、信号驱动 12-25%、推荐引入 30-50%。SDR 角色演变：从批量操作员 → 深度账户专家。 -- Concepts created: [[Signal-Based-Selling-Framework]], [[ICP (Ideal Customer Profile)]], [[Multi-Channel-Sequence-Architecture]], [[Account-Tiering-Model]] -- Concepts updated: [[Challenger-Sales-Model]]（sources 添加 sales-outbound-strategist）、[[Land-and-Expand]]（sources 添加 sales-outbound-strategist） -- Entities linked: Outbound Strategist Agent, SDR -- Source page: wiki/sources/sales-outbound-strategist.md -- Notes: overview.md 新增"### Sales Outbound Methodology"章节（位于 Sales Discovery Methodology 之前）；index.md Concepts 节新增 4 个概念条目；Entity 页面未创建（Outbound Strategist Agent 和 SDR 均仅出现 1 次，不足独立建页阈值）；与 [[sales-deal-strategist]] 的漏斗互补关系已记录（出站=漏斗顶部，Deal=漏斗中部） - -## [2026-04-25] ingest | Deal Strategist Agent -- Source file: Agent/agency-agents/sales/sales-deal-strategist.md -- Status: ✅ 成功摄入 -- Summary: Deal Strategist Agent——高级deal策略师与管线架构师智能体，专注于MEDDPICC资质评分、竞争定位和复杂B2B销售周期的赢单规划。核心理念：每个deal都是战略问题而非关系练习；MEDDPICC全面推行的组织赢率提升18%、deal规模扩大24%；Commit deals预测准确率85%+；Qualified Pipeline（28/40+）赢率35%+；永远不做单线程账户。核心框架：MEDDPICC八维评分（每维度5分，满分40）+ Challenger商业教学六步序列 + 竞争三区定位（Winning/Battling/Losing）+ 地雷问题布局 + 交易检查方法论。 -- Concepts updated: [[MEDDPICC]]（新增 Deal-Level Application 和 Deal Verdict Categories）、[[Challenger Sales Model]]（新增 Commercial Teaching 六步序列） -- Entities linked: [[Sales Coach Agent]], [[Discovery Coach Agent]], [[Sales Proposal Strategist]], Deal Strategist Agent（均出现1次，不足独立Entity建页阈值） -- Source page: wiki/sources/sales-deal-strategist.md -- Notes: index.md 已替换占位符条目（2026-04-20 → 2026-04-25）；overview.md 已新增独立段落（Sales Coaching Methodology 章节末尾）；MEDDPICC 和 Challenger Sales Model 两个 Concept 页面均已更新 sources 列表 + 新增 sales-deal-strategist 专属内容；未创建新 Entity/Concept 页面（Deal Scoring/Competitive Positioning/Win Planning 等概念在 sales-deal-strategist 源文档中均仅出现1次，不足独立建页阈值）；与 [[sales-discovery-coach]] 的"发现→策略"协同关系已记录；与 [[sales-proposal-strategist]] 在"策略分析 vs 叙事构建"上的互补关系已记录于 Contradictions - -## [2026-04-25] ingest | Account Strategist Agent -- Source file: Agent/agency-agents/sales/sales-account-strategist.md -- Status: ✅ 成功摄入 -- Summary: Account Strategist Agent——售后账户扩张策略师智能体，专门负责 Land-and-Expand 执行、QBR 设计、利益相关者映射和净收入留存（NRR）最大化。核心理念：最佳销售时机是客户成功时；永远不做单线程账户；NRR 是终极指标。核心框架：扩张信号四维度（信号+情境+时机+利益相关者对齐）、账户健康三色评分（绿扩张/黄稳定/红救流失）、多线程关系建设（每账户至少三条独立关系线）。 -- Concepts created: [[Land-and-Expand]], [[Net Revenue Retention (NRR)]], [[Account Health Score]] -- Entities linked: Account Executive (AE), Customer Success (CS), Product Team, Executive Sponsor -- Source page: wiki/sources/sales-account-strategist.md -- Notes: 与 [[sales-proposal-strategist]] 的"赢单叙事"互补（前者构建叙事，后者交付超越叙事）；与 [[sales-coach]] 协同（后者辅导卖方，前者辅导买方冠军）；与 [[sales-discovery-coach]] 形成完整销售生命周期覆盖（发现→赢单→扩张）；overview.md 新增"Sales Account Expansion Methodology"主题节；创建 3 个独立 Concept 页面（Land-and-Expand、NRR、Account Health Score） - -## [2026-04-25] ingest | Sales Proposal Strategist -- Status: ✅ 成功摄入 -- Summary: Sales Proposal Strategist——将 RFP 响应转化为赢单叙事的系统化提案方法论。核心框架：三幕提案叙事结构（理解挑战→解决方案旅程→转变状态）+ 3-5 个赢标主题矩阵 + 执行摘要五步模板 + 说服架构（首因/近因效应、认知负荷管理、社会认同排序、损失厌恶框架）。核心理念：提案在开篇100词决定胜负；叙事是差异化核心；永远不直接批评竞争对手；定价在价值之后；内容库按赢标主题而非章节组织。 -- Concepts created: [[WinThemes]], [[ThreeActProposalNarrative]], [[PersuasionArchitecture]] -- Entities linked: 无特定命名实体 -- Source page: wiki/sources/sales-proposal-strategist.md -- Notes: 与 [[sales-coach]] 在"辅导行为 vs 撰写结构"上形成 Sales 体系互补关系；与 [[sales-discovery-coach]] 的发现阶段输入为提案策略提供买方情境；无冲突发现；overview.md 暂不需要更新 - -## [2026-04-25] ingest | Sales Coach Agent -- Source file: Agent/agency-agents/sales/sales-coach.md -- Status: ✅ 成功摄入 -- Summary: Sales Coach Agent——AI 销售教练 Agent，通过苏格拉底式提问驱动销售代表成长。核心辅导框架：Richardson Sales Performance（四维能力）、Challenger 辅导模型、MEDDPICC 资质诊断。关键方法论：辅导行为而非结果；一次只做一件事；管道质量是管理工具；挑战"happy ears"要求可验证的承诺。数据支撑：正式辅导项目配额完成率91.2%，vs 非正式辅导84.7%；每周2小时辅导赢单率56%，vs 少于30分钟43%。 -- Concepts created: MEDDPICC, Challenger Sales Model -- Entities linked: Discovery Coach Agent（已有）、Sales Pipeline Analyst Agent（已有）、Sales Deal Strategist Agent（已有） -- Source page: wiki/sources/sales-coach.md -- Notes: 与 Discovery Coach Agent 的辅导焦点层次差异已记录于 Contradictions；source页面内 Key Concepts 详细记录了 MEDDPICC、Challenger、Richardson Sales Performance 等框架；overview.md 新增"Sales Coaching Methodology"主题节，置于"Sales Discovery Methodology"之后，两者协同关系已明确 - -## [2026-04-25] ingest | Discovery Coach Agent -- Source file: Agent/agency-agents/sales/sales-discovery-coach.md -- Status: ✅ 成功摄入 -- Summary: Discovery Coach Agent——销售发现访谈方法论教练智能体，坚信发现是交易成败的真正战场。整合三大发现框架（SPIN Selling / Gap Selling / Sandler Pain Funnel）+ 标准30分钟发现电话结构（开场2分钟 / 发现18分钟 / 定向pitch 6分钟 / 下一步4分钟）+ AECR异议处理框架（Acknowledg/Empathize/Clarify/Reframe）。核心原则：发现不是审讯，Implication问题通过激活损失厌恶推动成交，60/40规则（买家说话60%以上），最优秀销售多问一个问题。 -- Concepts created: SPIN Selling（作为wikilink保留于source页面内）、Gap Selling（同）、Sandler Pain Funnel（同）、AECR Framework（同）、Upfront Contract（同）、Discovery Call Structure（同） -- Entities linked: Neil Rackham（同）、Keenan（同）、Sandler（同） -- Source page: wiki/sources/sales-discovery-coach.md -- Notes: Entity/Concept页面未单独创建（均首次出现且可抽象为独立概念，建议在后续摄入相关源文件时再评估）；未发现与现有Wiki内容的冲突；overview.md新增"Sales Discovery Methodology"主题节；source页面内详细记录了各框架的定义和引用 - -## [2026-04-25] ingest | Paid Media Ad Creative Strategist Agent -- Source file: Agent/agency-agents/paid-media/paid-media-creative-strategist.md -- Status: ✅ 成功摄入 -- Summary: 付费媒体广告创意策略 Agent——由 John Williams（@itallstartedwithaidea）设计，专注于 Google、Meta、Microsoft 及程序化平台的全渠道广告文案创作、响应式搜索广告（RSA）架构设计和系统性创意测试框架。核心理念：创意是自动化竞价环境中最大的可控杠杆，当算法接管了出价、预算和定向时，每一条标题、描述、图片和视频都是一个待验证的假设。 -- Concepts created: [[ResponsiveSearchAds]], [[AdStrength]], [[CreativeFatigue]], [[HookBodyCTA]], [[ABTesting]], [[MessageMatch]], [[AdExtensions]] -- Entities linked: [[GoogleAds]], [[MetaAdsManager]], [[MicrosoftAdvertising]], [[PerformanceMax]], [[JohnWilliams]]（已存在） -- Source page: wiki/sources/paid-media-creative-strategist.md -- Notes: 与 [[paid-media-ppc-strategist]] 在"自动化 vs 创意质量"权衡上的张力已记录于 Contradictions；与 [[paid-media-programmatic-buyer]] 在"创意新鲜度"上的潜在冲突已记录；与 [[paid-media-paid-social-strategist]] 协同关系已记录（受众洞察→平台原生创意执行）；overview.md 中 paid-media-creative-strategist 条目已从简略描述更新为完整条目，Key Concepts 行已更新 - -## [2026-04-25] ingest | Paid Social Strategist -- Source file: Agent/agency-agents/paid-media/paid-media-paid-social-strategist.md -- Status: ✅ 成功摄入 -- Summary: 跨平台付费社交广告专家 Agent，覆盖 Meta（Facebook/Instagram）、LinkedIn、TikTok、Pinterest、X 和 Snapchat，设计从引流到再营销的全漏斗社交广告项目。核心理念：社交广告本质是"打断"而非"回答"，必须构建平台原生体验而非跨平台复用创意。 -- Concepts created: [[Full-Funnel-Campaign-Architecture]], [[Custom-Audience-Engineering]], [[Conversions-API]], [[Advantage+-Campaigns]], [[Incrementality-Testing]], [[SKAdNetwork]] -- Entities created: [[Meta-Ads-Manager]], [[LinkedIn-Campaign-Manager]], [[TikTok-Ads]]; [[JohnWilliams]] 已更新 -- Source page: wiki/sources/paid-media-paid-social-strategist.md -- Notes: 与 [[paid-media-programmatic-buyer]] 在"自动化 vs. 控制"权衡上存在张力已记录于 Contradictions；与 [[paid-media-ppc-strategist]] 在跨渠道预算分配验证原则上有协同关系；与 [[paid-media-creative-strategist]] 在受众策略→创意方向上有依赖关系已记录 - -## [2026-05-06] ingest | Paid Media Search Query Analyst Agent -- Source file: Agent/agency-agents/paid-media/paid-media-search-query-analyst.md -- Status: ✅ 成功摄入 -- Summary: 付费媒体搜索词分析师 Agent——由 John Williams（@itallstartedwithaidea）设计，专注于从用户真实搜索词中挖掘洞察、构建分层负关键词架构、系统化提升付费搜索账户信噪比。核心能力：N-gram 分析、查询意图分类、匹配类型优化、查询雕塑（Query Sculpting）、浪费支出识别、关键词机会挖掘。核心理念：搜索查询优化是持续系统而非一次性任务，每浪费一美元在不相关查询上就是从转化查询中偷走一美元。成功指标：首次分析识别并消除 10-20% 非转化支出、无关查询展示占比 <5%、查询意图对齐度 80%+。 -- Concepts linked: [[SearchQueryOptimization]], [[NegativeKeywordArchitecture]], [[NgramAnalysis]], [[IntentClassification]], [[QuerySculpting]], [[SQOSScoring]], [[CloseVariantAnalysis]], [[WasteIdentification]], [[QueryClustering]], [[MatchTypeOptimization]], [[BrandVsNonbrandLeakageAnalysis]], [[CompetitorQueryInterception]], [[ShoppingSearchTermAnalysis]], [[PerformanceMaxInsights]] -- Entities linked: [[JohnWilliams]], [[GoogleAdsMCP]] -- Source page: wiki/sources/paid-media-search-query-analyst.md -- Notes: index.md 已替换占位符条目（2026-04-20 → 2026-05-06）；overview.md 已有 paid-media-search-query-analyst 条目（line 63），本次摄入更新了 Key Claims 和 Key Quotes，补充了 [[GoogleAdsMCP]] Entity；Concepts 和 Entities 在其他源页面中均仅出现 1 次，不足独立建页阈值（≥2 次），以 wikilink 形式记录于 Source page；与 [[paid-media-ppc-strategist]] 的协同关系已记录（策略制定依赖查询分析结果），与 [[paid-media-auditor]] 的协同关系已记录（审计触发查询分析需求） - -## [2026-05-05] ingest | Paid Media Auditor Agent -- Source file: Agent/agency-agents/paid-media/paid-media-auditor.md -- Status: ✅ 成功摄入 -- Summary: 企业级付费媒体账户审计 Agent——系统化评估 Google Ads、Microsoft Ads 和 Meta Ads 账户，覆盖 200+ 检查点（账号结构/追踪配置/竞价策略/创意/受众/竞争定位），每项发现附严重程度和预估业务影响。核心能力：8 大审计维度（账号结构/追踪/竞价/关键词/创意/Shopping/竞争定位/Landing Page）+ 历史趋势分析 + 合规审计。核心理念：像审计财务报表一样审计广告账户，不遗漏任何设置、假设和每一分钱。成功指标：审计通常识别 15-30% 效率提升机会，80%+ 高优先级建议 30 天内落地。 -- Concepts linked: [[AccountAudit]], [[ConversionTracking]], [[AttributionModeling]], [[BidStrategy]], [[QualityScore]], [[NegativeKeywordManagement]], [[AuctionInsights]], [[Dayparting]], [[ResponsiveSearchAds]], [[ProductFeedOptimization]], [[LandingPageAudit]], [[CompetitivePositioning]] -- Entities linked: [[JohnWilliams]], [[GoogleAds]], [[MicrosoftAdvertising]], [[AmazonAds]], [[GA4]], [[GTM]] -- Source page: wiki/sources/paid-media-auditor.md -- Notes: index.md 已替换占位符条目（2026-04-20 → 2026-05-05）；overview.md 已更新 paid-media-auditor 条目，补充 200+ 检查点框架和成功指标；所有 Entity/Concept 均仅出现 1 次，不足独立建页阈值（≥2 次），以 wikilink 形式记录于 Source page；与 [[paid-media-ppc-strategist]]（架构即战略 vs 现状审计）和 [[paid-media-programmatic-buyer]]（下漏斗 vs 上漏斗指标）的互补张力已记录于 Contradictions 节 - -## [2026-05-05] ingest | Paid Media PPC Campaign Strategist Agent -- Source file: Agent/agency-agents/paid-media/paid-media-ppc-strategist.md -- Status: ✅ 成功摄入 -- Summary: 企业级付费搜索与效果媒体策略 Agent——由 John Williams（@itallstartedwithaidea）设计，专注 Google Ads、Microsoft Advertising、Amazon Ads 三大平台。核心能力：分层活动架构（品牌/非品牌/竞品/征服）、Smart Bidding（tCPA/tROAS/Max Conversions/Max CV）、Performance Max 资产组设计、Google Ads API 自动化、MCC 级策略、增量测试框架。核心理念：账户架构即战略——活动/广告组/受众/信号系统协同驱动业务成果。成功指标：品牌展示份额 90%+、非品牌 40-60%、QS 7+ 占比 70%+、日预算消耗率 95-100%、季度转化量增长 15-25%。 -- Concepts created: [[PerformanceMax]], [[SmartBidding]], [[AccountArchitecture]], [[TieredCampaignArchitecture]], [[IncrementalityTesting]], [[ConversionActionHierarchy]], [[CustomerMatch]], [[BudgetPacing]] -- Entities created: [[GoogleAds]], [[MicrosoftAdvertising]], [[AmazonAds]], [[JohnWilliams]] -- Source page: wiki/sources/paid-media-ppc-strategist.md -- Notes: index.md 已新增 Sources 条目；Entities（4个）和 Concepts（8个）均已创建并添加到 index.md；overview.md 已新增 "The Agency — Paid Media 部门" 章节，整合了所有 Paid Media Agent 的协同关系；冲突已识别并记录：与 [[paid-media-programmatic-buyer]] 在预算分配方向上存在张力（高意图搜索流量 vs 品牌曝光），记录于 Source Page Contradictions 部分 - -## [2026-05-05] ingest | Paid Media Programmatic & Display Buyer Agent -- Source file: Agent/agency-agents/paid-media/paid-media-programmatic-buyer.md -- Status: ✅ 成功摄入 -- Summary: 战略性程序化购买与展示广告 Agent——覆盖 Google Display Network、DV360、The Trade Desk、Amazon DSP 等 DSP 平台，支持 Demandbase/6Sense/RollWorks ABM 展示广告策略，管理 25+ 合作伙伴媒体 AMP 计划。以受众优先为核心（正确的人在正确的上下文以正确的频次触达），强调可见性（70%+ MRC 标准）、品牌安全（IVT <3%）、频次管理（3-7 次/月）。通过 MCP 工具与 Google Ads API 集成实现自动化：placement 性能报告拉取、GDN 广告位排除、跨账户审计自动化。 -- Concepts linked: [[Programmatic Buying]], [[ABM Display]], [[Viewability]], [[Invalid Traffic]], [[Frequency Cap]], [[Supply Path Optimization]], [[Partner Media AMP]], [[MRC Standard]], [[CTV/OTT Advertising]], [[Brand Lift Measurement]] -- Entities linked: [[DV360]], [[The Trade Desk]], [[Amazon DSP]], [[Google Display Network]], [[Demandbase]], [[6Sense]], [[RollWorks]], [[John Williams]] -- Source page: wiki/sources/paid-media-programmatic-buyer.md -- Notes: index.md 已插入新条目至 paid-media-paid-social-strategist 之前；Entity/Concept 均未达到独立建页阈值（N=1）；冲突已识别并记录：与 paid-media-paid-social-strategist 在效果衡量指标上的差异（展示广告看上漏斗指标 vs 社交广告看直接转化指标） - -## [2026-05-05] ingest | Visual Storyteller Agent -- Source file: Agent/agency-agents/design/design-visual-storyteller.md -- Status: ✅ 成功摄入 -- Summary: Visual Storyteller Agent 角色定义——视觉叙事与品牌故事创作专家智能体，专注于将复杂信息转化为引人入胜的视觉叙事内容，驱动情感共鸣和用户参与。核心交付物：叙事弧创作（Beginning-Middle-End 三幕结构）、情感旅程映射、数据可视化叙事、跨平台视觉策略（Instagram/TikTok/YouTube/LinkedIn/Pinterest）。核心原则：叙事结构优先、情感驱动、品牌一致性（95%+触点）、WCAG 可访问性标准。成功指标：参与度提升 50%+、故事完成率 80%、品牌认知度提升 35%、视觉内容表现优于纯文本 3x。与 [[design-brand-guardian]] 互补（品牌叙事体系 vs 具体视觉内容），与 [[design-inclusive-visuals-specialist]] 协同（包容性视觉融入叙事），与 [[UX-Researcher]] 协同（用户洞察驱动情感旅程），与 [[design-whimsy-injector]] 互补（宏观叙事弧 vs 微交互趣味），共同为 [[LuxuryDeveloper]] 提供完整的品牌体验设计支撑。 -- Concepts linked: [[Story-Arc-Creation]], [[Emotional-Journey-Mapping]], [[Data-Storytelling]], [[Cross-Platform-Adaptation]], [[Motion-Graphics]], [[Visual-Pacing]], [[Progressive-Disclosure]], [[Brand-Narrative-Strategy]] -- Entities linked: [[Visual-Storyteller-Agent]], [[The-Agency]], [[LuxuryDeveloper]] -- Source page: wiki/sources/design-visual-storyteller.md -- Notes: index.md 已替换占位符条目（2026-04-20 → 2026-05-05）；overview.md 已新增独立段落（置于 design-whimsy-injector 和 design-image-prompt-engineer 之间）；无新 Entity/Concept 需创建（所有概念均为方法论术语，不足独立建页阈值）；无内容冲突检测到 - -## [2026-05-05] ingest | UI Designer Agent Personality -- Source file: Agent/agency-agents/design/design-ui-designer.md -- Status: ✅ 成功摄入 -- Summary: UI Designer Agent 角色定义——视觉界面设计专家智能体，专注于视觉设计系统、组件库和像素级界面交付。核心交付物：设计令牌系统（CSS 变量管理颜色/字体/间距/阴影/过渡）、响应式设计框架（Mobile-first，4个断点 640/768/1024/1280px）、可访问性标准（WCAG AA，色彩对比度 4.5:1）、组件文档与设计 QA 流程。核心理念：Design System First（先建组件基础再创建界面）、Accessibility Built-In（从架构层面内置无障碍）、Developer Handoff（详细规格实现 90%+ 准确率）。与 [[design-brand-guardian]] 互补（品牌身份 vs 视觉执行），与 [[design-whimsy-injector]] 存在张力——前者追求 95%+ 视觉一致性，后者在规范内注入趣味元素，通过预定义可配置槽位协调。与 [[ArchitectUX]]（技术架构）和 [[UX-Researcher]]（用户研究）协同，构成 [[The Agency]] 设计部门完整设计支撑体系。 -- Concepts linked: [[Design-System]], [[Design-Tokens]], [[Visual-Hierarchy]], [[Responsive-Design]], [[WCAG-AA]], [[Component-Library]], [[Dark-Mode]], [[Design-QA]], [[Accessibility-First-Design]] -- Entities linked: [[The Agency]], [[ArchitectUX]], [[design-brand-guardian]], [[design-whimsy-injector]], [[UX-Researcher]], [[LuxuryDeveloper]] -- Source page: wiki/sources/design-ui-designer.md -- Notes: index.md 已新增 Sources 条目（置于 design-brand-guardian 之前）；overview.md 已新增独立段落并替换原有 design-ux-architect 条目，新增 design-brand-guardian 条目，调整各 Agent 描述使其更准确；无新 Entity/Concept 需创建（Design-System/WCAG/Component-Library 等概念均在 Agency Agent 系统上下文中以方法论形式出现，不足独立建页阈值）；与 [[design-whimsy-injector]] 存在一致性与趣味性的张力，已记录于 Contradictions 部分——通过预定义可配置槽位协调（如微交互动画） - -## [2026-05-05] ingest | Design Brand Guardian -- Source file: Agent/agency-agents/design/design-brand-guardian.md -- Status: ✅ 成功摄入 -- Summary: Brand Guardian Agent 角色定义——品牌战略与身份守护专家智能体，负责创建 cohesive 品牌体系、确保跨所有触点的品牌表达一致性、并通过品牌保护策略维护品牌价值。核心交付物：品牌战略框架（Purpose/Vision/Mission/Values/Personality 五要素）、视觉身份系统（CSS 变量定义的品牌色彩/字体/间距/Logo 变体）、品牌声音指南、品牌保护策略。核心原则：Brand-First（先建品牌基础再战术执行）、一致性优先（95%+ 触点保持一致）、战略性演进（随市场变化成长而不失核心身份）。与 [[design-whimsy-injector]] 互补（Brand Guardian 建边界，Whimsy Injector 在边界内注入个性），共同为 [[LuxuryDeveloper]] 提供完整品牌体验设计。与 [[ArchitectUX]]（技术架构）和 [[UX-Researcher]]（用户研究）协同，构成 [[The Agency]] 设计部门完整设计支撑体系。 -- Concepts linked: [[Brand-Strategy]], [[Visual-Identity-System]], [[Brand-Voice-Guidelines]], [[Brand-Protection-Strategy]] -- Entities linked: [[The Agency]], [[ArchitectUX]], [[design-whimsy-injector]], [[UX-Researcher]], [[LuxuryDeveloper]] -- Source page: wiki/sources/design-brand-guardian.md -- Notes: index.md 已替换占位符条目；overview.md 已新增独立段落（置于 design-whimsy-injector 和 multi-agent-system-reliability 之间）；无新 Entity/Concept 需创建（Brand-Strategy/Visual-Identity-System/Brand-Voice-Guidelines/Brand-Protection-Strategy 及 ArchitectUX/LuxuryDeveloper 仅出现 1 次，不足建页阈值）；与 [[design-whimsy-injector]] 存在品牌一致性与创意表达的张力，已记录于 Contradictions 部分——两者互补而非互斥 - -## [2026-04-24] ingest | Inclusive Visuals Specialist -- Source file: Agent/agency-agents/design/design-inclusive-visuals-specialist.md -- Status: ✅ 成功摄入 -- Summary: Inclusive Visuals Specialist Agent 角色定义——包容性视觉表征专家智能体，专门对抗 AI 图像/视频生成模型（Midjourney、Sora、Runway Gen-3、DALL-E）中内嵌的系统性刻板印象偏见，生成具有文化真实性、尊严感和无歧视性的人类视觉表征。核心挑战：克隆脸（Clone Faces）、异域化偏见（Exoticism Bias）、文化符号乱码、地理/建筑失真。核心技术：结构化提示词架构（Subject → Sub-actions → Context → Camera Spec → Color Grade → Explicit Exclusions）+ 负向提示库 + 视频物理学定义。四阶段工作流：Brief Intake → Annotation Framework → Video Physics Definition → 7-Point QA Review Gate。成功指标：表征准确度 100%、AI 伪影消除率 100%、社区验证认可。 -- Concepts created: [[InclusiveVisuals]], [[NegativePromptingLibrary]] -- Concepts linked: [[IntersectionalRepresentation]], [[CommunityValidation]], [[AIArtifactElimination]], [[PromptEngineering]] -- Entities linked: [[TheAgency]], [[Midjourney]], [[Sora]], [[Runway-Gen-3]], [[DALL-E]], [[InclusiveVisualsSpecialist]] -- Source page: wiki/sources/design-inclusive-visuals-specialist.md -- Notes: index.md 已替换占位符条目（2026-04-20 → 2026-04-24）；overview.md 已新增 InclusiveVisualsSpecialist 独立段落（置于 design-image-prompt-engineer 和 design-brand-guardian 之间）；新增 Concept 页面 [[InclusiveVisuals]] 和 [[NegativePromptingLibrary]]；与 [[design-image-prompt-engineer]] 互补（摄影美学精准度 vs 消除表征偏见），与 [[design-whimsy-injector]] 存在张力——Kumbaya 库存照片套路和表演性象征主义是包容性设计必须坚决拒绝的 - -## [2026-04-24] ingest | UX Researcher Agent Personality -- Source file: Agent/agency-agents/design/design-ux-researcher.md -- Status: ✅ 成功摄入 -- Summary: UX Researcher Agent 角色定义——用户体验研究专家智能体，通过定性和定量研究方法验证设计决策。核心交付物：用户画像模板、用户旅程映射、可用性测试协议、A/B 测试框架。核心理念：研究方法论优先、证据优先沟通、研究推荐 80%+ 实施率。与 [[ArchitectUX]]（技术架构）和 [[design-whimsy-injector]]（品牌趣味）协同，共同为 [[LuxuryDeveloper]] 提供完整的用户中心设计支撑。 -- Concepts linked: [[Mixed-Methods Research]], [[Usability Testing]], [[User Persona]], [[User Journey Mapping]], [[Triangulation]], [[A/B Testing]], [[Accessibility Research]], [[Behavioral Analytics]], [[Research Repository]] -- Entities linked: [[Design Teams]], [[Product Teams]], [[Stakeholders]], [[The Agency]] -- Source page: wiki/sources/design-ux-researcher.md -- Notes: index.md 已新增 Sources 条目；overview.md 已新增独立段落（Multi-Agent AI Systems 主题下，置于 design-whimsy-injector 之前）；无新 Entity/Concept 需创建（大多数概念和实体在源文档中出现次数不足建页阈值）；与 [[design-whimsy-injector]] 存在设计理性与创意表达的互补张力，已记录于 Contradictions 部分 - -## [2026-05-05] ingest | Design Whimsy Injector -- Source file: Agent/agency-agents/design/design-whimsy-injector.md -- Status: ✅ 成功摄入 -- Summary: Whimsy Injector Agent 角色定义——品牌个性化和愉悦感注入专家，通过战略趣味设计为品牌体验增添个性、微交互和游戏化元素。核心交付物：品牌个性框架（专业/休闲/错误/成功四种场景人格光谱）、Whimsy 分类学（微妙/交互/发现/情境四类趣味）、微交互设计系统（CSS 动画 + 彩蛋 + 成就系统）。核心理念：有目的的趣味 + 包容性愉悦设计。与 [[ArchitectUX]] 互补，共同为 [[LuxuryDeveloper]] 提供完整品牌体验设计。 -- Concepts linked: [[Whimsy-Injector]], [[Micro-Interaction-Design]], [[Gamification-System]], [[Inclusive-Delight-Design]] -- Entities linked: [[ArchitectUX]], [[LuxuryDeveloper]], [[The Agency]] -- Source page: wiki/sources/design-whimsy-injector.md -- Notes: index.md 已替换占位符条目；overview.md 已新增独立段落（置于 design-ux-architect 和 multi-agent-system-reliability 之间）；无新 Entity/Concept 需创建（ArchitectUX/LuxuryDeveloper/Micro-Interaction-Design 等仅出现 1 次，不足建页阈值）；无内容冲突 - -## [2026-05-05] ingest | Contributing to The Agency -- Source file: Agent/agency-agents/CONTRIBUTING.md -- Status: ✅ 成功摄入 -- Summary: The Agency 多智能体框架贡献者指南英文原版——涵盖 Code of Conduct、四大贡献方式（创建智能体/优化现有/分享案例/报告问题）、智能体设计模板（YAML frontmatter + 结构化文档）、五大设计原则（鲜明性格/明确交付物/可量化指标/验证工作流/学习记忆）、PR 流程规范（单文件优先/Discussion 前置/提交前检查）、代码风格指南。 -- Concepts linked: [[Agent-Design-Principles]], [[Agent-Template]], [[Multi-Agent-Team]], [[Multi-Agent-System-Reliability]] -- Entities linked: [[The Agency]], [[OpenClaw]], [[msitarzewski]] -- Source page: wiki/sources/contributing.md -- Notes: index.md 已替换占位符条目；overview.md 已更新 contributing_zh-cn 条目，补充英文原版 wikilink；无新 Entity 需创建（msitarzewski/The Agency 仅出现 1 次，不足建页阈值）；无实质内容冲突，与 contributing_zh-cn 差异属语言版本差异 - -## [2026-05-05] ingest | 为 The Agency 贡献代码 -- Source file: Agent/agency-agents/CONTRIBUTING_zh-CN.md -- Status: ✅ 成功摄入 -- Summary: The Agency 项目（agency-agents）贡献者指南，定义智能体设计规范、贡献流程和社区标准。核心贡献方式：创建全新智能体（8大分类）、优化现有智能体、分享成功案例、反馈问题。智能体设计五原则：鲜明性格、明确交付物、可量化指标、经过验证的工作流、学习记忆。PR 流程含提交前检查（真实场景测试、遵循模板、补充示例）、社区评审与迭代优化。 -- Concepts created: [[Agent-Design-Principles]], [[Agent-Template]] -- Entities created: none（The Agency 已在 Wiki 中存在引用，无需新建 Entity 页面） -- Concepts linked: [[Multi-Agent-System-Reliability]], [[Multi-Agent-Team]] -- Source page: wiki/sources/contributing_zh-cn.md -- Notes: index.md 已新增 Sources 条目；overview.md 已新增独立段落（Multi-Agent AI Systems 主题下，置于 multi-channel-assistant 之前）；Agent-Design-Principles 和 Agent-Template 为新创建 Concept 页面；无 Entity 需创建；无冲突内容 - -## [2026-05-05] ingest | CTP Topic 12 Using SES SMTP service terraform module -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/ctp-topic-12-using-ses-smtp-service-terraform-module.md -- Status: ✅ 成功摄入 -- Summary: Christian Deckelmann 和 Filos Christolakis 主讲，Micro Focus 团队通过 Terraform 模块自动化部署 AWS SES SMTP 服务以替代传统本地 SMTP 网关——SES 是网络安全部门唯一批准的云端邮件发送方案；Terraform 模块封装 SMTP 终端节点配置，支持现有应用程序通过标准 SMTP 协议集成；VPC 端点私有连接 + IAM 用户凭证转 SMTP 认证信息存储于 Secrets Manager；自动化 DKIM 验证和 Infoblox DNS 记录创建；两个手动步骤（脱离 Sandbox Mode + 手动更新 DNS TXT 记录）；未来计划收件人限制和凭证滚动更新。 -- Concepts created: [[VPC-Endpoint]], [[DKIM-Email-Authentication]], [[SES-Sandbox-Mode]] -- Entities created: none（Christian Deckelmann、Filos Christolakis、Infoblox 出现频次不足建页阈值，以 wikilink 形式记录于 Source page） -- Concepts linked: [[Infrastructure-as-Code]], [[Secrets-Management]] -- Source page: wiki/sources/ctp-topic-12-using-ses-smtp-service-terraform-module.md -- Notes: index.md 已替换占位符条目（日期 2026-04-14）；overview.md 已新增独立段落（Terraform 段落末尾，置于 RDS via Terraform 和 Topic 21 之间）；VPC-Endpoint/DKIM-Email-Authentication/SES-Sandbox-Mode 为新创建 Concept 页面；Secrets-Management 已存在，已建立 wikilink；无其他 Entity 需创建 -- Conflicts: 与 [[ctp-topic-36-sendgrid-as-an-email-service]] 在邮件服务选型上的差异——SendGrid 被选定为新标准云邮件服务，SES 则服务现有应用通过 SMTP 协议平滑迁移上云，两者互补而非互斥 - -## [2026-05-05] ingest | design-ux-architect -- Source file: Agent/agency-agents/design/design-ux-architect.md -- Status: ✅ 成功摄入 -- Summary: ArchitectUX 智能体角色定义——为 LuxuryDeveloper 提供坚实的技术架构和 UX 基础。核心交付物：CSS 设计系统（颜色/排版/间距令牌，light/dark/system 三模式）、响应式布局框架（Grid/Flexbox/mobile-first）、ThemeManager JS 类、信息架构规范。核心原则：Foundation-First 和消除开发者架构决策疲劳。所有新站点强制要求主题切换功能。 -- Concepts linked: none（CSS 设计系统/ThemeManager 等属单一来源概念，以 wikilink 形式记录于 Source page，不足建 Concept 页阈值） -- Entities linked: [[ArchitectUX]], [[LuxuryDeveloper]], [[The Agency]] -- Source page: wiki/sources/design-ux-architect.md -- Notes: index.md 已替换占位符条目；overview.md 已新增独立段落（置于 multi-agent-system-reliability 之前）；无新 Entity/Concept 需创建（ArchitectUX/LuxuryDeveloper 仅出现 1 次，不足建 Entity 页阈值）；无实质内容冲突 - -## [2026-05-05] ingest | Learning Sessions Cloud Transformation Programme-20230808 183322-Meeting Recording -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi.md -- Status: ✅ 成功摄入 -- Summary: JP 和 Raja M 主讲，CTP/SRE 团队通过 Terraform IaC 实现 ECS 容器化应用自动化部署——基于 Gruntwork 仓库构建 ECS 模块，支持 Docker 容器/EC2 部署；核心功能：自动扩缩容、自动故障恢复、金丝雀部署；Listener 集中管理方式；前置条件：VPC/ELB 安全组/EFS 卷挂载；集成 CloudWatch/Splunk/Grafana/Prometheus。ECS 作为 AWS 原生技术与 AWS 服务深度集成。 -- Concepts linked: [[Infrastructure-as-Code]], [[Canary-Deployment]], [[ECS-Module]] -- Entities linked: [[Gruntwork]], [[AWS]], [[Cloud-Transformation-Programme]] -- Source page: wiki/sources/learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi.md -- Notes: index.md 已替换占位符条目；overview.md 已新增同主题 wikilink；JP 和 Raja M 各出现 1 次，不足独立 Entity 建页阈值，以 wikilink 形式记录于 Source page；无实质性内容冲突，ECS vs EKS 选型差异记录于 Contradictions 节 -- Conflicts: 与 [[ctp-topic-64-scaling-out-with-amazon-eks]] 在容器编排选型上的差异——ECS 强调 AWS 原生集成，EKS 强调可移植性，两者适用于不同场景但可互补 - -## [2026-05-05] ingest | CTP Topic 16 Cross-account Terraform modules -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/ctp-topic-16-cross-account-terraform-modules.md -- Status: ✅ 成功摄入 -- Summary: Fibos 主讲，多账号 AWS 环境中跨账号 Terraform 模块的中心化部署方案——基于 Shared Account（共享账号）作为中转站，Jenkins + ECS Deploy Runner + Assume Role 三联动。核心机制：Jenkins 检测 `cross-account.json` 标记文件触发 ECS Deploy Runner，通过 Assume Role 访问目标账号的 TF state bucket accessor 和 cross-account ECS deploy runner role。三大目标：安全性（无 Workload 账号间直接信任）、自动化（Jenkins 自动识别模块类型）、可复用性（模块代码不硬编码特定账号角色）。 -- Concepts created: [[Cross-account-Terraform-Modules]] -- Entities created: none（Gruntwork 已存在） -- Source page: wiki/sources/ctp-topic-16-cross-account-terraform-modules.md -- Notes: index.md 已替换占位符条目；overview.md 已新增独立段落（置于 ECS Deployment 和 Topic 21 之间）；Entity Jenkins/Fibos 提及次数不足建页阈值，以 wikilink 形式记录于 Source page；无实质性内容冲突，演进关系记录于 Contradictions 节 - -## [2026-05-05] ingest | Learning Sessions ECS Deployment using IAC - 20230808 -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording.md -- Status: ✅ 成功摄入 -- Summary: JP 和 Raja M 主讲，CTP/SRE 团队通过 Terraform IaC 实现 ECS 容器化应用自动化部署——基于 Gruntwork 仓库构建 ECS 模块，支持 Docker 容器/EC2 部署；核心功能：自动扩缩容、自动故障恢复、金丝雀部署；Listener 集中管理方式；前置条件：VPC/ELB 安全组/EFS 卷挂载；集成 CloudWatch/Splunk/Grafana/Prometheus。ECS 作为 AWS 原生技术与 AWS 服务深度集成。 -- Concepts created: [[Canary-Deployment]], [[Infrastructure-as-Code]] -- Entities created: [[Gruntwork]] -- Source page: wiki/sources/learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording.md -- Notes: index.md 已替换占位符条目；overview.md 已新增独立段落（置于 Terraform 工具选型后）；ECS 与 EKS 选型冲突记录于 Contradictions 节；JP 和 Raja M 各出现 1 次，不足独立 Entity 建页阈值，以 wikilink 形式记录于 Source page；无其他内容冲突 -- Conflicts: 与 [[ctp-topic-64-scaling-out-with-amazon-eks]] 在容器编排选型上的差异——ECS 强调 AWS 原生集成，EKS 强调可移植性，两者适用于不同场景但可互补 - -## [2026-05-05] ingest | CTP Topic 48 Terraform vs Terragrunt -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/ctp-topic-48-terraform-vs-terragrunt.md -- Status: ✅ 成功摄入 -- Summary: Bob（AWS Solutions Architect）对比 Terraform 与 Terragrunt——Terraform（HashiCorp 出品）是云厂商无关的 Golang 应用，通过状态文件绑定期望状态与实际环境；Terragrunt 是轻量封装，贯彻 DRY 原则，管理 provider 和 remote_state 块减少跨环境重复声明。两者命令和语法高度一致，Terragrunt 通过减少硬编码优化大规模企业部署。辅助工具：Terraform Enterprise、Gruntwork、Atlantis、tfsec、Terratest -- Concepts created: [[DRY Principle]], [[State-File-Management]] -- Entities created: [[HashiCorp]], [[Terragrunt]], [[Atlantis]] -- Entities updated: [[Terraform]], [[Gruntwork]] -- Concepts updated: [[Infrastructure-as-Code]] -- Source page: wiki/sources/ctp-topic-48-terraform-vs-terragrunt.md -- Notes: 视频由 Gemini 摘要，原文状态为 "summarized (Gemini 摘要)"；来源 NAS 路径为 `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 48_ Terraform vs Terragrunt.mp4` - -## [2026-05-05] ingest | Public Cloud Learning Sessions (OpenText) - AI Use Cases - 20241126 160106 -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec.md -- Status: ✅ 成功摄入 -- Summary: AWS AI 专家 Stephen Frank 分享 Gen2 AI 发展驱动力（数据爆发+算力提升）、企业级 AI 应用场景（客户体验/洞察提取/流程自动化/内容生成）、AWS 三层产品战略（基础设施→Bedrock→AI 应用）、数据差异化策略（RAG/Fine-tuning/持续预训练）、Amazon Q 企业知识问答、负责任 AI 原则 -- Concepts linked: [[RAG]], [[Fine-Tuning]], [[Continued-Pre-Training]], [[Responsible-AI]] -- Entities linked: [[AWS]], [[Amazon-Bedrock]], [[Amazon-SageMaker]], [[Amazon-Q]], [[Stephen-Frank]] -- Source page: wiki/sources/public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec.md -- Notes: index.md 已替换占位符条目（日期修正为 2026-04-14）；overview.md 已新增独立段落（Serverless & AI 专题，置于提示工程后）；RAG/Fine-Tuning/Responsible-AI/Stephen-Frank/Amazon-Q/Amazon-SageMaker 在 wiki 中出现频次不足独立建页阈值，以 wikilink 形式记录于 Source page；无内容冲突 -- Conflicts: 无 - -## [2026-05-05] ingest | Public Cloud Learning Sessions (OpenText) - Event Driven Architecture Part 2 - 20240917 -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091.md -- Status: ✅ 成功摄入 -- Summary: EDA 进阶实践——三组件（事件生产者/消费者/代理）、事件路由器（EventBridge/SNS）与事件存储（SQS/Kinesis）、编排与编排模式（Choreography vs Orchestration）、幂等性、事件排序、去中心化团队所有权、Fan-out 模式、竞争消费者模式、死信队列、EventBridge 最佳实践 -- Concepts updated: [[Event-Driven-Architecture]]（补充 Part 2 内容：EDA 三组件、编排模式对比、生产级最佳实践：幂等性/事件排序/团队独立性、扩展 Event Patterns：Fan-Out/Competing Consumer/DLQ） -- Entities existing (no new): [[AWS]], [[Amazon-EventBridge]], [[Amazon-SQS]], [[Amazon-SNS]], [[AWS-Lambda]], [[AWS-Step-Functions]] -- Source page: wiki/sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091.md -- Notes: index.md 已替换占位符条目（日期修正为 2026-05-05）；overview.md 已添加 Part 2 独立段落（新增于 Serverless 段落和 Part 1 之间），同时更新 Part 1 引用指向 Part 2；Event-Driven-Architecture 概念页已更新 sources + last_updated，新增 EDA 三组件/编排模式/生产级最佳实践内容，扩展 Event Patterns；Kinesis-Data-Streams 出现 1 次，不足独立建 Entity 阈值，以 wikilink 形式记录于 Concept 页 -- Conflicts: 与 [[ctp-topic-64-scaling-out-with-amazon-eks]] 在扩展方式上的差异——EDA 通过事件驱动异步扩展（消费者按需处理），EKS 通过容器编排横向扩展（Pod 副本数调整），两者适用于不同场景但可互补使用 -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091.md -- Status: ✅ 成功摄入 -- Summary: EDA 入门——AWS 解决方案架构师 Dr. Anil Giri 介绍 EventBridge/SQS/SNS 事件驱动架构与 Enterprise Integration Patterns；会议因 Teams 屏幕共享故障仅完成开场介绍，完整演示参见 Part 2 -- Concepts linked: [[Event-Driven-Architecture]], [[Enterprise-Integration-Patterns]], [[Amazon-EventBridge]], [[Amazon-SQS]], [[Amazon-SNS]] -- Entities linked: [[Dr.-Anil-Giri]], [[AWS]], [[OpenText]], [[Micro-Focus]] -- Source page: wiki/sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091.md -- Notes: index.md 已替换占位符条目（日期修正为 2026-04-19）；overview.md 已补充（Serverless & AI 专题段落新增，置于无服务器计算后）；Dr. Anil Giri/AWS/OpenText/Micro Focus 在 wiki 中出现频次不足独立建 Entity 页阈值，以 wikilink 形式记录于 Source page；EventBridge/SQS/SNS/Enterprise-Integration-Patterns 概念频次不足独立建 Concept 页阈值；已建立与 Part 2（public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091）、无服务器计算（public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee）的 Connections 关系；冲突记录与 ctp-topic-64-scaling-out-with-amazon-eks 的扩展方式差异已记录于 Contradictions 节 -- Conflicts: 与 [[ctp-topic-64-scaling-out-with-amazon-eks]] 在扩展方式上的差异——EDA 通过事件驱动异步扩展，EKS 通过容器编排横向扩展，两者适用于不同场景但可互补使用 - -## [2026-05-05] ingest | Public Cloud Learning Sessions - Serverless Computing - 20240903 -- Status: ✅ 成功摄入 -- Summary: AWS 无服务器计算深度解析——Lambda 事件驱动模型（同步/异步/事件源映射）、Step Functions 状态机编排（Standard/Express）、API Gateway（边缘优化/区域/私有）、SAM 本地开发和部署；Serverless 业务价值（快速上市/按需付费/自动扩展/内置安全）；AWS 与客户共担运维责任 -- Entities created: [[AWS-Lambda]], [[AWS-Step-Functions]], [[Amazon-API-Gateway]], [[SAM-Serverless-Application-Model]] -- Concepts linked: [[Serverless-Computing]], [[Event-Driven-Architecture]] -- Source page: wiki/sources/public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee.md -- Notes: index.md 已更新（替换占位符条目，日期修正为 2026-04-14）；overview.md 已补充（Cloud Transformation & DevOps 章节新增独立段落，置于 AI/ML 入门与 CTP Topic 20 之间）；Entity 页均按字母顺序插入 index.md Entities 节；无内容冲突（Serverless-Computing 概念页已存在，内容一致） -- Conflicts: 无 - -## [2026-05-05] ingest | Public Cloud Learning Sessions - Introduction to AI/ML with AWS -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin.md -- Status: ✅ 成功摄入 -- Summary: AWS AI/ML 与生成式 AI 入门——AI 定义（复制人类智能任务的系统）、三类 AI（分类/预测/生成式 AI）、AWS 20 年 ML 积累、Amazon Bedrock 全托管服务（Titan 基础模型+微调+持续预训练+RAG+Agents+Guardrails）、SageMaker Canvas 无代码工具、ML Ops 数据/训练/推理三流水线 -- Concepts linked: [[RAG]], [[MLOps]], [[Foundation-Models]], [[Amazon-Bedrock]], [[Amazon-SageMaker-Canvas]], [[Responsible-AI]] -- Entities linked: [[AWS]], [[Amazon-Bedrock]], [[Amazon-Titan]] -- Source page: wiki/sources/public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin.md -- Notes: index.md 已更新（替换占位符条目）；overview.md 已补充（Cloud Transformation & DevOps 章节新增 Serverless & AI 专题段落，置于 FinOps 后）；Suraav Paul/AWS Senior Solutions Architect 仅出现 1 次，以 wikilink 形式记录于 Source page；RAG/MLOps/Responsible AI 频次不足独立建页阈值；本来源属于 Cloud Transformation Programme 的 Serverless & AI 专题（09_Serverless_AI）；无内容冲突 -- Conflicts: 无 - -## [2026-05-05] ingest | Cloud Learning Master Index -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/_Index/cloud-learning-master-index.md -- Status: ✅ 成功摄入 -- Summary: OpenText/微焦点云转型学习会话视频总索引——NAS 源 `/volume2/work/Public Cloud Learning Sessions/`，覆盖 10 大技术领域共 111 个视频：AWS Landing Zone（22）、OpenText Series（21）、EKS & Kubernetes（14）、Security（9）、Networking（9）、Serverless & AI（9）、FinOps & Cost（10）、CI/CD & GitOps（8）、IAM & Identity（3）、Terraform & IaC（6）。该索引是所有 CTP 专题视频的元数据入口。 -- Concepts created: 无（所有关键技术概念已通过其他来源创建独立页面；该索引为元数据文件，无需新建 Concept） -- Source page: wiki/sources/cloud-learning-master-index.md -- Notes: index.md 已更新（Sources 节新增条目置于顶部）；overview.md 已补充（Cloud Transformation & DevOps 章节新增 cloud-learning-master-index 段落）；CTP-Team 和 OpenText 以 wikilink 形式记录于 Source page（出现次数不足独立建页阈值）；Cloud-Transformation-Programme 已通过 Micro Focus Entity 页覆盖；无内容冲突 -- Conflicts: 无 - -## [2026-05-05] ingest | CTP Topic 27 AWS Instance Scheduler -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/ctp-topic-27-aws-instance-scheduler.md -- Status: ✅ 成功摄入 -- Summary: AWS Instance Scheduler 原生方案——通过 CloudFormation + CloudWatch Events（每15分钟）+ Lambda + DynamoDB 调度配置表，自动定时启停 EC2/RDS 实例；通过标签（Schedule/Period）关联调度规则；由 Guardrails 框架自动推送至公司月消费10美元以上账号；基于"时间表"而非"空闲率"触发；RDS 维护窗口智能协同；关机行为必须设为"停止"而非"终止" -- Concepts created: 无（所有概念仅出现 1 次，以 wikilink 形式记录于 Source page） -- Source page: wiki/sources/ctp-topic-27-aws-instance-scheduler.md -- Notes: index.md 已更新（替换占位符条目，日期修正为 2026-04-14）；overview.md 已补充（FinOps 章节新增段落，置于 ctp-topic-63 后）；已建立与 ctp-topic-13（政策框架）、ctp-topic-63（Terraform Scheduler 互补）、ctp-topic-71（RightSizing 互补）的 Connections 关系；冲突记录：与 ctp-topic-63 在实现路径上的差异（AWS 原生 vs Terraform 层）已于 Contradictions 节说明为互补而非互斥 -- Conflicts: 与 [[ctp-topic-63-optimise-resource-cost-using-automation]] 就 EC2/RDS 自动调度的实现路径差异——Instance Scheduler（AWS 原生方案）覆盖广账户层，Terraform Scheduler（IaC 层）提供细粒度控制，两者互补而非互斥 - -## [2026-04-25] ingest | CTP Topic 63 Optimise resource cost using automation -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/ctp-topic-63-optimise-resource-cost-using-automation.md -- Status: ✅ 成功摄入 -- Summary: 使用自动化手段优化 AWS 云资源成本——五大策略：批准区域标准化、Graviton ARM 实例选型（比 Intel 便宜 20-25%）、承诺计划（1年 40% / 3年 64% 折扣）、GP2→GP3 存储优化（节省 20%）、基于标签的 EC2/RDS 自动化调度（每天只运行 10 小时可节省 70% 成本） -- Concepts created: 无（已存在的 [[Savings-Plans]] 涵盖承诺计划；Graviton/RightSizing 等概念在本 wiki 中出现频次不足以独立建页） -- Source page: wiki/sources/ctp-topic-63-optimise-resource-cost-using-automation.md -- Notes: Pushka 演示 Terraform Scheduler 模块配置（`auto_shutdown = yes` 标签）；无内容冲突 - -## [2026-04-24] ingest | Public Cloud Learning Sessions - Best practices for EC2 cost optimization in AWS - 20240529 -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/public-cloud-learning-sessions-best-practices-for-ec2-cost-optimization-in-aws-2.md -- Status: ✅ 成功摄入 -- Summary: Mike Dukes 和 Steele Taylor（AWS 专家）主讲 EC2 成本优化最佳实践——AWS Nitro 系统外部化网络/存储/安全组件提升效率；Graviton ARM 处理器基于 ARM64 架构，提供 40% 性价比提升，功耗减少 60%；EC2 Spot 实例利用闲置容量提供 90% 折扣；购买选项包括 On-Demand/Savings Plans/Spot Instances；Spot Invaders 游戏展示容错混沌工程实践；Spot + Graviton + 容器组合实现最大化成本节省 -- Concepts created: [[Nitro-System]], [[EC2-Purchase-Options]] -- Concepts linked: [[Graviton]], [[Spot Instances]], [[Savings Plans]], [[FinOps]], [[Cloud Cost Optimization]] -- Entities identified: Mike Dukes 和 Steele Taylor 为演讲者，但提及次数不足 2 次，以 wikilink 形式记录于 Source page -- Source page: wiki/sources/public-cloud-learning-sessions-best-practices-for-ec2-cost-optimization-in-aws-2.md -- Notes: index.md 已更新（Sources 节新增条目）；overview.md 已补充（FinOps 章节新增段落，置于 ctp-topic-13 后）；Nitro-System 和 EC2-Purchase-Options 不存在于现有 Wiki，新建 Concept 页面；已建立与 public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco、ctp-topic-13-cloud-finops-policies 的 Connections 关系 -- Conflicts: 与 ctp-topic-14-octane-hub-on-aws 可能的冲突（Graviton 对有状态服务的适用性），已记录于 Source page Contradictions 节 - -## [2026-04-25] ingest | Public Cloud Learning Sessions - Storage Cost Optimization - 20240305 -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/public-cloud-learning-sessions-storage-cost-optimization-20240305-160037-meeting.md -- Status: ✅ 成功摄入 -- Summary: AWS EBS（GP3 20% 节省+独立扩展 IOPS/吞吐）、EFS/FSx（生命周期分层）、S3（Intelligent Tiering 自动冷热迁移+生命周期策略+PrivateLink 规避数据传输费）、ADM 三阶段迁移案例（OpenZFS → 自管理 NetApp on EC2 → FSx for NetApp ONTAP 实现 60% 成本削减） -- Concepts linked: [[EBS-GP3]], [[EBS-Snapshot-Archive]], [[Data-Lifecycle-Manager]], [[AWS-Backup]], [[EFS-Infrequent-Access]], [[S3-Intelligent-Tiering]], [[S3-Lifecycle-Policies]], [[FSx-for-NetApp-ONTAP]], [[AWS-PrivateLink]], [[FinOps]], [[Cloud Cost Optimization]] -- Entities linked: [[AWS]], [[ADM]] -- Source page: wiki/sources/public-cloud-learning-sessions-storage-cost-optimization-20240305-160037-meeting.md -- Notes: index.md 已更新（Sources 节新增条目，置于 ctp-topic-71 前）；overview.md 已补充（FinOps 章节新增存储成本优化专题段落）；ADM 提及仅 1 次，以 wikilink 形式记录于 Source page；所有 AWS 服务特性概念（EBS-GP3/Snapshot-Archive/EFS-IA/S3-IntelligentTiering 等）已记录于 Source page Key Concepts 节，暂不单独建页；已建立与 public-cloud-learning-sessions-reducing-cloud-costs-20250318、ctp-topic-13-cloud-finops-policies 的 Connections 关系 -- Conflicts: 与 ctp-topic-14-octane-hub-on-aws 可能的 EFS vs EBS 选型冲突，已记录于 Source page Contradictions 节 - -## [2026-04-25] ingest | Public Cloud Learning Sessions - Reducing Cloud Costs - 20250318 -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco.md -- Status: ✅ 成功摄入 -- Summary: Vinay（FinOps）主讲 AWS 云成本优化——工作负载优化（现代化：EC2 新代际/Graviton 20-25% 节省/AMD 6-10% 节省/GP2→GP3 存储 20% 节省/EKS 最新版避免扩展支持费/Spot 实例 90% 折扣）和 Right Sizing（EC2 Right Sizing 报告/实例调度/闲置资源清理）；费率优化（Savings Plans/RI 两种承诺类别 + 实施流程）；关键规则：承诺计划仅无预付选项，最低 $5k/年，仅 Phenops 团队实施 -- Concepts created: [[Savings-Plans]], [[Spot-Instances]] -- Concepts linked: [[Cloud Cost Optimization]], [[Graviton]], [[Right Sizing]], [[EKS Extended Support]], [[EDP (Enterprise Discount Program)]] -- Entities created: [[Vinay]], [[Phenops-Team]] -- Entities linked: [[AWS]] -- Source page: wiki/sources/public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco.md -- Notes: index.md 已更新（Sources 节新增条目，Entities 节新增 Phenops-Team 和 Vinay，Concepts 节新增 Savings-Plans 和 Spot-Instances）；overview.md 已补充（FinOps 章节新增段落，Key Entities 新增 Vinay 和 Phenops-Team）；Graviton/Spot-Instances/Savings-Plans 均满足 Concept 可复用条件，新建页面；Vinay 出现 ≥2 次新建 Entity，Phenops-Team 出现 ≥2 次新建 Entity；与 [[ctp-topic-13-cloud-finops-policies]] 构成政策层→技术实施层互补关系，已记录于 Connections；无内容冲突 -- Conflicts: 无 - -## [2026-04-25] ingest | CTP Topic 13 Cloud FinOps Micro Focus Policies best practices to optimize the costs -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co.md -- Status: ✅ 成功摄入 -- Summary: PCG 团队 Uday 和 Vinay 主讲 Cloud FinOps 成本优化政策与最佳实践；PCG 三层服务模型（成本管理→成本优化→治理与自动化）；5 大核心策略（账单可见性、标签合规、预算责任、Reserved Instances 集中管理、区域限制）；安全控制（Godrails/MFA/告警重定向）；Cloud Health 工具；标准化实例选型 + Graviton；研发环境三合一优化 -- Concepts identified: [[FinOps（云财务管理）]]（已存在）、[[Showback/Chargeback]]（已有引用） -- Entities identified: [[PCG]]（提及但 <2 次）、[[Cloud-Health]]（提及但 <2 次） -- Source page: wiki/sources/ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co.md -- Notes: PCG 和 Cloud Health 出现次数不足 2 次，不满足独立 Entity 页面创建条件，以 wikilink 形式记录于 Source page；index.md 已更新（替换 expected 条目为实际内容）；overview.md Cloud Transformation 章节已补充（置于 ctp-topic-65 后）；已建立与 ctp-topic-63（自动化调度优化）、ctp-topic-71（Rightsizing）、ctp-topic-27（AWS Instance Scheduler）的连接关系；FinOps 概念页已存在于 wiki/concepts/，无需新建 -- Conflicts: 与 [[ctp-topic-53-why-bother-with-cloud]] 存在视角差异：Topic 13 假设已在云上聚焦优化，Topic 53 聚焦是否应迁移的决策论证；已在 Source page Contradictions 节记录 - -## [2026-04-26] ingest | Public Cloud Learning Sessions - Budget Control - 20240319 -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/public-cloud-learning-sessions-budget-control-20240319-160204-meeting-recording.md -- Status: ✅ 成功摄入 -- Summary: SRE Core 团队（Daniela/Evan/Alan）分享 AWS Budget Control 自动化——解决账户蔓延导致的成本失控。核心架构：AWS Budget → SNS → Lambda → Step Functions → SCP Enforcement（服务控制策略封禁新资源创建）。4 类告警：Forecast/Actual 80-98%/Severe/Enforcement。Source Identity 通过 CloudTrail 追踪联邦登录跨角色切换的原始用户身份。初始范围仅限 Lab 账户。 -- Concepts created: [[AWS-Source-Identity]] -- Concepts linked: [[FinOps]], [[SCP-Enforcement]], [[CloudTrail]], [[Step-Functions]], [[Cost-Explorer]], [[AWS-Budget-Alerts]] -- Entities linked: [[SRE-Core-Team]], [[Phenops-Team]], [[NetIQ]] -- Source page: wiki/sources/public-cloud-learning-sessions-budget-control-20240319-160204-meeting-recording.md -- Notes: index.md 已更新（Sources 节新增条目，Concepts 节新增 AWS-Source-Identity）；overview.md 已补充（FinOps 章节新增段落，置于 reducing-cloud-costs-20250318 后）；AWS-Source-Identity 为 Source Identity 追踪机制的完整概念页，满足可复用条件；已建立与 ctp-topic-13（治理自动化政策层）、ctp-topic-63（主动优化）、reducing-cloud-costs-20250318（优化手段）的 Connections 关系；无内容冲突 - -## [2026-04-25] ingest | CTP Topic 15 Working with Renovatebot -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-15-working-with-renovatebot.md -- Status: ✅ 成功摄入 -- Summary: Paul Hopkins 主讲 Renovate Bot 自动化管理云原生基础设施依赖项更新；解决"依赖地狱"问题，实时扫描 Docker/Terraform/Terragrunt/pre-commit 版本标签并自动发起 Pull Request；通过 Dependency Dashboard 提供全局依赖状态视图；集成 Jenkins 流水线，使用 Podman 容器化运行并配置 Rate Limiting -- Concepts created: [[Renovate-Bot]], [[Dependency-Management]], [[Semantic-Versioning]] -- Source page: wiki/sources/ctp-topic-15-working-with-renovatebot.md -- Notes: Renovate-Bot 出现在 6 个以上来源中（index 有 416 行引用记录），满足 ≥2 次条件，创建独立 Concept 页面；Dependency-Management 和 Semantic-Versioning 作为支撑概念也一并创建；index.md 和 overview.md 均已更新；已建立与 ctp-topic-9（Gruntwork CI/CD）、ctp-topic-33（GitOps 入门）、ctp-topic-32（Atlantis CI/CD）的连接关系；Gruntwork 已有 Entity 页面（wiki/entities/Gruntwork.md），无需新建 -- Conflicts: （暂无） - -## [2026-04-24] ingest | Public Cloud Learning Sessions - Ollie Workflow and The Demand Process - 20240416 -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16.md -- Status: ✅ 成功摄入 -- Summary: Oli 工作流（超大规模云厂商支出审批三级工作流）+ 需求管理自动化端到端流程（ITIL 框架、Octane/Qixi 提交入口、主服务目录嵌入 SMACs、"机器做机器能做的事"理念） -- Concepts identified: [[Demand-Management]], [[ITIL-Service-Management]], [[FinOps]], [[SMACs]] -- Entities identified: [[Tom-Bice]], [[FPNA-Team]], [[MUI]], [[Shannon]], [[Octane]], [[Qixi]] -- Source page: wiki/sources/public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16.md -- Notes: entities 和 concepts 目录均为空（无历史页面）；未满足 ≥2 次出现条件，不新建独立页面，以 wikilink 形式记录于 Source page；index.md 已更新；overview.md Cloud Transformation 章节已补充（置于 ctp-topic-57 后）；已建立与 ctp-topic-57（Backlog 管理管道）、ctp-topic-65（价值量化）、public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109（需求分析前置技法）、ctp-topic-4（敏捷实践）的连接关系 -- Conflicts: （暂无） - -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-3-deploy-and-maintain-infrastructure.md -- Status: ✅ 成功摄入 -- Summary: Landing Zone 环境下通过 Terraform/Terragrunt 实现基础设施部署与维护的完整方法论；核心区分 Service Module（业务视角）与 Regular Module（技术视角）的分层抽象；Terragrunt HCL 版本锁定；Service Catalog 三级复用（单账户→产品团队→跨团队） -- Concepts identified: [[Service Module]], [[Service Catalog]], [[Terragrunt]], [[Infrastructure as Code]], [[Terraform Module]] -- Entities identified: [[Gruntwork]], [[AWS Landing Zone]] -- Source page: wiki/sources/ctp-topic-3-deploy-and-maintain-infrastructure.md -- Notes: 已建立与 ctp-topic-1（Gruntwork LZ 架构）、ctp-topic-9（CI/CD with Gruntwork）、ctp-topic-32（Atlantis CI/CD）、ctp-topic-33（GitOps 入门）、ctp-topic-39（EKS Atlantis 约束差异）的连接关系；Service Module/Service Catalog 仅出现 1 次，不满足 ≥2 次建页条件，以 wikilink 形式记录于 Source page；index.md 已更新；overview.md Cloud Transformation & DevOps 章节已更新 -- Conflicts: 与 [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]] 存在 Atlantis EKS 支持约束差异（Topic 3 通用原则 vs Topic 39 具体实践） - -## [2026-04-24] ingest | CTP Topic 9 CI CD with Gruntwork -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-9-ci-cd-with-gruntwork.md -- Status: ✅ 成功摄入 -- Summary: CTP Topic 9 CI/CD 与 Gruntwork 在 AWS Landing Zone 中的实践视频；源文档状态为"待 Whisper 转录"，基于文件元数据生成初始页面 -- Concepts identified: [[CI/CD Pipeline]], [[Infrastructure as Code]], [[Gruntwork]], [[Terraform]], [[Terragrunt]] -- Entities identified: [[Gruntwork]], [[AWS Landing Zone]], [[Cloud Transformation Programme]] -- Source page: wiki/sources/ctp-topic-9-ci-cd-with-gruntwork.md -- Notes: 源视频待转录，Key Claims/Key Quotes 为占位内容；已建立与 ctp-topic-1（Gruntwork LZ 架构）、ctp-topic-2（Git）、ctp-topic-33（GitOps 入门）、ctp-topic-32（Atlantis CI/CD）的连接关系；index.md 已更新；overview.md Cloud Transformation & DevOps 章节已更新；无需新建 Entity/Concept 页面 -- Conflicts: （暂无，待视频转录后补充） - -## [2026-04-14] ingest | CTP Topic 32 Using Atlantis CICD for Infrastructure Deployments -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments.md -- Status: ✅ 成功摄入 -- Summary: Atlantis 替代 Jenkins 用于 Terraform IaC 部署的 CTP 学习视频，涵盖 Atlantis 架构（单 EC2 + GitHub Webhook）、PR 评论式协作模型、跨账户 IAM 角色访问、并行构建、模块锁定机制 -- Concepts identified: [[GitOps]], [[Infrastructure-as-Code]], [[CI/CD Pipeline]], [[Terraform]] -- Source page: wiki/sources/ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments.md -- Notes: Source page 已创建；index.md 已更新（Sources 节顶部）；overview.md Cloud Transformation & DevOps 章节已更新；GitOps.md sources 列表已更新；已识别与 ctp-topic-39（EKS 不支持 Atlantis）的矛盾点并记录于 Contradictions 节 -- Conflicts: [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]]（Atlantis 不支持 EKS 部署 vs Atlantis 可替代 Jenkins 全面部署） - -## [2026-04-14] ingest | CTP Topic 2 Git -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-2-git.md -- Status: ✅ 成功摄入 -- Summary: CTP Topic 2 Git 版本控制系统基础与实践视频讲座，作为 CI/CD/GitOps 系列开篇；源文档状态为"待 Whisper 转录" -- Concepts identified: [[Git]], [[Version Control]], [[DevOps]] -- Entities identified: [[Cloud Transformation Programme]] -- Source page: wiki/sources/ctp-topic-2-git.md -- Notes: 源视频待转录，Key Claims/Key Quotes 为占位内容；已建立与 ctp-topic-9（CI/CD with Gruntwork）和 ctp-topic-33（GitOps 入门）的连接关系；index.md 已更新，overview.md Cloud Transformation & DevOps 章节已更新 - -## [2026-04-14] ingest | CTP Topic 24 Micro Focus Product Privacy Framework -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/ctp-topic-24-micro-focus-product-privacy-framework.md -- Status: ✅ 成功摄入 -- Summary: Micro Focus 产品隐私框架在云转型中的应用——PSAC 与法律顾问合作，将 GDPR/CCPA 等晦涩法律条款翻译为约 110 项低级别技术要求；隐私框架是 STLC（安全开发生命周期）中 13 个安全与隐私轨道之一；通过五类需求（架构类/文档类/法律类/实现类/SAS 运营类）和成熟度模型（0-4 级）评估产品隐私合规状态；通过"蜘蛛图"直观展示产品隐私 KPI 合规现状 -- Concepts identified: [[Product Privacy Framework（产品隐私框架）]], [[STLC（Security Development Life Cycle）]], [[PSAC（Product Security Advisory Committee）]], [[PII（Personally Identifiable Information）]], [[Maturity Model（成熟度模型）]], [[Spider Chart（蜘蛛图）]], [[Product Privacy Settings Document]], [[Data Controller vs. Data Processor]], [[Anonymization & Pseudonymization]] -- Entities identified: [[Micro Focus]], [[Shlomi Ben-Hur]] -- Source page: wiki/sources/ctp-topic-24-micro-focus-product-privacy-framework.md -- Notes: 无冲突检测；CTP Topic 21 和 Topic 24 均由 Shlomi Ben-Hur 主讲，PSAC 作为产品安全顾问委员会在多个 topic 中出现，实体创建条件待后续评估；STLC 作为 SDLC 的安全扩展已有提及，本次独立建 Concept 页面；overview.md 已更新，新增条目和 Key Concepts/Entities - -## [2026-04-24] ingest | CTP Topic 49 Container Lifecycle Hardening Standards -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/ctp-topic-49-container-lifecycle-hardening-standards.md -- Status: ✅ 成功摄入 -- Summary: Micro Focus 产品安全小组 Ashish 主讲，容器镜像构建阶段 11 条安全加固标准——基础镜像选择、Init 系统（tini 防止僵尸进程）、只读根文件系统（readOnlyRootFilesystem: true）、emptyDir Volume、禁用 Kubernetes API 自动挂载（automountServiceAccountToken: false）、私有服务账号+RBAC、避免 hostNetwork/hostPort -- Concepts created: [[Container-Lifecycle-Hardening]], [[Pod-Security-Context]], [[emptyDir-Volume]] -- Entities created: [[Ashish]], [[Product-Security-Group]], [[tini]] -- Source page: wiki/sources/ctp-topic-49-container-lifecycle-hardening-standards.md -- Notes: 与 [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]] 就 hostNetwork 配置存在场景冲突（Topic 39 Lab 环境特例 vs Topic 49 通用最佳实践）；检测到 3 个潜在概念（Container-Lifecycle-Hardening/Pod-Security-Context/emptyDir-Volume）和 3 个实体（Ashish/Product-Security-Group/tini），均已创建 Entity/Concept 页面；overview.md 已更新 - -## [2026-04-14] ingest | CTP Topic 21 Supply Chain Security in Micro Focus -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/ctp-topic-21-supply-chain-security-in-micro-focus.md -- Status: ✅ 成功摄入 -- Summary: Micro Focus 软件供应链安全新方法——供应链（产品层面）涵盖 SCM/CI/CD 全环节；驱动因素：SolarWinds 攻击事件、美国网络安全行政命令、AWS/SaaS 迁移风险；安全观念转变：从 99% 关注研发安全转向全生命周期防护；供应链安全成为 SDL 第五支柱，强调 CI 和 CD 过程完整性 -- Concepts identified: [[Supply Chain Security（供应链安全）]], [[SolarWinds Hack]], [[CI/CD Security]], [[SDL（Security Development Lifecycle）]], [[Executive Order on Cybersecurity]], [[Lateral Movement]] -- Entities identified: [[Micro Focus]], [[Shlomi Ben-Hur]] -- Source page: wiki/sources/ctp-topic-21-supply-chain-security-in-micro-focus.md -- Notes: 无冲突检测；Micro Focus 已在多处来源提及但无独立 Entity 页面，本次补充创建；SolarWinds/Shlomi Ben-Hur 仅出现一次，不满足 Entity 创建条件 - -## [2026-04-24] ingest | CTP Topic 52 3 Lines of Defence (3LoD) Framework Cloud Security Posture Management -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/ctp-topic-52-3-lines-of-defence-3lod-framework-cloud-security-posture-management.md -- Status: ✅ 成功摄入 -- Summary: 3LoD 安全治理框架落地（业务单元→集团职能部门→审计三层责任分层）+ Cloud Guard CSPM 工具选型（态势管理/资产管理/网络可视化/事件管理/威胁情报）+ 新账户创建流程中自动纳入 Cloud Guard -- Concepts identified: [[Three Lines of Defence（3LoD）]], [[Cloud Security Posture Management（CSPM）]] -- Source page: wiki/sources/ctp-topic-52-3-lines-of-defence-3lod-framework-cloud-security-posture-management.md -- Notes: 无冲突内容；3LoD/CSPM 均属行业通用概念，已有 CSPM 相关内容于 cloud-security.md；Cloud Guard 为该组织专用 CSPM 工具，暂不单独建 Entity 页面 - -## [2026-04-24] ingest | CTP Topic 55 AWS Firewall Manager -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/ctp-topic-55-aws-firewall-manager.md -- Status: ✅ 成功摄入 -- Summary: AWS Firewall Manager 在 Grand Torque 多 Landing Zone 环境中的集中化安全策略管理实践——跨 RLABS/R&D/SAS/CAT 多个 Landing Zone 统一部署基线安全组；三种策略类型（通用/审计强制/清理冗余）；通过 AWS Config + Lambda 实现自动修复；RAM 前缀列表跨账户共享规则；独立 Firewall Manager 账户支持跨 LZ 部署；Demo 展示 EC2 实例安全组的自动附加与移除 -- Concepts identified: [[Security-Group]], [[Prefix-List]], [[Auto-Remediation]], [[WAF-Rules-Management]] -- Entities identified: [[AWS-Firewall-Manager]], [[Landing-Zones]], [[QALIS]], [[Checkpoint-Firewall]] -- Source page: wiki/sources/ctp-topic-55-aws-firewall-manager.md -- Notes: 无冲突检测；与 [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] 中的 Checkpoint 方案属互补关系（网络边界防火墙 vs 实例级安全组基线），已于 Contradictions 节记录 - -## [2026-04-30] ingest | CTP Topic 37 Secrets Certificates Management -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/ctp-topic-37-secrets-certificates-management.md -- Status: ✅ 成功摄入 -- Summary: 云转型计划密钥与证书管理解决方案选型与实施——30天试点对比 AWS Secrets Manager 与 HashiCorp Vault，AWS Secrets Manager 以更低成本和更简实施胜出；实施阶段从 Control Tower 开始，从 CI/CD 流程清除明文密钥，集中化管理。 -- Concepts identified: [[Secrets-Management]], [[AWS-Secrets-Manager]] -- Entities identified: [[Micro-Focus]], [[CCLE]]（CCLE 在 2022 年 3 月负责评估工作，关键组织角色） -- Source page: wiki/sources/ctp-topic-37-secrets-certificates-management.md -- Notes: 无冲突；与 [[ctp-topic-62-aws-secrets-manager]] 的关系记录于 Contradictions 节（Topic 37 试点结论 + Topic 62 深度实践，属补充关系而非冲突） - -## [2026-04-30] ingest | CTP Topic 62 AWS Secrets Manager -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/ctp-topic-62-aws-secrets-manager.md -- Status: ✅ 成功摄入 -- Summary: AWS Secrets Manager 企业级密钥管理——Nurit & Daniel 分享。选型：HashiCorp Vault vs AWS Secrets Manager POC，AWS Secrets Manager 以更低成本和更简实施胜出。分阶段实施：集中化密钥 → 自动化获取 → 轮换。核心原则：开发者无需直接访问密钥，IAM 角色+标签控制访问。实施案例：Oracle DB 密码轮换（Lambda）、SendGrid API 密钥集中化轮换（无需应用重启）、JDBC Wrapper + AWS SDK 免密登录。 -- Concepts identified: [[Secrets-Management]], [[Secret-Rotation]], [[JDBC-Wrapper]], [[AWS-Secrets-Manager]], [[HashiCorp-Vault]]（HashiCorp Vault 作为备选方案被记录于源页面，实体重要性待定） -- Entities identified: [[Nurit]], [[Daniel]], [[Victor]]（CTP Topic 62 演讲者和演示者，作为演讲者提及一次，暂不创建独立页面） -- Source page: wiki/sources/ctp-topic-62-aws-secrets-manager.md -- Notes: 无冲突检测；相关来源 [[ctp-topic-37-secrets-certificates-management]] 和 [[ctp-topic-36-sendgrid-as-an-email-service]] 已于 Contradictions 和 Connections 节记录 - -## [2026-04-29] ingest | Public Cloud Learning Sessions - OpenText GIS Security Policies - 20241015 -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/public-cloud-learning-sessions-opentext-gis-security-policies-20241015-160257-me.md -- Status: ✅ 成功摄入 -- Summary: OpenText 全球信息安全团队（GIS）安全策略全景——Mike & Ed 主讲。GIS 分层组织架构（安全运营/合规/治理风险验证/隐私）；OpenText 分层方法定义安全策略；ISO 27001 姿态框架（2022年更新）；Global Information Security Policy（GISP）是最高纲领性政策，季度审查；每月处理 2250 亿条日志，分诊约 350 个案例；FedRAMP 等多项认证支撑多垂直市场销售。 -- Concepts identified: [[ISO-27001]], [[FedRAMP]], [[Global-Information-Security-Policy]], [[Security-Awareness-Training]], [[Third-Party-Penetration-Testing]], [[Threat-Intelligence]], [[BrightCloud]]（均以 wikilink 形式记录于 Source page，各仅出现 1 次，暂不创建独立页面） -- Entities identified: [[Mike]]（GIS Team 主讲人，仅出现 1 次，以 wikilink 形式记录于 Source page）, [[Ed]]（GIS Team 主讲人，仅出现 1 次，以 wikilink 形式记录于 Source page） -- Source page: wiki/sources/public-cloud-learning-sessions-opentext-gis-security-policies-20241015-160257-me.md -- Notes: - - 新增 1 个 Source Page（wiki/sources/public-cloud-learning-sessions-opentext-gis-security-policies-20241015-160257-me.md） - - index.md 更新：Sources 节新增条目（日期 2026-04-14，置顶于所有条目最前） - - overview.md 更新：新增 GIS Security Policies 摘要条目（置于 Thor Platform 之后，CTP Topic 28 之前）；Key Concepts 新增 ISO-27001/FedRAMP（已有条目）、BrightCloud 等 - - Connections 已建立：与 [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] 建立 related_to 关系 - - 冲突检测：与 [[ctp-topic-10]] 的互补而非冲突关系已记录于 Source Page Contradictions 节——GISP 定义全局政策纲领，Landing Zone 层面通过标签和 SCP 实现技术落地 - -## [2026-04-25] ingest | CTP Topic 64 Scaling out with Amazon EKS -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-64-scaling-out-with-amazon-eks.md -- Status: ✅ 成功摄入 -- Summary: Amazon EKS 工作负载扩缩容完整方法论——Pod 层：HPA（标准指标）+ KEDA（事件驱动）；Node 层：Cluster Autoscaler（ASG 联动）+ Karpenter（直接 EC2 API）；IP 耗尽解决方案：IPv6 双栈 VPC；集群稳定性：API Server PPF + CoreDNS 扩缩容。Suravpul 主讲。 -- Concepts identified: [[Horizontal Pod Autoscaler (HPA)]]（已在 ctp-topic-59 提及）, [[KEDA]]（新）, [[Cluster Autoscaler]]（已在 ctp-topic-70 提及）, [[Karpenter]]（已在 Part 1 提及） -- Entities identified: [[Suravpul]]（AWS 高级解决方案架构师，ctp-topic-59/64/67 三专题讲师） -- Source page: wiki/sources/ctp-topic-64-scaling-out-with-amazon-eks.md -- Notes: 与 ctp-topic-59（EKS 可靠性，HPA/VPA）和 ctp-topic-70（IaC 部署，Cluster Autoscaler）形成互补知识链路。与 Part 3 EKS Auto Mode 共享 Karpenter 知识节点。 - -## [2026-04-25] ingest | CTP Topic 67 Cloud native observability using OpenTelemetry -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-67-cloud-native-observability-using-opentelemetry.md -- Status: ✅ 成功摄入 -- Summary: AWS 解决方案架构师 Surav 分享的 EKS/ECS 云原生可观测性深度实践。涵盖可观测性三信号模型（Traces/Metrics/Logs）、OpenTelemetry Collector 架构（Receivers → Processors → Exporters）、ADOT 的多种 EKS/ECS 部署模式。核心观点：构建可观测的应用是开发者的责任；Trace 捕获调用栈各层处理耗时；Correlation ID 实现跨信号关联。 -- Concepts identified: [[OpenTelemetry]], [[Three Signals]], [[SIGV4 Auth Extension]], [[Correlation ID]] -- Source page: wiki/sources/ctp-topic-67-cloud-native-observability-using-opentelemetry.md -- Notes: 与 ctp-topic-60（Hyperscale Observability with Grafana）同属可观测性专题，与 public-cloud-learning-sessions-observability-with-opentelemetry-20240402 同属 OpenTelemetry 主题 - -## [2026-04-24] ingest | Public Cloud Learning Sessions - EKS Optimization Part 2 of 3 - Running Containers with Bottlerocket OS -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w.md -- Status: ✅ 成功摄入 -- Summary: Bottlerocket OS（火箭瓶）深度解析——AWS 专为容器工作负载优化的最小化开源 Linux 发行版。核心设计理念：最小化（去除包管理器/Shell/SSH，仅打包必要内核组件）、安全更新（分区镜像 A/B 切换确保原子性）、安全加固（dm-verity 根文件系统加密验证 + SE Linux enforcing 模式 + 根文件系统默认只读）。Variant 机制通过平台+架构+工作负载组件组合在构建时定制功能，支持 Bottlerocket for EKS AMI（自管理节点组）、托管节点组（Managed Node Groups）和 Carpenter 节点池三种集成方式。 -- Concepts identified: [[Immutable-Root-Filesystem]], [[dm-verity]], [[SE-Linux-Enforcing]], [[Partition-Updates]], [[CIS-Benchmark]] -- Entities identified: [[Bottlerocket]], [[Amazon EKS]], [[AWS]] -- Source page: wiki/sources/public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w.md -- Notes: EKS 优化三专题 Part 2（Part 1 = Karpenter 计算优化，Part 3 = EKS Auto Mode）。Bottlerocket Entity 和 5 个 Concept 均为新增。Part 3 的 EKS Auto Mode 默认使用 Bottlerocket 作为节点操作系统，形成知识链路补充。 - -## [2026-04-24] ingest | CTP Topic 42 Grafana Observability Dashboard -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-42-grafana-observability-dashboard.md -- Status: ✅ 成功摄入 -- Summary: 企业级 Grafana 可观测性平台在 AWS 多账户环境下的架构设计与 Terraform IaC 自动化实践。涵盖 Grafana 核心定位（不存储数据，仅从数据源可视化）、基础设施架构（监控账户部署 Grafana，通过 IAM 角色跨账户访问产品团队 AWS 账户）、用户和团队访问控制、示例仪表盘（CPU/I/O/Network/EBS/Estimated Charges）、告警系统（Microsoft Teams 通知）、Terraform 模块化供给（数据源模块 + 组织模块 + LZSAP 自动化接入）、Prometheus 网络监控（Checkpoint/防火墙 SNMP 指标）。 -- Concepts identified: [[Observability（可观测性）]], [[Prometheus]], [[SNMP（Simple Network Management Protocol）]], [[IAM Role（跨账户角色）]] -- Entities identified: [[AWS CloudWatch]], [[AWS Landing Zone]], [[Micro Focus Operations Bridge Manager]] -- Source page: wiki/sources/ctp-topic-42-grafana-observability-dashboard.md -- Notes: 该视频与 [[ctp-topic-60]] 均介绍 Grafana，视角互补（Grafana 本身 vs Hyperscale 场景），与 [[ctp-topic-54]] 和 [[ctp-topic-67]] 同属可观测性专题，共同构成监控知识体系。长期目标是构建应用级仪表盘替代 Micro Focus OBM。Entity 和 Concept 已有 Grafana/Prometheus/Terraform/Checkpoint 等，无需新建。 - -## [2026-04-25] ingest | CTP Topic 54 ESM SaaS Log Analytics -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-54-esm-saas-log-analytics.md -- Status: ✅ 成功摄入 -- Summary: ITOM ESM SAS 架构师 Jackie 主讲的企业级日志分析解决方案——ELK/OpenSearch 技术栈架构（BEATS/Filebeat → Logstash → Elasticsearch/OpenSearch → Kibana）、双 VPC 隔离架构、Redis 缓冲层、GDPR 合规区域分割。安全：NVMe 静态加密、TLS 1.2、VPC 私有流量、RBAC。方案对比：AWS OpenSearch（~$1,500/月，SLA 99.9%，推荐）vs Logz.io（~$4,000/月，SLA 99.8%）vs 自托管 ELK vs Microfocus OBA。 -- Concepts identified: [[ELK Stack]], [[OpenSearch]], [[Logstash]], [[Kibana]], [[BEATS]], [[Filebeat]], [[Centralized-Logging]], [[Redis缓存]], [[RBAC]], [[TLS]], [[GDPR]] -- Entities identified: [[AWS OpenSearch]], [[Jackie]] -- Source page: wiki/sources/ctp-topic-54-esm-saas-log-analytics.md -- Notes: 新建 Concept 页面 ELK-Stack.md、BEATS.md；新建 Entity 页面 AWS-OpenSearch.md；已更新 overview.md（Sources 条目 + Key Concepts）；Key Concepts 列表中已有 Centralized-Logging、Redis缓存（Redis缓存.md）、TLS，未发现冲突内容 - -## [2026-04-26] ingest | CTP Topic 59 Achieving reliability with Amazon EKS -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-59-achieving-reliability-with-amazon-eks.md -- Status: ✅ 成功摄入 -- Summary: Amazon EKS 可靠性最佳实践——Surav Paul（AWS 高级解决方案架构师）主讲。涵盖 ECS vs EKS 选型、可靠性五维度（故障检测/优雅降级/确定性故障/自愈/按需扩缩）、Shared Responsibility Model（Fargate 免除节点管理）、应用层可靠性（AZ 分散/拓扑约束/HPA/VPA/部署策略/健康探针/PodDisruptionBudget）、控制平面可靠性（指标监控/认证加固/Webhook 管理/集群升级）和数据平面可靠性（节点问题检测/资源预留/QoS/配额/Pod 优先级）。 -- Concepts identified: [[Reliability（系统可靠性）]], [[Application Reliability（应用可靠性）]], [[Control Plane Reliability（控制平面可靠性）]], [[Data Plane Reliability（数据平面可靠性）]], [[Shared Responsibility Model（EKS）]], [[Pod Anti-Affinity]], [[Topology Spread Constraints]], [[Horizontal Pod Autoscaler (HPA)]], [[Vertical Pod Autoscaler (VPA)]], [[Liveness/Readiness/Startup Probes]], [[PodDisruptionBudget]], [[Rolling/Blue-Green/Canary Deployment]]（均以 wikilink 形式记录于 Source page；均仅出现 1 次，暂无独立页面） -- Entities identified: [[Surav Paul]], [[Amazon EKS]], [[Amazon ECS]], [[AWS Fargate]]（均以 wikilink 形式记录于 Source page；仅 [[Amazon EKS]] 在多个页面中反复出现，符合独立页面创建条件，其余仅出现 1 次，暂无独立页面） -- Source page: wiki/sources/ctp-topic-59-achieving-reliability-with-amazon-eks.md -- Notes: - - 新增 1 个 Source Page（wiki/sources/ctp-topic-59-achieving-reliability-with-amazon-eks.md） - - index.md 更新：新增 CTP Topic 59 条目于 Sources 节顶部 - - overview.md 更新：新增 CTP Topic 59 条目于 Cloud Transformation & DevOps → EKS 知识链路 - - Contradictions 记录：与 ctp-topic-39（EKS Lab LZ 网络部署）存在视角差异——Topic 39 面向受限网络环境的自定义网络方案，Topic 59 提供通用 EKS 可靠性最佳实践，互为补充而非冲突 - - 无需新建 Concept/Entity 独立页面（所有概念和实体仅在本页面出现 1 次；Amazon EKS 虽在多个其他页面提及，但本页面无新增独立维度，不单独创建） - -## [2026-04-26] ingest | CTP Topic 29 Cloud Monitoring – SaaS LZ accounts -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-29-cloud-monitoring-saas-lz-accounts.md -- Status: ✅ 成功摄入 -- Summary: AWS 云监控解决方案 OpsBridge Cloud Monitoring 覆盖多账户多区域的云原生监控架构——容器化部署于 EKS，支持 20+ AWS 数据服务，数据存储于 Optic Data Lake（Vertica）；通过 IAM Role 信任关系实现只读跨账户 CloudWatch 数据采集，无需在被监控账户安装服务器或共享 Access Key；基于标签的监控是最佳实践，自动化识别缺失标签；单一 OpsBridge 实例监控多账户多区域，降低运维成本；与 OpsBridge 产品研发团队协作，报表功能在下一版本持续增强。 -- Concepts identified: [[Cloud Monitoring（AWS）]], [[Tag-Based Monitoring]], [[Vertica]], [[OpsBridge]], [[ITOM（IT Operations Management）]]（均以 wikilink 形式记录于 Source page；仅出现 1 次，暂无独立页面） -- Entities identified: [[Micro Focus OpsBridge]], [[AWS CloudWatch]], [[AWS Landing Zone]]（均以 wikilink 形式记录于 Source page；仅出现 1 次，暂无独立页面） -- Source page: wiki/sources/ctp-topic-29-cloud-monitoring-saas-lz-accounts.md -- Notes: - - 新增 1 个 Source Page（wiki/sources/ctp-topic-29-cloud-monitoring-saas-lz-accounts.md） - - index.md 更新：新增 CTP Topic 29 条目于 Sources 节顶部 - - Contradictions 记录：与 ctp-topic-8（OBM 监控）存在视角差异——Topic 8 描述基础 OBM 组件栈（三层架构），Topic 29 描述 Cloud Monitoring 新模块（容器化+EKS+20+数据服务），当前观点认为两者是同一方案的不同层面 - -## [2026-04-24] ingest | CTP Topic 60 - Monitor AWS using Hyperscale Observability with Grafana -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana.md -- Status: ✅ 成功摄入 -- Summary: 使用 Grafana Enterprise 实现 AWS 超大规模可观测性监控——Vinay 主讲（代替休假的 Sashi）。核心内容：Grafana 与多数据源集成、事件追踪、告警配置、实例监控和资源标签化；Optic DR 作为 VaticaDB 插件是导入 Grafana 仪表板的关键数据源；*Opsbridge 监控解决方案使用仪表板展示触发事件；Grafana 告警系统支持多通知渠道，可转发至 Opsbridge 创建工单；Terraform 模块自动化创建 Grafana 组织、用户、文件夹、IAM 角色和仪表板；默认指标不产生额外成本，自定义指标可能产生费用。未来路线图：SSO 认证、报表、URL 监控、进程监控、日志监控、与 PagerDuty/Slack Manager 集成。 -- Concepts identified: [[Hyperscale Observability]], [[Dashboard as Code]], [[Grafana Alert System]], [[Resource Tagging]], [[Instance Monitoring]], [[Event Tracking]]（均以 wikilink 形式记录于 Source page） -- Entities identified: [[Vinay]], [[Optic DR]], [[Opsbridge]], [[VaticaDB]], [[Grafana]], [[Terraform]]（均以 wikilink 形式记录于 Source page） -- Source page: wiki/sources/ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana.md -- Notes: - - 新增 1 个 Source Page（wiki/sources/ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana.md） - - index.md 更新：新增 CTP Topic 60 条目于 Sources 节顶部 - - Contradictions 记录：与 ctp-topic-8（OBM 监控）的互补而非冲突关系已记录 - -## [2026-04-26] ingest | CTP Topic 8 Implementation of Cloud monitoring using Micro Focus Operations Bridge Manager -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid.md -- Status: ✅ 成功摄入 -- Summary: 使用 Micro Focus Operations Bridge Manager (OBM) 实现 AWS 公有云监控的完整解决方案——OBM AWS Account 部署 OBM 应用 + Postgres RDS + Operation Agent 三层组件；Agent 通过 AWS Management Pack 利用 IAM Role 跨账户采集 CloudWatch 指标，无需在被监控账户安装服务器或共享 Access Key；Global OBM 作为 Manager of Managers 汇聚 Regional OBM 数据，事件通过 SMACKS 触发工单；新增实例自动发现与策略自动下发，解决云环境动态性监控难题；支持任意公有云（AWS/Azure/GCP）的 CloudWatch 兼容服务。 -- Concepts identified: [[Cloud-Monitoring]], [[Management-Pack]]（均已创建独立 Concept 页面） -- Entities identified: [[SMACKS]]（已有页面，更新 sources；其余实体仅出现 1 次，以 wikilink 形式记录于 Source page） -- Source page: wiki/sources/ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid.md -- Notes: - - 新增 1 个 Source Page（wiki/sources/ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid.md） - - 新增 2 个 Concept Page（wiki/concepts/Cloud-Monitoring.md, wiki/concepts/Management-Pack.md） - -## [2026-04-24] ingest | CTP Topic 39 Implementing EKS in the AWS Lab Landing Zone -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone.md -- Status: ✅ 成功摄入 -- Summary: EKS 在受限 Lab Landing Zone 网络环境下的技术实施方案——Spencer 和 Guy 分享。核心问题：Micro Focus 网络的 AWS Lab 环境 IP 地址池不足，无法满足 Octane（IP 密集型 SaaS 应用）的 EKS Pod 需求。解决方案：创建独立私有子网（非主 VPC 子网）为 EKS Pod 提供充足 IP 池；EKS 模块自定义网络标志控制 Pod IP 分配；Terraform/Terragrunt 模块封装完整 EKS 部署逻辑，支持跨账户角色映射；Pod 规范设置 `hostNetwork: true` 使其同时访问内部 Micro Focus 网络和外部资源。Atlantis 当前不支持 EKS 部署，需通过 Jenkins + Terragrunt 模块替代。 -- Concepts identified: [[Amazon EKS]], [[Kubernetes Custom Networking]], [[Terraform-Terragrunt Module]], [[IAM Role Mapping (EKS)]], [[Host Network Mode (Pod)]], [[Container Hardening]]（均以 wikilink 形式记录于 Source page；均仅出现 1 次，暂无独立页面） -- Entities identified: [[Octane-Hub]]（已有页面，更新 sources）、[[Terragrunt]], [[Atlantis]]（工具名，均仅出现 1 次，以 wikilink 形式记录于 Source page） -- Source page: wiki/sources/ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone.md -- Notes: - - 新增 1 个 Source Page（wiki/sources/ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone.md） - - index.md 更新：新增 CTP Topic 39 条目于 Sources 节顶部 - - overview.md 更新：新增 CTP Topic 39 条目于 EKS 知识链路 - - 无需新建 Concept/Entity 独立页面（所有概念和实体仅出现 1 次） - -## [2026-04-26] ingest | Public Cloud Learning Sessions EKS Optimization Part 3 of 3 Introduction to EKS Auto Mode -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks-.md -- Status: ✅ 成功摄入 -- Summary: EKS Auto Mode 将 Kubernetes 数据平面管理责任从用户扩展至 AWS。Carpenter Controller 负责节点生命周期和滚动升级；Bottlerocket OS 提供最小化安全容器操作系统，自动应用安全补丁；AWS Load Balancer Controller（eks.aws/alb）管理 ingress；EBS CSI Controller 支持有状态工作负载；Pod Identity Associations 替代 K8s RBAC 实现 Pod 级 IAM 权限控制；Prefix Delegation 默认启用优化 Pod 网络 IP 分配。默认两个节点池（General Purpose AMD64 + System taint），支持自定义 Graviton 节点池。每个 Auto Mode 实例附加 12% 管理溢价。 -- Concepts created: [[EKS Auto Mode]]（已创建独立 Concept 页面） -- Source page: wiki/sources/public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks.md -- Notes: - - 新增 1 个 Source Page（wiki/sources/public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks.md） - - 新增 1 个 Concept Page（wiki/concepts/EKS-Auto-Mode.md） - - Entities：AWS 和 Amazon EKS 已在 overview.md 中存在，无需新建 Entity 页面 - -## [2026-04-24] ingest | Image Prompt Engineer Agent -- Source file: Agent/agency-agents/design/design-image-prompt-engineer.md -- Status: ✅ 成功摄入 -- Summary: Image Prompt Engineer Agent 角色定义——AI 图像生成提示词工程专家智能体，专注于将视觉概念精准翻译为可执行的提示词语言，驱动 Midjourney/DALL-E/Stable Diffusion/Flux 等 AI 图像生成工具产出专业级摄影作品。核心方法：五层提示词结构框架（主体描述层 → 环境设定层 → 光线规范层 → 摄影技术层 → 风格美学层）+ 平台特定语法优化 + 体裁专属提示模式（人像/产品/风光/时尚摄影）。核心原则：摄影术语精确性 + 负向提示词 + 宽高比构图。成功指标：视觉概念还原率 90%+。与 [[design-ui-designer]]（像素级精确）存在张力，已记录于 Contradictions；与 [[design-brand-guardian]]（品牌一致性）、[[design-whimsy-injector]]（品牌趣味）协同，构成 [[The Agency]] 设计部门完整设计支撑体系。 -- Concepts linked: [[Prompt-Engineering]], [[Five-Layer-Prompt-Structure]], [[Platform-Specific-Prompt-Optimization]], [[Negative-Prompts]], [[Film-Emulation]], [[Lighting-Patterns]] -- Entities linked: [[Midjourney]], [[DALL-E]], [[Stable-Diffusion]], [[Flux]], [[Annie Leibovitz]], [[Peter Lindbergh]], [[The Agency]] -- Source page: wiki/sources/design-image-prompt-engineer.md -- Notes: index.md 已替换占位符条目；overview.md 已新增独立段落（置于 design-whimsy-injector 之后，design-brand-guardian 之前）；无新 Entity/Concept 需创建（Midjourney/DALL-E/Stable-Diffusion/Flux/Prompt-Engineering 等仅出现 1 次，不足建页阈值）；与 [[design-ui-designer]] 在概率生成 vs 像素精确的张力已记录于 Contradictions 节——通过确定性约束（具体颜色值/光照参数）协调 -- Conflicts: 与 [[design-ui-designer]] 在视觉还原精度上的差异——Image Prompt Engineer 目标 90%+ 概念还原（概率生成固有不确定性），UI Designer 要求 95%+ 实现准确率（设计到代码的翻译环节）；已建立协调方案 - -## [2026-04-24] ingest | CTP Topic 11 AD Integration and Login using AD Accounts -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/02_IAM/ctp-topic-11-ad-integration-and-login-using-ad-accounts.md -- Status: ✅ 成功摄入 -- Summary: Jenkins 与 SW Infra AD 安全域集成，实现基于 AD 账号的统一身份认证与自动化用户管理（入离职无需手动维护本地用户）；通过 AD 组策略实现 RBAC 精细化权限控制（只读/读写/流水线创建）；pre-commit 框架集成 terraform fmt/TFLint/Checkov 三款工具在代码提交阶段嵌入自动化安全检查；CI/CD 流水线分层治理模式（Commit 检查 → PR 检查+plan → Master 人工审核后 apply），核心理念为"左移"（Shift-Left）将安全问题提前到开发早期。 -- Concepts identified: [[Active Directory Integration]], [[RBAC (Role-Based Access Control)]], [[Pre-commit Framework]], [[Terraform Fmt]], [[TFLint]], [[Checkov]], [[Shift-Left Security]], [[CI/CD Pipeline Governance]]（均以 wikilink 形式记录于 Source page；各仅出现 1-2 次，未达 ≥2 次阈值，暂不创建独立页面） -- Entities identified: [[Niranjan]]（仅出现 1 次，未达 ≥2 次阈值，以 wikilink 形式记录于 Source page） -- Source page: wiki/sources/ctp-topic-11-ad-integration-and-login-using-ad-accounts.md -- Notes: - - 新增 1 个 Source Page（wiki/sources/ctp-topic-11-ad-integration-and-login-using-ad-accounts.md） - - index.md 更新：新增 CTP Topic 11 条目于 Sources 节顶部 - - overview.md 更新：新增 CTP Topic 11 详细条目于身份治理知识体系段落 - - Contradictions 记录：与 Atlantis（ctp-topic-32）关于 terraform apply 审批权的差异已记录 - -## [2026-04-24] ingest | CTP Topic 5 - AWS Identity and Access Management (IAM) -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/02_IAM/ctp-topic-5-aws-identity-and-access-management-iam.md -- Status: ✅ 成功摄入 -- Summary: AWS IAM 核心组件与联邦访问机制——IAM Dashboard 四大资源（用户、组、客户托管策略、角色、身份提供商）；联邦用户通过 Active Directory 组映射到 IAM 角色；accounts.json 位于 Landing Zone 根目录；IAM 用户主要用于服务账号，人工用户优先使用联邦访问；角色本身不启用操作，而是将"谁可以做什么"与"可以做什么"关联；策略分为 AWS 托管和客户托管，Terraform 模块可定义 IAM 角色；PFSSO 工具实现 CLI 联邦访问；最小权限原则贯穿始终。 -- Concepts identified: [[IAM（身份和访问管理）]], [[Federation（联邦身份）]], [[Least Privilege（最小权限）]], [[IAM Role（IAM 角色）]], [[IAM Policy（IAM 策略）]], [[Managed Policy vs Inline Policy]], [[Cross-Account Role Assumption]], [[PFSSO]]（均以 wikilink 形式记录于 Source page；各仅出现 1 次，未达 ≥2 次阈值，暂不创建独立页面） -- Entities identified: [[accounts.json]], [[VSM]]（均以 wikilink 形式记录于 Source page；各仅出现 1 次，未达 ≥2 次阈值） -- Source page: wiki/sources/ctp-topic-5-aws-identity-and-access-management-iam.md -- Notes: - - 新增 1 个 Source Page（wiki/sources/ctp-topic-5-aws-identity-and-access-management-iam.md） - - index.md 更新：替换原有缺失条目为完整条目（日期 2026-04-24） - - overview.md 更新：新增 CTP Topic 5 条目于身份治理知识体系段落 - -## [2026-04-24] ingest | Public Cloud Learning Sessions - AWS End User Compute Services - 20240430 -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee.md -- Status: ✅ 成功摄入 -- Summary: AWS EUC 服务全景介绍——覆盖 Workspaces（全持久虚拟桌面）、AppStream 2.0（选择持久/非持久应用流，多租户降本）、Workspace Core（第三方 VDI 集成）、Workspace Web（低成本安全浏览器）四大服务。选型原则：知识工作者完整桌面 → Workspaces；实验室/培训/非持久 → AppStream 2.0；第三方 VDI → Workspace Core；安全浏览 → Workspace Web。安全措施包括 AD 集成、加密、IAM 配置文件、SAML 认证、多因素认证。 -- Concepts identified: [[Amazon-Workspaces]], [[AppStream-2.0]], [[AWS-End-User-Computing]], [[Virtual-Desktop-Infrastructure]], [[WSP-Protocol]], [[BYOD]], [[VDI]], [[SAML-Authentication]], [[VPC-Interface-Endpoints]]（均以 wikilink 形式记录于 Source page；各仅出现 1-2 次，未达 ≥2 次阈值，暂不创建独立页面） -- Entities identified: [[Christian-O'Donough]]（仅出现 1 次，未达 ≥2 次阈值，以 wikilink 形式记录于 Source page） -- Source page: wiki/sources/public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee.md -- Notes: - - 新增 1 个 Source Page（wiki/sources/public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee.md） - - index.md 更新：在 Sources 节顶部新增条目（日期 2026-04-24） - - overview.md 更新：在 ctp-topic-6-aws-workspaces-demo 之后新增摘要段落；与 [[ctp-topic-6-aws-workspaces-demo]] 建立关联关系 - - Connections 已建立：与 [[ctp-topic-6-aws-workspaces-demo]]（实操演示）、[[AWS-Landing-Zone]]（VPC 架构）建立 depends_on 关系 - - 冲突检测：无已知冲突内容 - -## [2026-04-30] ingest | Public Cloud Learning Sessions - Applicable Business Analysis Techniques - 20240109 -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109-.md -- Status: ✅ 成功摄入 -- Summary: 业务分析（Business Analysis）基础技能与三大核心技法——T型技能模型（连接业务与技术）、BOSCARD框架（复杂新工作定义）、干系人轮盘（Stakeholder Wheel）、结合元数据的用户故事需求收集。INVEST原则检查需求质量，SAFe框架补充Features/Capabilities/NFR。核心理念：业务分析将业务需求与技术变更解决方案对齐，帮助定义企业架构中哪些变更是有益的。 -- Concepts identified: [[Business-Analysis]], [[T-Shaped-Skills]], [[BOSCARD]], [[Stakeholder-Wheel]], [[Requirements-Gathering]], [[INVEST]], [[SAFe]], [[RACI]]（均以 wikilink 形式记录于 Source page；各仅出现 1 次，未达 ≥2 次阈值，暂不创建独立页面） -- Entities identified: [[BCS]], [[IIBA]], [[OpenText]]（均仅出现 1 次，未达 ≥2 次阈值，以 wikilink 形式记录于 Source page） -- Source page: wiki/sources/public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109.md -- Notes: - - 新增 1 个 Source Page（wiki/sources/public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109.md） - - index.md 更新：替换预期占位符为正式条目（日期修正为 2024-01-09，添加摘要） - - overview.md 更新：在 Cloud Transformation & DevOps 部分新增摘要段落（置于 ctp-topic-4 之后）；Key Concepts 新增 Business-Analysis、T-Shaped-Skills、BOSCARD、Stakeholder-Wheel、Requirements-Gathering、INVEST、SAFe - - Connections 已建立：与 ctp-topic-4（敏捷实践）、ctp-topic-57（需求管理）、ctp-topic-20（需求流程）、ctp-topic-41（NFR）建立 related_to 关系 - - 冲突检测：与 [[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]] 互补而非冲突——Topic 4 提供敏捷持续流动实践框架，本视频提供需求定义前置技法，构成云转型计划完整方法论（规划→需求→执行） - -## [2026-04-14] ingest | CTP Topic 23 Introduction to the Technical Architecture Team and Function -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-23-introduction-to-the-technical-architecture-team-and-function.md -- Status: ✅ 成功摄入 -- Summary: Martin Nash（技术架构经理）介绍技术架构团队的核心职能、组织架构及在云转型中的价值。核心主题：从被动响应转向主动规划。团队推行"云优先"策略，维护 AWS Enterprise Landing Zones。三层架构分工：EA（企业架构）对接业务战略，SA（方案架构）负责中间件与服务优化，TA（技术架构）专注底层技术实施与基础设施治理。通过划分"技术领域"并由首席架构师负责，制定 12-24 个月前瞻性路线图。 -- Concepts created: [[Enterprise-Architecture]], [[Solution-Architecture]], [[Technical-Architecture]]（均已创建独立页面） -- Entities created: [[Martin-Nash]]（Technical Architecture Manager，已创建独立页面） -- Source page: wiki/sources/ctp-topic-23-introduction-to-the-technical-architecture-team-and-function.md -- Notes: - - 新增 1 个 Source Page - - index.md 更新：替换预期占位符为正式条目（日期修正为 2026-04-14，添加摘要） - - overview.md 更新：在 CTP Topics 部分添加 Topic 23 摘要条目（位于 Topic 47 和 Topic 72 之间） - - 新增 3 个 Concept 页面：Enterprise-Architecture.md, Solution-Architecture.md, Technical-Architecture.md - - 新增 1 个 Entity 页面：Martin-Nash.md - - Key Concepts 新增：[[Cloud-First Strategy]], [[AWS Enterprise Landing Zones]], [[Technical Domains]], [[Enterprise Architecture (EA)]], [[Solution Architecture (SA)]], [[Technical Architecture (TA)]], [[Roadmaps]], [[ITIL Alignment]] - - 无冲突内容 - -## [2026-04-25] ingest | CTP Topic 57 Product backlog managing demand -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-57-product-backlog-managing-demand.md -- Status: ✅ 成功摄入 -- Summary: CTP 产品待办列表（Backlog）需求管理完整管道——SMACs提交→双周评审（20题问卷）→Octane特性化→Sprint规划（50%新需求/50%支持+技术债）→Prerequisite Phase→SRE构建账号→2周Hyper Care。核心理念：透明化需求管道，确保所有工作以同一标准评估。 -- Concepts identified: [[Product-Backlog]], [[Demand-Management]], [[SMACs]], [[Prerequisite-Phase]], [[Hyper-Care]], [[Sprint-Planning]], [[Octane]]（均以 wikilink 形式记录于 Source page） -- Entities identified: [[Matthew Chapman]], [[David Grant]], [[Brendan Starnig]], [[ADM]], [[ITOM]], [[PCG]], [[SRE]]（均以 wikilink 形式记录于 Source page；Matthew Chapman/David Grant 仅出现1-2次，未达 ≥2 阈值，暂不创建独立 Entity 页面） -- Source page: wiki/sources/ctp-topic-57-product-backlog-managing-demand.md -- Notes: - - 新增 1 个 Source Page（wiki/sources/ctp-topic-57-product-backlog-managing-demand.md） - - index.md 更新：替换预期占位符为正式条目（日期修正为 2026-04-14，添加摘要） - - overview.md 更新：在 CTP Topics 部分添加 Topic 57 摘要条目（位于 Topic 41 和 Topic 65 之间）；Key concepts 新增 [[Product-Backlog]], [[Demand-Management]], [[SMACs]], [[Prerequisite-Phase]], [[Hyper-Care]], [[Octane]] - - Connections 已建立：与 CTP Topic 20（需求流程）、CTP Topic 4（敏捷实践）、CTP Topic 30（变更管理）建立 related_to 关系 - - 无冲突内容 - -## [2026-04-25] ingest | Public Cloud Learning Sessions (OpenText) - Thor Platform & Flows -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet.md -- Status: ✅ 成功摄入 -- Summary: Arnold Dacan 详解 Project Thor 平台架构与数据流——五大支柱框架（敏捷周期治理、产品发布治理、开发者门户 Backstage、安全治理、Build Hub）；核心数据流：源代码（GitLab）→ 制造流程（Build Farms）→ Artifactory → 客户环境；地理分布：主站点 Brook Park + 灾备站点 Sacramento；标准化目标：统一 GitLab/Artifactory/UCMDB 工具链，夯实供应链安全基础。 -- Concepts identified: Project Thor, Supply Chain Security, Build Hub, GitLab Proxy, GitLab Geo, Code Signing（均以 wikilink 形式记录于 Source page，暂不创建独立 Concept 页面） -- Entities identified: Arnold Dacan（仅出现1次，未达 ≥2 阈值，以 wikilink 形式记录于 Source page）；GitLab/Artifactory/Backstage/UCMDB（通用工具名称，不创建独立 Entity 页面） -- Source page: wiki/sources/public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet.md -- Notes: - - 新增 1 个 Source Page（wiki/sources/public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet.md） - - index.md 更新：替换预期占位符为正式条目（添加摘要） - - overview.md 更新：在 GitHub→GitLab 迁移条目后新增 Thor Platform & Flows 摘要条目 - - Connections 已建立：与 GitHub→GitLab 迁移文档建立 extends 关系；与 CTP Topic 21 建立 related_to 关系 - - 无冲突内容 - -## [2026-04-25] ingest | CTP Topic 6 AWS Workspaces Demo -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-6-aws-workspaces-demo.md -- Status: ✅ 成功摄入 -- Summary: AWS Workspaces 虚拟桌面演示——Windows Server 2016 托管桌面，预装 PFSSO/Terraform/TerraGrunt/Git/VS Code；21分钟完成 TerraGrunt Plan；通过 Federation 访问 AWS Console，GitHub Enterprise 登录（已过期，应为 GitLab） -- Concepts identified: [[AWS Workspaces]], [[Terraform]], [[TerraGrunt]], [[PFSSO]], [[AWS Federation]]（均已存在于 Wiki 或通过 Source page 内 wikilink 引用，暂不创建独立页面） -- Entities identified: [[Naga]]（仅出现1次，未达 ≥2 阈值，以 wikilink 形式记录于 Source page） -- Source page: wiki/sources/ctp-topic-6-aws-workspaces-demo.md -- Notes: - - 新增 1 个 Source Page（wiki/sources/ctp-topic-6-aws-workspaces-demo.md） - - index.md 更新：替换预期占位符为正式条目（日期修正为 2026-04-14，添加摘要） - - overview.md 更新：在 Cloud Transformation & DevOps 部分新增 Topic 6 摘要条目 - - Contradiction 已记录：与 GitHub→GitLab 迁移文档冲突（视频录制时仍使用 GitHub Enterprise，当前已被 GitLab 替代） - -## [2026-04-25] ingest | CTP Topic 53 Why bother with Cloud -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-53-why-bother-with-cloud.md -- Status: ✅ 成功摄入 -- Summary: Micro Focus 云转型计划商业价值论证——14个数据中心近20,000台资产，年营收25亿美元但VMware利用率不足40%；三个产品从Bublikan迁出后下线575台物理服务器，云端仅需240台虚拟服务器；Redding退出时40%应用直接关机；当前55% AWS成本发生在LZ之外。云迁移不仅是成本节约，更是创新催化剂。 -- Concepts identified: Cloud Transformation Programme, Landing Zone (Labs/SAS/Corporate), AWS Account Tagging Framework, Enterprise Platform, Multi-Cloud Strategy（均已在 overview.md 中以 wikilink 关联，暂不创建独立 Concept 页面） -- Entities identified: Micro Focus, ELT, Bublikan, Redding, Houston, Dart, CCOE, SRE（均已在 overview.md 中以 wikilink 关联，暂不创建独立 Entity 页面） -- Source page: wiki/sources/ctp-topic-53-why-bother-with-cloud.md -- Notes: - - 新增 1 个 Source Page（wiki/sources/ctp-topic-53-why-bother-with-cloud.md） - - index.md 更新：替换预期占位符为正式条目（日期修正为 2026-04-14，添加摘要） - - overview.md 更新：在 Cloud Transformation & DevOps 部分添加 Topic 53 摘要条目 - - Contradiction 已记录：与 ctp-topic-43-vmware-cloud-on-aws 的观点张力（完全迁移 vs 混合云中间路线） - -## [2026-04-24] ingest | Public Cloud Learning Sessions (OpenText) - GitHub Enterprise to GitLab Migration -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20.md -- Status: ✅ 成功摄入 -- Summary: OpenText 将源代码管理平台从 GitHub Enterprise 迁移至 GitLab——Project Thor 整合工具链，GitLab 作为源代码控制黄金标准；GitHub 许可证12月底到期不续；各团队自服务模式规划迁移；两种迁移方案（镜像同步 / 搬移重构）；PHT 跟踪进度；网络挑战通过 Brook Park GitLab 代理解决。 -- Concepts identified: Project Thor（企业工具链整合）, Build Hub（中心工具支持团队）, Self-Serve Migration（自服务迁移模式）, Mirroring（镜像同步迁移）, Shift and Lift（搬移重构迁移）, Service Account Standard（服务账号标准） -- Entities identified: OpenText, GitHub Enterprise, GitLab, Build Hub, PHT（均未达 ≥2 次阈值，暂不创建独立页面，以 wikilink 关联） -- Source page: wiki/sources/public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20.md -- Notes: - - 新增 1 个 Source Page（wiki/sources/public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20.md） - - index.md 更新：替换预期占位符为正式条目（日期修正为 2026-04-24） - - overview.md 更新：新增摘要段落（置于 tagging-standard-v2 之后，ctp-topic-28 之前） - - 冲突检测：未发现与其他 Wiki 页面的矛盾冲突 - -## [2026-04-29] ingest | Public Cloud Learning Sessions - OpenText Tagging Standard v2 -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-opentext-tagging-standard-v2-20250429-170111-meet.md -- Status: ✅ 成功摄入 -- Summary: OpenText 云资源标签标准 v2，Martin Rosler 主讲——三大驱动力（成本优化/风险降低/自动化效率）；覆盖云账户、云资源、Kubernetes 对象和容器镜像；标准化前缀（OT\_/app.opentext.com/com.opentext.image）确保跨平台语义无歧义；最佳实践：IaC 自动化、禁止标签存敏感数据。 -- Concepts identified: Cloud-Cost-Optimization（成本优化）, Tag-Standardization（标签标准化）, Kubernetes-Labeling（Kubernetes 标签）, Container-Image-Tagging（容器镜像标签）, IaC-Tagging-Automation（IaC 标签自动化） -- Entities identified: Martin-Rosler（讲师，出现 1 次，未达 ≥2 次阈值，以 wikilink 关联）, Phenops-Team（发起团队，出现 1 次，未达 ≥2 次阈值，以 wikilink 关联） -- Source page: wiki/sources/public-cloud-learning-sessions-opentext-tagging-standard-v2-20250429-170111-meet.md -- Notes: - - 新增 1 个 Source Page（替换 index.md 占位符条目，日期修正为 2026-04-14） - - overview.md 新增摘要段落（置于 ctp-topic-17 之后，ctp-topic-28 之前）；Key Entities 新增 Martin Rosler 和 Phenops-Team - - 冲突检测：与 [[ctp-topic-28-aws-tag-validation-tool]] 无矛盾——标签标准定义「应该怎么标」，验证工具发现「谁没标好」，两者互补 - - Terraform/Kubernetes/Container-Images 已在 Key Concepts 中存在，以 wikilink 关联 - - -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-41-nfrs-and-error-budgets.md -- Status: ✅ 成功摄入 -- Summary: NFR（非功能需求）与 Error Budget（错误预算）在云转型和敏捷开发中的实践——Brendan Standing（Head of SRE）主讲。核心：NFR Epic 模板将 NFR 集成到 Sprint Backlog；AWS 共享责任模型；Error Budget = 1 - SLO，量化系统可容忍的不可靠程度；SLR/SLO/SLA 三层体系；混沌工程主动注入故障验证韧性。核心理念：Error Budget 将失败归一化为开发流程的一部分，弥合开发与运维的文化鸿沟。 -- Concepts identified: NFR（非功能需求）, Error Budget（错误预算）, Chaos Engineering -- Entities identified: Brendan-Standing, AWS, Micro Focus（各仅出现 1-2 次，未达 ≥2 次阈值，暂不创建独立页面） -- Source page: wiki/sources/ctp-topic-41-nfrs-and-error-budgets.md -- Notes: - - 新增 1 个 Source Page（wiki/sources/ctp-topic-41-nfrs-and-error-budgets.md） - - NFR/Error Budget/Chaos Engineering 以 wikilink 形式建立关联，暂不创建独立页面（各仅出现 1 次，未达 ≥2 次阈值） - - Brendan-Standing 以 wikilink 形式建立关联，暂不创建独立页面（仅出现 1 次，未达 ≥2 次阈值） - - index.md 更新：替换预期占位符为正式条目（日期修正为 2026-04-14） - - overview.md 更新：新增 CTP Topic 41 摘要段落（置于 ctp-topic-30 之后，ctp-topic-65 之前）；Key Concepts 新增 NFR（非功能需求）、Error Budget（错误预算）、Chaos Engineering - - 冲突检测：与 [[ctp-topic-30-managing-change]] 在 SRE 职责范围上存在视角差异——Topic 30 强调变更管理，Topic 41 强调可靠性工程，两者互补而非矛盾，已记录于 Source Page Contradictions 节 - -## [2026-04-28] ingest | CTP Topic 10 AWS Landing Zone (LZ) Data Collection, Tagging Related Security -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md -- Status: ✅ 成功摄入 -- Summary: AWS Landing Zone 部署数据收集策略与基于标签的云原生安全架构——Steve Jarman 和 Pradeep 主讲。核心：OU+SCP 分层治理、标签即凭证（替代 IP 规则）、Checkpoint 有序层防火墙（地理→类型→BU→产品→环境→角色）、Inline 层账号号父子规则。标签缺失/篡改触发 SCP 拒绝策略，确保合规。 -- Concepts identified: Service-Control-Policies-SCPs, Checkpoint-Firewall, AWS-Landing-Zone, Tag-Based-Security, OU-Layered-Security -- Entities identified: Steve-Jarman, Pradeep, Checkpoint, AWS-Organizations -- Source page: wiki/sources/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md -- Notes: - - 新增 1 个 Source Page（替换 2 个占位符条目） - - 5 个 Concepts 以 wikilink 形式建立关联，暂不创建独立页面（Service-Control-Policies-SCPs/Checkpoint 已存在于 entities/；其余各仅出现 1-2 次，未达 ≥2 次阈值） - - 4 个 Entities 以 wikilink 形式建立关联，暂不创建独立页面（Checkpoint 已存在于 entities/；Steve-Jarman/Pradeep/AWS-Organizations 各仅出现 1-2 次，未达 ≥2 次阈值） - - index.md 更新：修正日期为 2026-04-14，移除重复占位符条目（line 416） - - overview.md 更新：修正 CTP Topic 10 段落的 wikilink 指向新 source page；Key Concepts 新增 3 个概念（Service-Control-Policies-SCPs/OU-Layered-Security/Tag-Based-Security） - - 冲突检测：与 [[ctp-topic-28-aws-tag-validation-tool]] 在 SCP 标签强制能力边界上存在视角差异——Topic 10 认为 SCP 可「阻止不合规资源创建」，Topic 28 认为「无法修复存量资源」。两者互补：SCP 负责预防（准入控制），Tag Validation Tool 负责发现（存量审计） - -## [2026-04-27] ingest | CTP Topic 20 Program demand process flow and PoC onboarding -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-20-program-demand-process-flow-and-poc-onboarding.md -- Status: ✅ 成功摄入 -- Summary: 云转型计划的程序需求流程与 POC 入职流程——Sergio 和 Damian 主讲。核心内容：需求来源（业务案例/战略优先级/产品路线图）、Gate Process 三阶段审批（Gate 0/1/3）、POC 目的（验证架构可行性+熟悉 Gruntwork Landing Zone）、新环境强调 IaC（Terraform/Terragrunt）自动化、PCG 团队职责、成功标准前置定义。 -- Concepts identified: Program-Demand-Process, Proof-of-Concept, Gate-Process, Solution-Design -- Entities identified: Sergio, Damian, PCG-Team, Gruntwork, Terraform, Terragrunt -- Source page: wiki/sources/ctp-topic-20-program-demand-process-flow-and-poc-onboarding.md -- Notes: - - 新增 1 个 Source Page - - 4 个 Concepts 以 wikilink 形式建立关联，暂不创建独立页面（各仅出现 1 次，未达 ≥2 次阈值） - - 6 个 Entities 以 wikilink 形式建立关联，暂不创建独立页面（Sergio/Damian/PCG-Team 各仅出现 1 次；Gruntwork/Terraform/Terragrunt 已存在于 wiki/） - - index.md 更新：替换预期占位符为正式条目（日期修正为 2026-04-14） - - overview.md 更新：新增 CTP Topic 20 摘要段落（置于 ctp-topic-65 之后，ctp-topic-47 之前）；Key Concepts 列表新增 4 个概念（Program-Demand-Process/Proof-of-Concept/Gate-Process/Solution-Design） - - 冲突检测：与 [[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]] 存在流程视角差异——Topic 4 强调 Kanban 持续流动允许随时调整优先级，Topic 20 强调 Gate Process 阶段性审批节点。两者非逻辑矛盾，而是适用场景不同（敏捷迭代 vs 迁移治理），已记录于 Source Page Contradictions 节 - -## [2026-04-24] ingest | CTP Topic 4 Using Agile to Run the Cloud Transformation Programme -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-4-using-agile-to-run-the-cloud-transformation-program.md -- Status: ✅ 成功摄入 -- Summary: 云转型计划中敏捷实践落地经验——从 Scrum（两周 Sprint）因"Sprint 期间不允许变更"转向 Kanban 持续流动，采用混合框架（Kanban 为主 + 保留 Scrum 仪式）。Microsoft Planner 看板五列布局，最佳实践：单一负责人、依赖链接、优先级和截止日期。核心价值观：快速反馈驱动产品和开发文化持续改进。 -- Entities created: Heather-Norris, Microsoft-Planner -- Concepts created: Scrum, Kanban, Agile-Ceremonies, Continuous-Delivery -- Source page: wiki/sources/ctp-topic-4-using-agile-to-run-the-cloud-transformation-program.md -- Notes: 与 CTP Topic 30 (变更管理) 和 Topic 57 (需求管理) 共同构成项目管理知识体系 - -## [2026-04-26] ingest | CTP Topic 65 Tracing the Value Delivered in Cloud Transformation -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation.md -- Status: ✅ 成功摄入 -- Summary: 云转型价值交付量化框架——涵盖 Process/Value/Value-Stream 基础概念、Lean 三类活动识别、收益四维度量化（财务/生产力/质量/体验）、WSJF 优先级排序（Cost of Delay / Size of Job）、功能级价值拆解方法。核心理念："以最小投入尽早交付最大价值"。 -- Concepts identified: Process, Value, Value-Stream, Value-Adding, Waste, Benefits-Quantification, Cost-of-Delay, WSJF, SOM, Feature-Level-Value-Breakdown -- Entities identified: CTP（Cloud Transformation Programme），Scaled-Agile（WSJF 来源框架） -- Source page: wiki/sources/ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation.md - - - 新增 1 个 Source Page（wiki/sources/ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation.md） - - 所有 Concepts 和 Entities 均以 wikilink 形式建立关联，暂不创建独立页面（各仅出现 1 次，未达 ≥2 次阈值） - - index.md 更新：替换预期占位符为正式条目（日期修正为 2026-04-14） - - overview.md 更新：新增 CTP Topic 65 摘要段落（置于 ctp-topic-30 之后，ctp-topic-47 之前）；Key Concepts 列表新增 10 个概念 - - 冲突检测：与 [[ctp-topic-53-why-bother-with-cloud]] 存在视角张力——Topic 53 质疑迁移必要性，Topic 65 假设迁移已决策并聚焦如何量化交付价值。两者互补而非逻辑矛盾——前者回答"是否迁移"，后者回答"如何衡量价值"。已记录于 Source Page Contradictions 节。 - - -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-30-managing-change.md -- Status: ✅ 成功摄入 -- Summary: 云转型中的变更管理与 SRE 团队协作——Brendan Starnig（SRE Function Lead）主讲。核心内容：①SRE 职责——用软件工程思维解决运维问题，追求可靠性、可测试性、可重复性；②变更分类——Standard Change（预批准，完全自动化）→ Normal Change（需 CAB 审批）→ Emergency Change（立即执行，事后 CAPA）；③SRE 三阶段协作——Build/Early Live Support/BAU；④Self-Healing 演进方向。 -- Concepts created: Standard-Change, Normal-Change, Emergency-Change, CAPA, Early-Live-Support -- Entities created: Brendan-Starnig, SMACs -- Source page: wiki/sources/ctp-topic-30-managing-change.md -- Notes: - - 新增 1 个 Source Page（wiki/sources/ctp-topic-30-managing-change.md） - - 新增 2 个 Entity 页面（Brendan-Starnig.md, SMACs.md） - - 新增 5 个 Concept 页面（Standard-Change.md, Normal-Change.md, Emergency-Change.md, CAPA.md, Early-Live-Support.md） - - 更新现有 Entity：SRE-Team.md（添加三阶段支持职责和 Topic 30 来源） - - index.md 更新：替换预期占位符为正式条目（日期修正为 2026-04-14） - - overview.md 更新：新增 CTP Topic 30 摘要段落 - - 冲突检测：与 [[ctp-topic-53-why-bother-with-cloud]] 的观点张力——Topic 30 假设迁移决策已做出，聚焦执行层面变更管理；Topic 53 质疑迁移必要性。已记录于 Source Page Contradictions 节。 - -## [2026-04-25] ingest | CTP Topic 69 Best Practices for Migrating On-Premises (IOD) Virtual Machines to VMware Cloud on AWS -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-69-best-practices-for-migrating-on-premises-iod-virtual-machines-to-vm.md -- Status: ✅ 成功摄入 -- Summary: VMC on AWS 虚拟机迁移最佳实践——HCX 多云管理（每次迭代最多 200 台 VM）、UI 和 CCOE 脚本两种迁移方案、Direct Connect + Virtual Transit Gateway 混合云连接、预/后迁移自动化、Brown to Manage 系统集成 SMACS + HCMX 实现后迁移管理。 -- Concepts created: Direct Connect, Virtual Transit Gateway, BGP, EC2-Bare-Metal, CCOE, SMACS Suite, HCMX -- Source page: wiki/sources/ctp-topic-69-best-practices-for-migrating-on-premises-iod-virtual-machines-to-vm.md -- Notes: - - 新增 1 个 Source Page（wiki/sources/ctp-topic-69-best-practices-for-migrating-on-premises-iod-virtual-machines-to-vm.md） - - 所有 Concepts 和 Entities 均以 wikilink 形式建立关联，暂不创建独立页面（各仅出现 1 次，未达 ≥2 次阈值） - - index.md 更新：替换预期占位符为正式条目（日期修正为 2026-04-14） - - overview.md 更新：新增 CTP Topic 69 摘要段落（置于 ctp-topic-43 之后），补充 HCX 和迁移执行层面的详细信息 - - 冲突检测：与 [[ctp-topic-43-vmware-cloud-on-aws]] 互补而非冲突——Topic 43 提供 VMC on AWS 概述，Topic 69 提供迁移执行细节，已记录于 Source Page Contradictions 节 - -## [2026-04-24] ingest | Public Cloud Learning Sessions (OpenText) - Evolving from DR to Recovery Assurance - 20240723 -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2.md -- Status: ✅ 成功摄入 -- Summary: OpenText DR 向 Recovery Assurance 演进框架——Jim Rose 主讲，涵盖 CrowdStrike 事件警示、RTO/RPO 合同差异、DR 测试瓶颈（被动/手动/按客户时间表）、多云复杂性（AWS/GCP/Azure）、混合架构挑战，以及 Design/Software/Build/Environments 四位框架转型路径。SRE + 可观测性工程是核心驱动力。 -- Concepts identified: RTO, RPO, SRE, Observability-Engineering, Disaster-Recovery, Business-Continuity-Plan, Self-Healing, Customer-Zero-Environment -- Entities identified: OpenText, Jim-Rose, CrowdStrike -- Source page: wiki/sources/public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2.md -- Notes: - - 新增 1 个 Source Page - - Concepts 和 Entities 均以 wikilink 形式建立关联，暂不创建独立页面（各仅出现 1 次，未达 ≥2 次阈值） - - index.md 更新：插入至 Sources 顶部，日期 2026-04-24 - - overview.md 更新：无需更新（已有 ctp-topic-72 覆盖 DR 核心内容，本视频内容已通过 Connections 节与相关 Topic 建立关联） - - 冲突检测：无冲突——与现有 Wiki DR 内容互补，记录于 Source Page Contradictions 节 - -## [2026-04-25] ingest | CTP Topic 31 Network Segregation and Secure Access to the New AWS Landing Zones -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones.md -- Status: ✅ 成功摄入 -- Summary: AWS Landing Zone 网络隔离与安全远程访问方案。核心：①网络隔离——Checkpoint 防火墙 SPI default-deny 阻断内部网络直连 AWS；②安全访问——AWS SSM 替代 VPN，IAM 角色假设 + SSM Agent 实现浏览器/CLI 远程访问。定位为 SD-WAN 实施前过渡方案；长期目标 IaC 化消除控制台访问。与 Topic 18 互补（打通 vs 限制）。 -- Concepts created: (已存在: SD-WAN, AWS-Landing-Zone, Network-Segregation, AWS-Systems-Manager-SSM, SPI-Security-Policy-Infrastructure; 新增 wikilinks 于 source page) -- Entities created: (已存在: Checkpoint) -- Source page: wiki/sources/ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones.md -- Notes: - - 新增 1 个 Source Page - - 冲突记录：与 [[ctp-topic-18-wide-area-networking-in-aws-cloud]] 的视角张力——Topic 18 关注打通网络，Topic 31 关注限制网络；已记录于 source page Contradictions 章节 - -## [2026-04-25] ingest | CTP Topic 18 Wide Area Networking in AWS Cloud -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-18-wide-area-networking-in-aws-cloud.md -- Status: ✅ 成功摄入 -- Summary: AWS Transit Gateway 全球广域网架构与 SD-WAN 演进路径——Micro Focus IT 网络架构师 Christian Deckelman 主讲。核心架构：全球划分为 APJ/EMEA/AMS 三个地理区域，每个区域设立 Hub，Landing Zones 通过 TGW Peering 以星型拓扑接入 Hub，区域 Hub 之间全网状互联。现状依赖静态路由缺乏 BGP，DR 需人工干预。未来演进：引入 Silver Peak SD-WAN 实现动态路径选择，Pulse VPN 迁移至 Prisma Access (SASE) 实现就近接入。 -- Concepts created: AWS-Transit-Gateway, Hub-and-Spoke, SD-WAN, Overlay-Network, Static-Routing, Prisma-Access, TGW-Peering -- Entities created: (已存在: Micro Focus, AWS, Christian Deckelman, Silver Peak, Palo Alto Networks) -- Source page: wiki/sources/ctp-topic-18-wide-area-networking-in-aws-cloud.md -- Notes: - - 新增 1 个 Source Page（wiki/sources/ctp-topic-18-wide-area-networking-in-aws-cloud.md） - - 新增 7 个 Concept 页面 - - index.md 更新：Sources 节新增条目（日期 2026-04-14） - - overview.md 更新：新增 Topic 18 的完整段落 - - 冲突检测：无已知冲突 - -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-43-vmware-cloud-on-aws.md -- Status: ✅ 成功摄入 -- Summary: VMware Cloud on AWS（VMC on AWS）混合云服务介绍——VMware与AWS联合开发，在AWS裸金属服务器（i3.metal/i3en.metal）上原生安装vSphere 8。工作负载可在数秒内往返迁移于本地与云端之间，通过HCX实现any-to-any vSphere迁移。相比常规云方案节省27%成本，云经济学团队可提供TCO计算。 -- Concepts created: VMware-Cloud-on-AWS, HCX, SDDC, Stretched-Cluster, Hybrid-Cloud -- Entities created: VMware, AWS -- Source page: wiki/sources/ctp-topic-43-vmware-cloud-on-aws.md -- Notes: - - 新增 1 个 Source Page（wiki/sources/ctp-topic-43-vmware-cloud-on-aws.md） - - 新增 2 个 Entity 页面（VMware.md, AWS.md） - - 新增 4 个 Concept 页面（VMware-Cloud-on-AWS.md, HCX.md, SDDC.md, Stretched-Cluster.md） - - index.md 更新：Sources 节新增条目（日期 2026-04-25，置顶于所有条目最前）；Entities 节新增 VMware 和 AWS；Concepts 节新增 4 个概念 - - overview.md 更新：新增 Topic 43 的完整段落；Key Concepts 新增 VMware-Cloud-on-AWS、VMware、HCX、SDDC、Stretched-Cluster、Hybrid-Cloud - - 冲突检测：与 ctp-topic-53-why-bother-with-cloud 存在是否应迁移至云端的观点张力，已在 source page 中记录为 Contradictions - -## [2026-04-24] ingest | CTP Topic 61 Workload VPC provision with IPAM Automation -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-61-workload-vpc-provision-with-ipam-automation.md -- Status: ✅ 成功摄入 -- Summary: -- Concepts created: VPC-自动化供给, CIDR-审批流程, Availability-Zone-ID -- Source page: wiki/sources/ctp-topic-61-workload-vpc-provision-with-ipam-automation.md -- Notes: - - 新增 1 个 Source Page（wiki/sources/ctp-topic-61-workload-vpc-provision-with-ipam-automation.md） - - index.md 更新：Sources 节新增条目（日期 2026-04-24，置顶于所有条目最前）；移除原有的 source missing 条目 - - overview.md 更新：新增 Topic 45 和 Topic 61 的完整段落，描述 IPAM 的"机制 → 应用"完整链路；Key Concepts 新增 [[VPC-自动化供给]] 和 [[CIDR-审批流程]] - - 冲突检测：无已知冲突内容 - - IPAM（IP Address Management）和 Infoblox Grid 概念已在 overview.md Key Concepts 中，无需单独 Concept 页面 - -## [2026-04-24] ingest | CTP Topic 45 Automatic IP address allocation with IPAM -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-45-automatic-ip-address-allocation-with-ipam.md -- Status: ✅ 成功摄入 -- Summary: 使用 Infoblox NIOS IPAM 实现 AWS VPC 自动化 IP 地址分配的架构实践。核心内容：①传统方式（手工请求→网络团队计算CIDR→电子表格→手工配置YAML）效率低下；②Infoblox NIOS 自动分配下一个可用 IP 地址块（≤/24 自动，>/24 需审批）；③新 YAML 配置仅声明期望子网大小和区域父 CIDR，不含硬编码 IP；④销毁 VPC 时自动从 IPAM Grid 清除条目，支持撤销保护；⑤向后兼容旧配置。目标：创建 VPC 无需网络团队参与，建立单一可信数据源。 -- Concepts created: IPAM（IP Address Management），Infoblox-NIOS，VPC-自动化供给 -- Source page: wiki/sources/ctp-topic-45-automatic-ip-address-allocation-with-ipam.md -- Notes: - - 新增 1 个 Source Page（wiki/sources/ctp-topic-45-automatic-ip-address-allocation-with-ipam.md） - - index.md 更新：将原有的 source missing 条目替换为正式条目（日期 2026-04-24） - - IPAM 关键概念在 source page 内已有详细说明，无需单独 Concept 页面 - - 冲突检测：无已知冲突内容 - -## [2026-04-24] ingest | CTP Topic 19 Configuring DNS within AWS LZs -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-19-configuring-dns-within-aws-lzs.md -- Status: ✅ 成功摄入 -- Summary: AWS Landing Zone 多账号环境中的集中化 DNS 配置架构——Sankar Gopov 主讲。核心内容：①设立专用 DNS 账号集中管理所有私有托管区（优于分散管理）；②Route 53 Resolver Inbound/Outbound Endpoints 打通混合 DNS（Inbound 接收本地请求，Outbound 转发 AWS 请求至本地）；③AWS RAM 跨账号共享 Resolver Rules；④跨账号 VPC 关联必须先授权（Authorization）再关联（Association）；⑤Terraform 自动化实现新账号上线即具备完整解析能力。 -- Concepts created: Hybrid DNS Resolution, Route 53 Resolver Rules, VPC Association Authorization, Terraform DNS Automation -- Entities created: Sankar Gopov -- Source page: wiki/sources/ctp-topic-19-configuring-dns-within-aws-lzs.md -- Notes: - - 新增 1 个 Source Page（wiki/sources/ctp-topic-19-configuring-dns-within-aws-lzs.md） - - 新增 1 个 Entity 页面（wiki/entities/SankarGopov.md） - - 新增 1 个 Concept 页面（wiki/concepts/HybridDnsResolution.md） - - index.md 更新：Sources 节新增条目（日期 2026-04-24，置顶于所有条目最前） - - overview.md 更新：更新 CTP Topic 22 段落，移除"（待摄入）"标注，补全两条 DNS 视频的知识体系关系描述 - - 冲突检测：与 [[ctp-topic-22-global-dns-service-offerings]] 存在潜在视角差异——DNS 账号是否应包含公共托管区；前者侧重落地配置，后者侧重服务提供架构；两者的冲突是视角互补而非逻辑矛盾 - -## [2026-04-26] ingest | CTP Topic 36 SendGrid as an Email Service -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-36-sendgrid-as-an-email-service.md -- Status: ✅ 成功摄入 -- Summary: SendGrid 被选定为 CTP 标准邮件服务，替换 Port 25 不安全的语义消息网关和每封限制 50 收件人的 SES。SendGrid 支持每封最多 1,000 收件人、TLS 端到端加密、双因素认证；两种架构（直连 vs 中继）；配置要求 software.microcopy.com 域名、smtp.sendgrid.net:587、TLS；SPF/DKIM 必要；API 密钥 180 天轮换；日志 7 天保留。同期更新了 Cyber Suite 加密标准（FIPS/Java/Golang/Node.js/OpenCell 等），可选套件因含 CBC 弱加密仅作向后兼容。 -- Concepts created: SPF, DKIM, TLS, API-Key-Rotation, Cyber-Suite, CBC-Mode -- Entities touched: SendGrid, Twilio, Rejoy Ganapati, Rajiv, Yu-Yan, PSAC -- Source page: wiki/sources/ctp-topic-36-sendgrid-as-an-email-service.md -- Notes: - - 新增 1 个 Source Page（wiki/sources/ctp-topic-36-sendgrid-as-an-email-service.md） - - 所有 Concepts 和 Entities 均以 wikilink 形式建立关联，暂不创建独立页面（各仅出现 1 次，未达 ≥2 次阈值） - - index.md 更新：Sources 节新增条目（日期 2026-04-14，置顶于 CTP Topic 34 之后） - - overview.md 更新：新增 CTP Topic 36 摘要段落（置于 ctp-topic-22 之后，ctp-topic-17 之前）；Key Concepts 列表新增 8 个概念（SPF/DKIM/TLS/API-Key-Rotation/Cyber-Suite/CBC-Mode/SendGrid/Twilio） - - 冲突检测：与 [[ctp-topic-12-using-ses-smtp-service-terraform-module]] 存在冲突——SES 作为标准邮件服务 vs SendGrid 被选定为新标准；SES 适合 AWS 原生集成场景，SendGrid 为大规模需求首选 - - -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-22-global-dns-service-offerings.md -- Status: ✅ 成功摄入 -- Summary: 企业级全球 DNS 服务架构详解——Sankar 和 Vino 主讲。核心架构：Route 53 Private Hosted Zone + AD 托管 DNS，通过 Route 53 Resolver 入站/出站终端节点打通 AWS VPC 与本地网络 DNS 查询；Outbound Endpoint 配置多区域 AD 域控制器 IP 实现故障自动切换；Infoblox Anycast 提供本地 DNS 全球低延迟和高可用；AWS EC2 不支持 Anycast；DNS 安全涵盖防隧道攻击、缓存污染等；就近解析优化 Office 365 访问 -- Concepts touched: Hybrid DNS Resolution、Route 53 Private Hosted Zone、Route 53 Resolver、DNS Anycast、Infoblox Grid、IPAM（IP Address Management）、Active Directory DNS、Landing Zone -- Entities touched: AWS、Infoblox、Microsoft Active Directory、Office 365、Sankar、Vino -- Source page: wiki/sources/ctp-topic-22-global-dns-service-offerings.md -- Notes: - - 新增 1 个 Source Page（wiki/sources/ctp-topic-22-global-dns-service-offerings.md） - - 所有 Concepts 和 Entities 均以 wikilink 形式建立关联，暂不创建独立页面（各仅出现 1 次，未达 ≥2 次阈值） - - index.md 更新：Sources 节替换预期占位符为正式条目（日期修正为 2026-04-14） - - overview.md 更新：新增 CTP Topic 22 摘要段落（置于 ctp-topic-14 之后，ctp-topic-17 之前）；Key Concepts 列表新增 7 个 DNS 相关概念 - - 冲突检测：ctp-topic-19（configuring DNS within AWS LZs）尚未摄入，无法进行完整对比；source page Contradictions 节已记录，待 ctp-topic-19 摄入后补充对比 - -## [2026-04-26] ingest | CTP Topic 50 AMI Roadmap for AWS AMIs -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-50-ami-roadmap-for-aws-amis.md -- Status: ✅ 成功摄入 -- Summary: CCOE AMI 路线图详解——涵盖 CCOE AMI 路线图规划、操作系统 EOL 时间线（Windows Server 2008/2008 R2 已 EOL；CentOS 8 已 EOL；Windows Server 2012 将于 2023 年 10 月 EOL；RHEL 7 和 CentOS 7 将于 2024 年 6 月 EOL）、AMI 通知机制、变更日志（CCRE 门户）、新 AMI 添加流程、当前支持的 AMI 清单及未来路线图。自 2023 年 5 月起所有 ARM AMI 同步发布。路线图优先级主要由 ADM 需求驱动，变更需通过需求管道流程提交。AMI 通过跨账号共享分发给组织内所有账户。 -- Concepts touched: Foundation AMI、OS-End-of-Life、AMI Sharing、ARM-AMI、CCOE、ADM、SSM Agent -- Entities touched: CCOE、AWS、Ubuntu、CentOS、Rocky Linux、Red Hat Enterprise Linux、SLES、Windows Server、McAfee -- Source page: wiki/sources/ctp-topic-50-ami-roadmap-for-aws-amis.md -- Notes: - - 新增 1 个 Source Page（wiki/sources/ctp-topic-50-ami-roadmap-for-aws-amis.md） - - 所有 Concepts 和 Entities 均以 wikilink 形式建立关联，暂不创建独立页面（各仅出现 1 次，未达 ≥2 次阈值） - - index.md 更新：Sources 节替换预期占位符为正式条目（日期修正为 2026-04-14） - - overview.md 更新：新增 CTP Topic 50 摘要段落（置于 learning-sessions-standard-amis-updates 之后，ctp-topic-26 之前） - - 冲突检测：与 [[learning-sessions-standard-amis-updates]] 的 EOL 时间线一致（CentOS 7/RHEL 7 将于 2024 年 6 月 EOL）；与 [[ctp-topic-26-standard-ami-build-publish-share-processes]] 存在描述角度差异（本话题聚焦路线图规划，Topic 26 聚焦生命周期管理），非矛盾而是互补关系，已记录于 Source Page Contradictions 节 - -## [2026-04-24] ingest | CTP Topic 40 SaaS Database Architecture On AWS Cloud -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-40-saas-database-architecture-on-aws-cloud.md -- Status: ✅ 成功摄入 -- Summary: SAS 数据库团队在 AWS 云上的架构与运维实践——全球分布式团队（美国/加拿大/印度/以色列）提供 24/7 支持，管理 500+ 数据库和 1000+ DB 服务器；支持 Oracle、Vertica、Postgres、DynamoDB、SQL Server、MongoDB、MySQL 等多引擎；高可用架构采用三可用区模式（主库/备用库/见证节点）；使用 Oracle Data Guard、Postgres Active-Passive/Active-Active、RDS HA 实现多活；通过 Terraform、AWS CLI、Shell/PowerShell 实现 IaC 自动化；Oracle GoldenGate 支持零停机迁移 -- Concepts created: 无新增（高可用/Oracle Data Guard/Multi-AZ Deployment/Database Migration/DB-as-a-Service 各仅出现 1-2 次，不满足 ≥2 次建页条件，跳过独立建页） -- Entities created: 无新增（AWS/RDS/Aurora/Terraform/Micro Focus 各仅出现 1-2 次，不满足 ≥2 次条件，跳过独立建页） -- Source page: wiki/sources/ctp-topic-40-saas-database-architecture-on-aws-cloud.md -- Notes: - - 新增 1 个 Source Page（wiki/sources/ctp-topic-40-saas-database-architecture-on-aws-cloud.md） - - 所有 Concepts 和 Entities 均以 wikilink 形式建立关联，暂不创建独立页面（未达 ≥2 次阈值） - - index.md 更新：Sources 节新增条目（置顶） - - overview.md 更新：新增 CTP Topic 40 摘要段落（置于 ctp-topic-10 之后，ctp-topic-46 之前）；Key Concepts 列表新增 Database Migration - - 冲突检测：无明显冲突内容 - -## [2026-04-26] ingest | CTP Topic 26 Standard AMI – build, publish, share processes -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-26-standard-ami-build-publish-share-processes.md -- Status: ✅ 成功摄入 -- Summary: Foundation AMI 全生命周期管理详解——基于市场主流 OS（CentOS/Ubuntu/Windows）进行 CIS 安全基准加固；集成 McAfee EPO + Syslog-ng + AD SSO + SSM Agent + SiteScope；HashiCorp Packer + Jenkins 流水线实现全自动化；跨账号 AMI Sharing 分发至全球多区域（俄勒冈/法兰克福/悉尼）；每两个月更新，N-2 版本保留策略；责任共担模型（CCOE 提供 Foundation AMI，产品团队构建产品特定 AMI） -- Concepts created: 无新增（Foundation AMI/OS Hardening/CIS Benchmarks/HashiCorp Packer/SSM Agent/AMI Sharing/Central Repository 各仅出现 1 次，不满足 ≥2 次建页条件，跳过独立建页） -- Entities created: 无新增（Srihari/Alan/Praveen 各仅出现 1 次，不满足 ≥2 次条件；CCOE 仅出现 1 次） -- Source page: wiki/sources/ctp-topic-26-standard-ami-build-publish-share-processes.md -- Notes: - - 新增 1 个 Source Page（wiki/sources/ctp-topic-26-standard-ami-build-publish-share-processes.md） - - 7 个 Concept 均以 wikilink 形式建立关联，暂不创建独立页面（未达 ≥2 次阈值） - - index.md 更新：Sources 节替换预期条目占位符为正式条目（日期修正为 2026-04-14） - - overview.md 更新：新增 CTP Topic 26 摘要段落（置于 learning-sessions-standard-amis-updates 之后，替换原 ctp-topic-58 段落位置）；Key Concepts 列表新增 Foundation AMI / OS Hardening / CIS Benchmarks / AMI Sharing / Central Repository - - 冲突检测：与 [[ctp-topic-58-aws-ec2-image-builder]] 描述不同 AMI 生命周期阶段——ctp-topic-26 描述当前 Packer+Jenkins 生产实践，ctp-topic-58 描述 EC2 Image Builder 未来演进方向，非冲突而是演进关系，已记录于 Source Page Contradictions 节 - -## [2026-04-23] ingest | CTP Topic 68 Introduction to Redshift -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-68-introduction-to-redshift.md -- Status: ✅ 成功摄入 -- Summary: AWS Redshift 数据仓库入门——核心架构（Leader Node + Compute Node + Slices）、MPP 并行处理、列式存储 vs 行式存储、数据压缩（ZSTD/LZO）、Sort Key / Distribution Key 优化、RA3 实例类型（AWS 托管 NVMe） -- Concepts created: [[MPP]], [[Columnar-Storage]] -- Entities created: [[Amazon-Redshift]] -- Source page: wiki/sources/ctp-topic-68-introduction-to-redshift.md -- Notes: - - 新增 1 个 Source Page（wiki/sources/ctp-topic-68-introduction-to-redshift.md） - - 新增 1 个 Entity Page（wiki/entities/Amazon-Redshift.md） - - 新增 2 个 Concept Page（wiki/concepts/MPP.md、wiki/concepts/Columnar-Storage.md） - - index.md 更新：Sources 节移除预期占位符（"source missing"）替换为正式条目；Entities 节新增 Amazon-Redshift；Concepts 节新增 MPP、Columnar-Storage - - overview.md 更新：新增 CTP Topic 68 摘要段落（置于 ctp-topic-51 之后）；Key Concepts 列表新增 Data-Warehouse、MPP、Columnar-Storage、Sort-Key、Distribution-Key - - 冲突检测：与 [[ctp-topic-66-rds-vs-aurora]] 存在架构差异（Redshift 独立 Compute Node vs Aurora 共享存储），记录于 Source Page 的 Contradictions 节 - - Sort Key 和 Distribution Key 概念因在其他页面中暂未出现，本次不创建独立页面 - -## [2026-04-14] ingest | CTP Topic 58 AWS EC2 Image Builder -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-58-aws-ec2-image-builder.md -- Status: ✅ 成功摄入 -- Summary: AWS EC2 Image Builder 替代 Packer/Jenkins 实现企业级 AMI 生命周期自动化——通过 Pipeline/Recipe/Component/Infrastructure Config 四层抽象，将 CCOE 加固脚本转换为可复用组件；POC 实现 CentOS 7 和 Ubuntu 18 端到端流水线；Lambda 工作流触发 AWS Inspector 扫描、邮件通知和 S3 报告归档 -- Concepts identified: [[Golden-AMI]], [[CCOE]], [[Image-Pipeline]], [[Image-Recipe]], [[Image-Component]], [[Infrastructure-Configuration]], [[Distribution-Settings]], [[AWS-Inspector]] -- Entities identified: [[AWS]]（仅出现 1 次，不满足 ≥2 次建页条件，跳过独立建页） -- Source page: wiki/sources/ctp-topic-58-aws-ec2-image-builder.md -- Notes: - - 新增 1 个 Source Page - - 新增 8 个 Concept，均仅出现 1 次，不满足 ≥2 次建页条件，本次不创建独立页面 - - AWS Entity 页面已存在于 wiki/entities/（Amazon-RDS.md 等系列页面），本次复用 - - index.md 更新：Sources 节替换预期条目占位符为正式条目（日期修正为 2026-04-14） - - overview.md 更新：新增 CTP Topic 58 摘要段落（置于 learning-sessions-standard-amis-updates 之后） - - 冲突检测：与 [[ctp-topic-26-standard-ami-build-publish-share-processes]] 描述不同 AMI 生命周期阶段，非冲突，记录于 Source Page 的 Contradictions 节 - -## [2023-12-05] ingest | Learning Sessions: Standard AMI Updates 20231205 -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2.md -- Status: ✅ 成功摄入 -- Summary: AWS 标准 AMI 更新机制与生命周期管理——标准 AMI 基于 AWS 原生镜像增加 OS 加固、安全补丁、SSM Agent、QALIS Agent；Jenkins 多分支流水线构建测试 AMI，将验证周期从 3-4 天缩短至 60 分钟；支持 23 种 AMI 涵盖 Amazon Linux/CentOS/OEL/RHEL/Rocky Linux/SUSE/Ubuntu/Windows；机器人框架自动化验证为核心优化手段；CentOS 7/RHEL 7 将于 2024 年 6 月 EOL，由 Rocky Linux 替代；SSM 打补丁方案适用于长期运行实例。 -- Concepts identified: [[Amazon-Machine-Image]], [[Jenkins-Multi-Branch-Pipeline]], [[AWS-Inspector]], [[Robotic-Framework]], [[SSM-Patching]], [[GP3-EBS-Storage]], [[OS-End-of-Life]] -- Entities identified: [[Rocky-Linux]], [[Sentinel-1]]（均仅出现 1 次，不满足 ≥2 次建页条件，跳过独立建页） -- Source page: wiki/sources/learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2.md -- Notes: - - 新增 1 个 Source Page - - 新增 overview.md 条目，置于 CTP Topic 7 之前（按日期 2023-12-05 排序） - - 7 个 Concept 均仅出现 1 次，不满足 ≥2 次建页条件，本次不创建独立 Concept 页面 - - 无内容冲突 - -## [2026-04-23] ingest | CTP Topic 7 SaaS Landing Zone Design -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-7-saas-landing-zone-design.md -- Status: ✅ 成功摄入 -- Summary: SAS（生产）Landing Zone 顶层设计——采用单一 Landing Zone 承载所有产品组；定义四层账户体系（Core Accounts: Shared/Logs/Security；Baseline Accounts: Network/DNS/AD；Shared Services Accounts: Software Factory/Cyber/ARC/Monitoring；Product Accounts）；Terraform IaC + GitHub/Jenkins CI/CD 端到端自动化部署链路（GitHub Hook → Jenkins → Management VPC → Lambda → ECS Cluster）；工作负载置于私有子网，WAF + CloudFront 提供入站安全；远程接入从 Checkpoint VPN 迁移至 Pulse VPN（AD 认证）。 -- Concepts identified: [[Landing-Zone-Architecture]], [[Active-Directory-Integration]], [[Transit-Gateway]], [[WAF-Web-Application-Firewall]], [[Private-Subnet-Architecture]], [[Terraform-IaC]] -- Entities identified: [[Gruntwork]], [[Jenkins]], [[Checkpoint]], [[CloudFront]], [[Qalis]], [[OBM]]（均仅出现 1 次，不满足 ≥2 次建页条件，跳过独立建页） -- Source page: wiki/sources/ctp-topic-7-saas-landing-zone-design.md -- Notes: - - 新增 1 个 Source Page - - 新增 6 个 Concept（Landing-Zone-Architecture/Active-Directory-Integration/Transit-Gateway/WAF-Web-Application-Firewall/Private-Subnet-Architecture/Terraform-IaC），均仅出现 1 次，不满足 ≥2 次建页条件，本次不创建独立页面 - - 新增 6 个 Entity（Gruntwork/Jenkins/Checkpoint/CloudFront/Qalis/OBM），均仅出现 1 次，不满足 ≥2 次条件，跳过独立建页 - - Gruntwork、Checkpoint Entity 页面已存在于 wiki/entities/，本次复用 - - Landing-Zone-Architecture Concept 页面已存在于 wiki/concepts/，本次复用 - - index.md 更新：Sources 节替换预期条目占位符为正式条目 - - overview.md 更新：新增 CTP Topic 7 摘要段落（置于 ctp-topic-1 之前） - - 冲突检测：与 [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] 存在时间维度的架构演进关系（非冲突）——ctp-topic-7 定义原始设计，ctp-topic-35 补充近期变更（网络分段、Pulse VPN 替换 Checkpoint VPN），记录于 Source Page 的 Contradictions 节 - -## [2026-04-14] ingest | CTP Topic 34 Azure Landing Zone Architecture Overview -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-34-azure-landing-zone-architecture-overview.md -- Status: ✅ 成功摄入 -- Summary: Kishore Garlopati 讲解 Azure Landing Zone 在 Micro Focus 的实施架构。核心：Azure Enterprise Enrollment → 管理组（Management Groups）四层分级（Platform/Landing Zones/Decommission/Sandbox）→ 独立订阅隔离目的 → Terraform Cloud IaC 自动化。Platform 层含 Identity 和 Connectivity 两个独立订阅；Connectivity 订阅作为中心枢纽汇聚所有入站/出站 Azure 流量（含 DDoS 防护和 Checkpoint 防火墙）；Landing Zones 设计为可扩展、模块化、全自动化；Terraform Cloud 管理跨订阅依赖；PIM/PAG 实现精细化访问控制。 -- Concepts identified: [[Azure Landing Zone]], [[Management Groups]], [[Terraform Cloud]], [[Privileged Identity Management (PIM)]], [[Privileged Access Groups]] -- Source page: wiki/sources/ctp-topic-34-azure-landing-zone-architecture-overview.md -- Notes: - - 新增 1 个 Source Page - - 新增 5 个 Concept（Azure Landing Zone / Management Groups / Terraform Cloud / Privileged Identity Management (PIM) / Privileged Access Groups），均仅出现 1 次，不满足 ≥2 次建页条件，本次不创建独立页面 - - 新增 1 个 Entity（Kishore Garlopati），仅出现 1 次，不满足 ≥2 次条件，本次不创建独立页面 - - index.md 更新：Sources 节替换预期条目占位符为正式条目 - - overview.md 更新：Cloud Transformation & DevOps 节新增 Azure Landing Zone 概念标注 - - 无冲突检测到 - - 本文档原状态为"🟡 Awaiting Whisper transcription → Summary"，现已摄入完成 - -## [2026-04-23] ingest | CTP Topic 35 AWS Landing Zone Design Refresher (SaaS Labs) -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-35-aws-landing-zone-design-refresher-saas-labs.md -- Status: ✅ 成功摄入 -- Summary: AWS Landing Zone 设计复习，明确 SaaS（生产）与 Labs（开发）的职责划分。SaaS LZ 为每个产品区域提供客户专属产品账户，连接共享服务账户（安全、日志、网络）；核心账户组含 AD、DNS、Network 账户；Gruntwork 账户跨所有账户管理 AMI、日志和安全。近期变更：网络分段阻断 SaaS 工作负载直接连通性；CCOEs CloudTrail 取代 Gruntworks CloudTrail；入站流量通过 Network 账户 Checkpoint 重新路由；AWS Backup 有望强制化；新账户可能取消 Management VPC。核心结论：SaaS = 生产，Labs = 开发；PoC LZ 并入 Labs。 -- Concepts created: [[AWS-Landing-Zone]], [[Gruntwork]], [[Shared-Services-Account]], [[Core-Accounts]], [[Product-Accounts]], [[Gruntwork-Accounts]], [[CCOEs-CloudTrail]], [[Network-Segmentation]] -- Source page: wiki/sources/ctp-topic-35-aws-landing-zone-design-refresher-saas-labs.md -- Notes: - - 新增 1 个 Source Page - - 新增 8 个 Concept（AWS-Landing-Zone/Gruntwork/Shared-Services-Account/Core-Accounts/Product-Accounts/Gruntwork-Accounts/CCOEs-CloudTrail/Network-Segmentation） - - 新增 1 个 Entity（Cloud-Technology-Design-Forum，仅在本文档提及，不满足 ≥2 次条件，跳过独立建页） - - overview.md 更新：新增 CTP Topic 35 摘要段落（置于 ctp-topic-1 之前） - - index.md 更新：Sources 节替换预期条目占位符为正式条目 - - 无冲突检测到 - -## [2026-04-14] ingest | CTP Topic 47 Enterprise Architecture Cloud Standards -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-47-enterprise-architecture-cloud-standards.md -- Status: ✅ 成功摄入 -- Summary: Lindsay 分享企业架构云标准。核心：Landing Zone 框架聚焦安全、合规和可管理性；账户结构与环境和角色对齐，零信任+最小权限原则；Terraform/Terragrunt 实现 IaC 标准化；云防护栏文档捕获强制性要求和最佳实践；功能分区将单体应用拆分为更小的独立模块或无服务器函数；强调需要应用团队输入完善防护栏。 -- Concepts created: [[Landing Zone]], [[Cloud Guardrails]], [[Functional Partitioning]] -- Source page: wiki/sources/ctp-topic-47-enterprise-architecture-cloud-standards.md -- Notes: - - 新增 1 个 Source Page - - 新增 3 个 Concept（Landing Zone / Cloud Guardrails / Functional Partitioning） - - overview.md 更新：新增 CTP Topic 47 摘要段落（置于 ctp-topic-17 之后） - - 无 Entity 创建（Lindsay 仅出现 1 次，不满足 ≥2 次条件） - - 无冲突检测到 - -## [2026-04-14] ingest | CTP Topic 72 Implementing an Enterprise DR Strategy Using AWS Backup -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup.md -- Status: ✅ 成功摄入 -- Summary: AWS 解决方案架构师 Sabith 深入讲解企业级灾难恢复策略与 AWS Backup 架构设计。核心：HA（高可用）关注运行时间和 MTBF，DR（灾难恢复）专注防止数据丢失；RPO/RTO 定义恢复目标；AWS Backup 集中化、基于策略，支持跨账户跨区域复制；四级 DR 架构模式（Backup and Restore → Pilot Light → Warm Standby → Active-Active）；增量备份节省成本；Vault Lock 合规模式防勒索软件；Bunker Account + Forensic Account 增强隔离性和测试验证。 -- Concepts created: [[高可用（High Availability）]], [[灾难恢复架构模式]], [[Vault Lock]], [[跨账户备份]], [[增量备份]], [[全量备份]], [[AWS Backup Audit Manager]] -- Source page: wiki/sources/ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup.md -- Notes: - - 新增 1 个 Source Page - - 新增 7 个 Concept（高可用/灾难恢复架构模式/Vault Lock/跨账户备份/增量备份/全量备份/AWS Backup Audit Manager） - - overview.md 更新：新增 CTP Topic 72 摘要段落（置于 ctp-topic-17 之后），Key Concepts 节新增 7 个概念标注 - - index.md 更新：Sources 节新增条目（置顶于 ctp-topic-28 之前），并删除预期条目占位符 - - 冲突检测：与 [[ctp-topic-44-aws-backup-in-micro-focus]] 互补而非冲突，Topic 72 提供理论框架，Topic 44 提供内部评估视角，构成完整 AWS Backup 知识体系 - - 与 [[ctp-topic-44-aws-backup-in-micro-focus]] 和 [[ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program]] 三者构成递进关系（理论基础 → 内部评估 → 迁移实施） - -## [2026-04-23] ingest | CTP Topic 51 Architecting with AWS Purpose-Built Databases -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-51-architecting-with-aws-purpose-built-databases.md -- Status: ✅ 成功摄入 -- Summary: AWS 数据库专家 Femi George 分享专用数据库选型与架构原则。核心：现代应用"为正确的工作选择正确的专用数据库"，避免一刀切。AWS 提供完整数据库品类（关系型/NoSQL/键值/文档/宽列/内存/图/时序）。实战案例：Duolingo 用 DynamoDB + ElastiCache + Aurora；Netflix 用 DynamoDB 做高弹性 JSON；Peloton 用 ElastiCache Redis 即时反馈。云时代 DBA 从平台管理转向应用创新。 -- Entities created: Amazon-DynamoDB, Amazon-DocumentDB, Amazon-ElastiCache, Amazon-Keyspaces, Amazon-Neptune, Amazon-Timestream -- Concepts created: Purpose-Built-Databases, DBA-Role-Evolution, Multi-Database-Architecture -- Source page: wiki/sources/ctp-topic-51-architecting-with-aws-purpose-built-databases.md -- Notes: - - 新增 1 个 Source Page - - 新增 6 个 Entity（Amazon-DynamoDB/ElastiCache/Neptune/Timestream/Keyspaces/DocumentDB） - - 新增 3 个 Concept（Purpose-Built-Databases / DBA-Role-Evolution / Multi-Database-Architecture） - - overview.md 更新：新增 CTP Topic 51 摘要段落，置于 ctp-topic-66 之前 - - index.md 更新：Sources 节替换预期条目为实际摘要，Entities 节新增 6 个实体，Concepts 节新增 3 个概念 - - 冲突检测：与 [[ctp-topic-66-rds-vs-aurora]] 视角互补而非冲突，已记录于 Source Page Contradictions 节 - -## [2026-04-23] ingest | CTP Topic 46 NetApps on AWS -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-46-netapps-on-aws.md -- Status: ✅ 成功摄入 -- Summary: Sandeep 和 Yael 主讲的 NetApp 存储系统培训。覆盖传统 NetApp 架构（ONTAP / Aggregate / FlexVol / Qtree / LUN / LIF / SVM）和 AWS 云版本 CVO。CVO 通过 EC2 实例提供软件定义存储，支持单节点或 HA 配对（跨多 AZ 同步复制）；数据分层机制将 30 天非活跃数据从 EBS 自动迁移到 S3；SnapMirror 实现块级跨集群复制；迁移工具包括 SnapMirror、NetApp XCP、Cloud Sync、AWS DataSync。组织已在 15 个 AWS 区域部署约 1.3 PB 数据。 -- Concepts created: [[SnapMirror]] -- Entities created: [[NetApp]] -- Source page: wiki/sources/ctp-topic-46-netapps-on-aws.md -- Notes: - - 新增 1 个 Source Page - - 新增 1 个 Entity（NetApp） - - 新增 1 个 Concept（SnapMirror） - - overview.md 更新：新增 CTP Topic 46 摘要段落，置于 ctp-topic-66 之前 - - index.md 更新：Sources 节新增条目（置顶于 Blogwatcher 前），Entities 节新增 NetApp，Concepts 节新增 SnapMirror - - 冲突检测：暂无检测到与其他 Wiki 页面的冲突（NetApp 存储与 RDS/Aurora 属不同技术域，互补关系） - -## [2026-04-14] ingest | CTP Topic 17 Active Directory Services in Gruntwork AWS LZs -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs.md -- Status: ✅ 成功摄入 -- Summary: Paul 讲解 Gruntwork AWS Landing Zones 中的 AD 服务集成。核心内容：双域名策略（`swinford.net` 用于 R&D Labs，`intsas.local` 用于生产/SAS 环境）；SRE 预制 AMI 内置 PowerShell（Windows）/Shell（Linux）域加入脚本，通过 Terraform `user_data` 触发自动域加入；旧域名 `infra` 和 `AST` 已废弃，提供迁移路径；Linux 支持安全动态更新（Secure Dynamic Updates）自动注册 DNS A 记录；R&D 环境使用 MIM 自助服务，生产/SAS 环境通过 SMACKS 工单系统申请账号。 -- Concepts created: [[Swinford.net]]（作为 AD 域名概念）、[[Intsas.local]]（作为 AD 域名概念）、[[SMACKS]]（作为工单系统概念） -- Entities created: [[Gruntwork]]（Company/Project类实体）、[[SMACKS]]（Project类实体） -- Source page: wiki/sources/ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs.md -- Notes: - - 新增 1 个 Source Page - - 新增 1 个 Entity（Gruntwork） - - 新增 2 个 AD 域名概念实体（Swinford.net、Intsas.local） - - 新增 1 个工单系统实体（SMACKS） - - overview.md 更新：新增 CTP Topic 17 摘要段落 - - 冲突检测：暂无检测到与其他 Wiki 页面的冲突 - -## [2026-04-24] ingest | CTP Topic 66 Exposing the differences between PostgreSQL RDS and Aurora -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora.md -- Status: ✅ 成功摄入 -- Summary: Greg Klau 深度对比 PostgreSQL RDS 与 Aurora。核心维度：①最小规格/成本（RDS 更低）；②最大容量/IO性能（Aurora 更优，>10-20TB首选）；③RTO（Aurora 30秒 vs RDS 2分钟）；④存储灵活性（RDS GP2/GP3/预置IOPS/磁性，Aurora按IO收费）；⑤架构（RDS：EC2+EBS分离，Multi-AZ备用；Aurora：6副本跨3AZ共享集群卷）；⑥Blue-Green部署（仅Aurora MySQL支持）；⑦端点设计（Aurora独立Writer/Reader Endpoint）。高可用调优：DNS TTL=1秒、TCP Keep-Alive、JDBC reader/writer端点路由。 -- Concepts created: [[RTO]] -- Entities created: [[Amazon-Aurora]]（Product类实体）、[[Amazon-RDS]]（Product类实体） -- Source page: wiki/sources/ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora.md -- Notes: - - 新增 1 个 Source Page - - 新增 1 个 Concept（RTO，灾备核心指标） - - 新增 2 个 Entity（Amazon-Aurora、Amazon-RDS） - - 冲突检测：与 learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform 存在视角差异——Terraform IaC 部署关注资源标准化，存储选型属运维决策层面，已记录于 Contradictions - - overview.md 更新：新增 CTP Topic 66 摘要段落，更新 Key Entities 和 Key Concepts - -## [2026-04-23] ingest | CTP Topic 14 Octane Hub on AWS Real Life Experience -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services-i.md -- Status: ✅ 成功摄入 -- Summary: Octane Hub CTO Holger Rode 分享将生产服务从 Bibling Lab 数据中心迁移到 AWS Landing Zone 的实战经验。涵盖 Docker 容器化工作负载（QuickSee、Release Manager、Patch Manager 等）、Packer+Terraform/TerraGrunt IaC 演进、EFS vs EBS 存储选型（EFS 不适合数据库，需用 EBS）、VPC Transit Gateway 网络互联、Route 53 DNS 设置。下一步：DR 改进、MSSQL→Postgres 迁移、ECS 演进。 -- Concepts created: [[Docker-Containerization]]、[[EFS-vs-EBS]] -- Entities created: [[Octane-Hub]] -- Source page: wiki/sources/ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services-i.md -- Notes: - - 新增 1 个 Source Page - - 新增 2 个 Concept（Docker-Containerization、EFS-vs-EBS） - - 新增 1 个 Entity（Octane-Hub） - - 冲突检测：与 ctp-topic-7（SaaS Landing Zone 设计）存在视角差异——前者侧重多租户架构，后者侧重单体团队实际迁移路径，已记录于 Contradictions - -## [2026-04-24] ingest | CTP Topic 44 AWS Backup in Micro Focus -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-44-aws-backup-in-micro-focus.md -- Status: ✅ 成功摄入 -- Summary: AWS Backup 托管服务详解，vs Micro Focus 当前分散式快照管理。涵盖四级 DR 策略（Backup and Restore / Pilot Light / Warm Standby / Active-Active），不可变性防勒索软件，法律保留合规，AWS Backup 功能演示（备份保管库、备份计划、时间点恢复），以及当前流程的五大差距。 -- Concepts created: 无（AWS Backup / RTO / RPO / Disaster Recovery / Pilot Light / Warm Standby / Active-Active / Legal Holds 已在 overview Key concepts 中覆盖） -- Entities created: 无（CCIE 门户仅出现1次，不满足创建条件） -- Source page: wiki/sources/ctp-topic-44-aws-backup-in-micro-focus.md -- Notes: - - 新增 1 个 Source Page - - 无新增 Entity/Concept - - 无冲突内容，与 ctp-topic-72、ctp-topic-73 构成递进关系 - -## [2026-04-24] ingest | 实战笔记：本地部署 RSSHub 并获取 YouTube 订阅 -- Source file: Home Office/实战笔记：本地部署 RSSHub 并获取 YouTube 订阅.md -- Status: ✅ 成功摄入 -- Summary: 本地 Docker 部署 RSSHub（diygod/rsshub，端口1200），通过浏览器 view-source 方式获取 YouTube 频道 ID，使用 `/youtube/channel/{channel_id}` 路由生成稳定 RSS 订阅源。相比第三方在线服务，本地部署更稳定可靠。 -- Concepts created: 无（RSSHub 已在 overview Key concepts 中） -- Entities created: 无（diygod 仅出现1次，不满足创建条件） -- Source page: wiki/sources/实战笔记-本地部署-rsshub-并获取-youtube-订阅.md -- Notes: - - 新增 1 个 Source Page - - 无新增 Entity/Concept - - 冲突检测：与 "How to Get the RSS Feed For Any YouTube Channel" 的在线 vs 本地方案略有差异，已记录于 Contradictions - -## [2026-04-24] ingest | Mac必装软件清单 -- Source file: Home Office/Mac必装软件清单-2026-04-17.md -- Status: ✅ 成功摄入 -- Summary: 精选8款Mac必备软件——Claude（AI助手）、Obsidian（AI知识库）、Chrome（浏览器）、Rectangle（分屏工具）、iShot（截图录屏）、Lemon（系统清理）、Raycast（启动器）、Homebrew（包管理器）。核心理念：用最少的软件达到最高的效率。Homebrew 是用 Claude Code 搭 Agent 的前置依赖。 -- Concepts created: 无 -- Entities created: 无 -- Source page: wiki/sources/mac必装软件清单-2026-04-17.md -- Notes: - - 新增 1 个 Source Page - - 无新增 Entity/Concept（软件均不满足创建条件） - - 冲突检测：无冲突 - -## [2026-04-18] ingest | fireworks-tech-graph -- Source file: raw/Skills/fireworks-tech-graph.md -- Status: ✅ 成功摄入 -- Summary: fireworks-tech-graph Claude Code Skill，将自然语言描述转化为精美 SVG 技术图，支持 7 种视觉风格和 14 种 UML 图类型，通过 rsvg-convert 导出 1920px PNG。内置语义形状词汇表和语义箭头系统，确保图形语义一致性。安装：npx skills add yizhiyanhua-ai/fireworks-tech-graph，依赖 librsvg。 -- Concepts created: 7种视觉风格系统、14种UML图、语义形状词汇表、语义箭头系统、技术图生成 -- Entities created: fireworks-tech-graph、rsvg-convert -- Source page: wiki/sources/fireworks-tech-graph.md -- Notes: - - 新增 1 个 Source Page - - 新增 5 个 Concept Page（7种视觉风格系统、14种UML图、语义形状词汇表、语义箭头系统、技术图生成） - - 新增 2 个 Entity Page（fireworks-tech-graph、rsvg-convert） - - 更新 wiki/index.md（Sources + Entities + Concepts 章节追加条目） - - 更新 wiki/overview.md（AI Tools & Prompt Engineering 章节追加条目） - - 无内容冲突 - -## [2026-04-18] ingest | Install WSL -- Source file: raw/Home Office/Install WSL.md -- Status: ✅ 成功摄入 -- Summary: 微软官方 WSL 完整安装指南，`wsl --install` 一键安装，支持 Ubuntu/Debian/SUSE/Kali 等多发行版并行安装，`wsl.exe --set-default-version` 切换 WSL1/WSL2；离线场景通过 MSI + DISM 命令手动启用 Virtual Machine Platform；运行入口推荐 Windows Terminal。与 [[WSL2 启动与网络配置指南]] 互补——前者解决安装，后者解决网络。 -- Concepts created: 无新增（WSL2 已存在于 overview.md，WSL1/WSL安装命令/多发行版支持/离线安装 为 WSL 特定术语，无需独立页面） -- Entities created: 无新增（Microsoft/Ubuntu/PowerShell/Windows Terminal 已存在于 overview.md） -- Source page: wiki/sources/install-wsl.md -- Notes: - - 新增 1 个 Source Page（install-wsl.md） - - 更新 wiki/index.md（Sources 章节追加条目） - - 更新 wiki/overview.md（新增 Install WSL 段落于 Home Server Automation 章节） - - 冲突记录：[[WSL2 启动与网络配置指南]] vs [[Install WSL]] — 侧重点差异，均为互补关系，非矛盾 - -## [2026-04-23] ingest | Obsidian 官方 CLI 命令全景速查表 -- Source file: raw/Skills/Obsidian 官方 CLI 命令全景速查表.md -- Status: ✅ 成功摄入 -- Summary: Obsidian v1.12+ 内置官方 CLI 命令行工具的完整速查表，包含 80+ 条命令覆盖 16 个功能模块（基础操作/数据库/书签/命令面板/日记/文件历史/文件目录/链接网络/大纲/插件管理/属性元数据/发布/随机笔记/全局搜索/官方同步/标签/任务管理/模板/外观样式/卡片盒/仓库管理/内置浏览器/字数统计/工作区布局/开发者模式）。文档还包含 7 个典型自动化应用场景工作流（全局极速闪记、播客知识榨取、AI 收件箱自动分拣、绝对隐私本地 RAG 对话助理、跨平台数据库级联录入、历史知识自动唤醒、批量元数据重构清洗）。 -- Concepts created: 无新增（Obsidian CLI / Obsidian Bases / Zettelkasten / 本地 RAG / 工作流自动化 / 元数据管理 / 快速闪记 均已存在于 overview.md） -- Entities created: 无新增（Obsidian / Obsidian CLI / Dataview / QuickAdd / Templater 已存在于 overview.md 或前次摄入） -- Source page: wiki/sources/obsidian-官方-cli-命令全景速查表.md -- Notes: - - 新增 1 个 Source Page - - 更新 wiki/index.md（Sources 章节追加条目） - - 无内容冲突（与 obsidian-必装-skills 和 obsidian-cli 形成互补） - -## [2026-04-23] ingest | Obsidian 必装 Skills -- Source file: raw/Skills/Obsidian 必装 Skills.md -- Status: ✅ 成功摄入 -- Summary: Obsidian 与 AI Agent 集成的必装 Skills 全景图。覆盖五大方向：①kepano 官方 Skills（defuddle 网页清洗、obsidian-cli 官方 CLI、obsidian-bases .base 数据库）；②Axton 可视化 Skills（obsidian-canvas-creator 径向布局算法、mermaid-visualizer、excalidraw-diagram）；③学术研究工具链（tutor-skills 输入-内化-检测学习闭环、scholar-skill L1/L2/L3 分级论文阅读）；④第三方插件（Claudian 适配 Claude Code、obsidian-agent-client 支持多 Agent）；⑤不推荐工具（obsidian-skill 过时、json-canvas 自动化程度低）。 -- Concepts created: Defuddle, Obsidian-CLI, Obsidian-Bases, Canvas, StudyVault, Scholar-Skill, Tutor-Skills, Claudian, Obsidian-Agent-Client -- Entities created: kepano, Axton, YishenTu, RAIT-09, Choi-Wontak, EESJGong -- Source page: wiki/sources/obsidian-必装-skills.md -- Notes: - - 新增 1 个 Source Page - - 新增 9 个 Concept 页面（Defuddle / Obsidian-CLI / Obsidian-Bases / Canvas / StudyVault / Scholar-Skill / Tutor-Skills / Claudian / Obsidian-Agent-Client） - - 新增 6 个 Entity 页面（kepano / Axton / YishenTu / RAIT-09 / Choi-Wontak / EESJGong） - - 更新 wiki/index.md（Sources / Entities / Concepts 三个章节均已追加条目） - - 更新 wiki/overview.md，补充 Obsidian Skills 生态段落 - - 无内容冲突（与已有 Obsidian 相关文档形成互补） - -- Source file: raw/AI/在 Ubuntu 安装 Ollama 并运行 Qwen2.5‑Coder 7B -- Status: ✅ 成功摄入 -- Summary: Ubuntu 系统上通过官方 install.sh 脚本一键部署 Ollama + Qwen2.5-Coder 7B。涵盖系统要求、安装步骤、服务管理、API 暴露（OLLAMA_HOST=0.0.0.0）、GPU 加速（CUDA 自动检测）、Python/Node.js SDK 调用，以及与 Open WebUI/n8n/OpenClaw 的集成方案。推荐搭配工具：Open WebUI（ChatGPT UI）、n8n（AI 自动化）、LangChain（Agent framework）、OpenClaw（AI coding agent）。qwen2.5-coder:7b 比通用版 qwen2.5:7b 更适合工程任务，因其 Tool usage 能力强、Shell/Python/SQL 理解强、Repo 级代码理解强。 -- Concepts created: 无新增（[[Ollama]]/[[本地大模型部署]]/[[GPU 加速推理]]/[[REST API]] 已存在于 overview.md） -- Entities created: 无新增（[[Open WebUI]]/[[n8n]]/[[OpenClaw]] 已存在于 overview.md） -- Source page: wiki/sources/在-ubuntu-安装-ollama-并运行-qwen2-5‑coder-7b.md -- Notes: - - 新增 1 个 Source Page - - 更新 wiki/index.md Sources 节，追加新条目（按日期排序） - - 更新 wiki/overview.md AI Tools 区域，追加 Qwen2.5-Coder 部署实战段落，关联 [[Ollama 本地 LLM 部署]]（DeepSeek-R1）形成 Ollama 部署双场景覆盖 - - 无需新建 Entity/Concept 页面（相关实体和概念已在 overview.md 中定义） - - 检测冲突：无 - -## [2026-04-16] ingest | Learn AI for free directly from top companies -- Source file: raw/AI/Learn AI for free directly from top companies -- Status: ✅ 成功摄入 -- Summary: @RodmanAi 汇总的 10 家顶级科技公司免费 AI 学习资源直链。涵盖：Anthropic（Skilljar）、Google（Grow.google/AI）、Meta（AI 资源中心）、NVIDIA（CUDA 开发者课程）、Microsoft（Microsoft Learn）、OpenAI（Academy）、IBM（SkillsBuild）、AWS（Skill Builder）、DeepLearning.AI（吴恩达课程）、Hugging Face（学习路径）。 -- Concepts created: 无新增 -- Entities created: [[DeepLearning.AI]], [[IBM]] -- Source page: wiki/sources/learn-ai-for-free-directly-from-top-companies.md -- Notes: - - 新增 1 个 Source Page（wiki/sources/learn-ai-for-free-directly-from-top-companies.md） - - 新增 2 个 Entity 页面：wiki/entities/DeepLearningAI.md, wiki/entities/IBM.md - - 更新 wiki/overview.md Educational Resources 区域，追加免费 AI 学习资源全景介绍 - -## [2026-04-23] ingest | I Went Through Every AI Memory Tool I Could Find. There Are Two Camps. -- Source file: raw/Agent/AI-Memory-Tools-Two-Camps.md -- Status: ✅ 成功摄入 -- Summary: AI 记忆工具全景分类框架。揭示两个根本不同的技术路线：Camp 1（Memory Backend，向量提取+检索，优化召回）vs Camp 2（Context Substrate，文件累积+背景整合，优化复合增长）。代表工具：Mem0、MemPalace（Camp 1）；OpenClaw、Zep、Thoth、TrustGraph（Camp 2）。核心洞察：Zep 从"memory"重塑为"context engineering"是最强市场信号；预测 6 个月内"context engineering"将取代"memory"成为主流术语；持续运行 Agent 必须采用 Context Substrate 架构。 -- Concepts created: [[Context Substrate]], [[Memory Backend]] -- Entities created: [[OpenClaw]], [[Mem0]] -- Source page: wiki/sources/ai-memory-tools-two-camps.md -- Notes: - - 新增 1 个 Source Page（wiki/sources/ai-memory-tools-two-camps.md） - - 新增 2 个 Concept 页面：wiki/concepts/Context-Substrate.md, wiki/concepts/Memory-Backend.md - - 新增 2 个 Entity 页面：wiki/entities/OpenClaw.md, wiki/entities/Mem0.md - - overview.md 新增 ai-memory-tools-two-camps 摘要条目，置于 semantic-memory-search 之后 - - index.md Sources 节新增条目（置顶） - - 冲突记录：与 semantic-memory-search 存在文件优先 vs 向量优先的表面张力，实际互补（已记录） - -## [2026-04-23] ingest | 可自动化、可扩展、AI增强的电商数据采集与处理系统 -- Source file: raw/Others/可自动化、可扩展、AI增强的电商数据采集与处理系统.md -- Status: ✅ 成功摄入 -- Summary: 基于 Docker + Ubuntu + n8n 的可自动化、可扩展、AI增强的电商数据采集与处理系统设计方案。三层架构：爬虫层（Scrapy/Playwright）→ AI处理层（n8n + LLM API）→ 存储展示层（PostgreSQL/MinIO + Grafana）。推荐 Scrapy + Playwright 组合，Docker Compose 容器化；n8n 工作流实现定时爬取→LLM处理→数据库写入→报表通知的全链路自动化；本地可使用 Ollama 无需外部 API Key；防封策略包括 User-Agent 轮换和代理池。 -- Concepts touched: [[Scrapy]], [[Playwright]], [[n8n]], [[Docker Compose]], [[Ollama]], [[Bright Data]], [[Scrapyd]], [[MinIO]], [[Grafana]], [[Metabase]], [[FastAPI]], [[LangChain]] -- Entities touched: [[Amazon]], [[JD]], [[Taobao]], [[Shopee]] -- Source page: wiki/sources/可自动化-可扩展-ai增强的电商数据采集与处理系统.md -- Notes: - - 新增 1 个 Source Page（wiki/sources/可自动化-可扩展-ai增强的电商数据采集与处理系统.md） - - Concept 和 Entity 均以 wikilink 形式建立关联，暂不创建独立页面（已存在于 Wiki） - - 冲突检测：无已知冲突，与 [[scrapy-playwright-抓取tiktok-shop-data]] 同属电商数据采集技术栈 - - 已在 index.md 添加 Source 条目 - - 已在 overview.md TikTok E-commerce Operations 部分新增条目 - -## [2026-04-26] ingest | 电商视频Prompt库 -- Source file: 跨境电商/电商视频Prompt.md -- Status: ✅ 成功摄入 -- Summary: AI 生成宠物电商视频的 7 模块 Prompt 库（产品展示/宠物动作/衣服防穿帮/场景变化/Negative Prompt/卖货文案/全流程示例），以"拼积木"组合方式实现低翻车率 + 高真实感的 TikTok Shop 带货视频生成，扩展至 1产品→3视频→6文案→A/B 测试全链路自动化。 -- Concepts touched: [[Prompt库设计原则]], [[Negative Prompt]], [[Image-to-Video]], [[TikTok电商内容自动化]], [[AI图生视频]] -- Entities touched: [[TikTok Shop]], [[宠物用品]], [[TikTok]] -- Source page: wiki/sources/电商视频prompt.md -- Notes: - - 新增 1 个 Source Page（wiki/sources/电商视频prompt.md） - - Concept 和 Entity 均以 wikilink 形式建立关联，暂不创建独立页面（出现次数 < 2 次阈值） - - 冲突检测：无已知冲突，与 [[AI图生视频工具盘点]]（工具盘点）和 [[做TK跨境思路不对努力白费]]（运营策略）互补 - - 已在 index.md 添加 Source 条目 - - 已在 overview.md 新增 [[电商视频Prompt库]] 小节，链接于 AI图生视频工具盘点 之后 - -## [2026-04-26] ingest | TikTok Shop - Apache Superset Dashboard设计思路 -- Source file: 跨境电商/TikTok Shop - Apache Superset Dashboard设计思路.md -- Status: ✅ 成功摄入 -- Summary: Apache Superset 在 TikTok Shop 电商选品分析场景的完整 Dashboard 设计方案——基于 products/reviews/variations 三表数据，通过 SQL View 预处理 JSON 字段，设计 4-Tab 专业 Dashboard（爆品雷达/类目洞察/店铺监控/评论分析），包含 KPI 卡/散点图/箱线图/热力图等可视化组件，提供选品评分加权公式（sold×0.4 + rating×15 + discount×0.5 + rating_count×0.2）。 -- Concepts created: [[Apache Superset]], [[KPI Card]], [[选品评分公式]], [[SQL View]], [[Dynamic Filter]], [[GMV]], [[Scatter Plot]], [[Box Plot]], [[Heatmap]] -- Entities created: [[TikTok Shop]], [[tiktok_products 数据库]], [[products 表]], [[product_reviews 表]], [[product_variations 表]] -- Source page: wiki/sources/tiktok-shop-apache-superset-dashboard设计思路.md -- Notes: - - 新增 1 个 Source Page（wiki/sources/tiktok-shop-apache-superset-dashboard设计思路.md） - - Concept 和 Entity 均以 wikilink 形式建立关联，暂不创建独立页面（各仅出现 1 次，未达 ≥2 次阈值） - - 冲突检测：无实质冲突，与 [[电商如何选品-如何找到爆款-选品策略]] 互补（策略 vs 数据工具） - - 已在 index.md 添加 Source 条目 - - overview.md 已在 "TikTok E-commerce Product Management" 小节提及 Apache Superset 与 Dashboard 集成，无需额外更新 - -## [2026-04-18] ingest | 做TK跨境思路不对努力白费 -- Source file: 跨境电商/做TK跨境思路不对努力白费.md -- Status: ✅ 成功摄入 -- Summary: TikTok跨境电商全流程实战指南——从市场选择(美区/日本>东南亚)→账号准备→选品策略(数据软件+垂直类目)→店铺运营(流量监控+商品优化)→流量获取(短视频+达人营销)→仓储物流(海外仓+海运补货)→团队建设，提供完整执行框架。 -- Concepts touched: [[跨境电商]], [[选品策略]], [[TikTok电商]], [[达人营销]] -- Entities touched: [[TikTok Shop]], [[美区]], [[日本]] -- Source page: wiki/sources/做tk跨境思路不对努力白费.md -- Notes: - - 新增 1 个 Source Page（wiki/sources/做tk跨境思路不对努力白费.md） - - Concept 和 Entity 均以 wikilink 形式建立关联，暂不创建独立页面（出现次数<2次阈值） - - 冲突检测：无已知冲突内容 - - 已在 index.md 添加 Source 条目 - - 已在 overview.md 新增 "TikTok E-commerce Operations" 小节 - -## [2026-04-23] ingest | 超达物流定价 -- Source file: 跨境电商/超达物流定价.md -- Status: ✅ 成功摄入 -- Summary: 超达物流跨境电商定价规则：申报/实重/材积取最大值计费，UIN渠道24-48h轨迹推送，TK平台面单"TKM"开头单号无效，UIN/TK取消单号收费规则，发货截止时间12点/美区周日休息。 -- Concepts touched: [[计费重量原则]], [[轨迹推送机制]], [[取消单号收费]] -- Source page: wiki/sources/超达物流定价.md -- Notes: - - 新增 1 个 Source Page（wiki/sources/超达物流定价.md） - - Entity 和 Concept 均以 wikilink 形式建立关联，暂不创建独立页面（各仅出现 1 次，未达 ≥2 次阈值） - - 冲突检测：无实质冲突，与 [[TK美国面单授权及操作流程]] 互为补充（前者专注授权配置，本文专注计费规则） - - 已在 index.md 添加 Source 条目 - - overview.md 无需更新（物流定价内容与 AI/软件主题 overview 相关性低） - -## [2026-04-25] ingest | TK美国面单授权及操作流程 -- Source file: 跨境电商/TK美国面单授权及操作流程.md -- Status: ✅ 成功摄入 -- Summary: TikTok美国市场面单授权配置与操作流程截图教程，通过6张Zipline图床备份图片展示具体操作步骤。 -- Concepts touched: [[TikTokShop]], [[面单授权]], [[跨境电商物流]] -- Entities touched: [[TikTok美国站]] -- Source page: wiki/sources/tk美国面单授权及操作流程.md -- Notes: - - 新增 1 个 Source Page（wiki/sources/tk美国面单授权及操作流程.md） - - Concept 和 Entity 均以 wikilink 形式建立关联，暂不创建独立页面（内容为截图教程，信息量有限） - - 冲突检测：无已知冲突内容 - - 已在 index.md 修正 Source 条目 - - overview.md 无需更新（物流操作类内容与 overview 主题相关性低） - -## [2026-04-24] ingest | Scrapy + Playwright 抓取TikTok Shop Data -- Source file: 跨境电商/Scrapy + Playwright 抓取TikTok Shop Data.md -- Status: ✅ 成功摄入 -- Summary: 使用 Scrapy + Playwright 技术栈抓取 TikTok Shop 商家数据的环境配置与运行指南。涵盖 Python venv 虚拟环境搭建、scrapy-playwright 依赖安装、Chromium 浏览器安装、Docker 容器化部署配置，以及 Playwright 验证方法。 -- Concepts touched: [[Scrapy]], [[Playwright]], [[scrapy-playwright]], [[venv]], [[Docker]], [[Chromium]] -- Entities touched: [[TikTok Shop]], [[shenwei]] -- Source page: wiki/sources/scrapy-playwright-抓取tiktok-shop-data.md -- Notes: - - 新增 1 个 Source Page（wiki/sources/scrapy-playwright-抓取tiktok-shop-data.md） - - Concept 和 Entity 均以 wikilink 形式建立关联，暂不创建独立页面（各仅出现 1 次，未达 ≥2 次阈值） - - 冲突检测：无已知冲突内容 - - 已在 index.md 添加 Source 条目 - - overview.md 无需更新（TikTok Shop 已存在于 Key Entities，Scrapy/Playwright 属技术工具不需独立概念页） - -## [2026-04-23] ingest | GOG CLI 安装配置指南 -- Source file: Skills/GOG-CLI-安装配置指南.md -- Status: ✅ 成功摄入 -- Summary: gog CLI（Google Workspace 命令行工具）在 macOS 系统上的完整安装与配置流程。涵盖 Homebrew 安装、OAuth 凭证配置、测试用户白名单添加、Google API 启用、常用命令速查及故障排除。 -- Concepts touched: [[OAuth 2.0]], [[Google Cloud Console]], [[API Enablement]], [[Google Workspace]] -- Entities touched: [[gog CLI]] -- Source page: wiki/sources/gog-cli-安装配置指南.md -- Notes: - - 新增 1 个 Source Page（wiki/sources/gog-cli-安装配置指南.md） - - 新增 1 个 Entity Page（wiki/entities/gog-CLI.md） - - 冲突检测：无已知冲突内容 - - 已在 index.md 修正 Source 条目（去除 "(expected: source missing)" 标注） - - 已在 overview.md Key Entities 添加 [[gog CLI]] 条目 - - 已在 overview.md Key Concepts 添加 [[OAuth 2.0]], [[Google Cloud Console]], [[API Enablement]] - - -- Source file: Skills/Last30Days-使用指南.md -- Status: ✅ 成功摄入 -- Summary: Last30Days 方法论——通过 AI Agent 自动化追踪近30天内新增/更新的内容源，避免信息过载。核心价值：将"主动订阅"转变为"被动接收"，用 AI 替代人工巡检，节省 80% 信息搜集时间。 -- Concepts touched: [[Last 30 Days Method]], [[信息消费习惯]] -- Entities touched: [[Last30Days]] -- Source page: wiki/sources/last30days-使用指南.md -- Notes: - - 新增 1 个 Source Page - - Concept 和 Entity 均以 wikilink 形式建立关联，暂不创建独立页面 - - 冲突检测：无已知冲突内容 - - 已在 index.md 添加 Source 条目 - - overview.md 无需更新（Last 30 Days Method 已存在于 Key Concepts） - -## [2026-04-25] ingest | 如何利用Sora接口实现视频自动化生成工作流 -- Source file: AI/如何利用Sora接口实现视频自动化生成工作流.md -- Status: ✅ 成功摄入 -- Summary: 利用亚马逊 Bedrock 平台的 Sora API 实现视频生成全自动化工作流，覆盖注册→API调用→批量生成完整流程。成本仅 2-3 元人民币，远低于市场水平；新用户享 200 美元抵扣金和 6 个月免费试用；支持文本转视频和图像生成，可结合 n8n 实现批量 UGC 内容生产。 -- Concepts touched: [[文字生成视频]], [[提示词优化]], [[肖像权合规]], [[n8n 工作流自动化]], [[UGC内容]] -- Entities touched: [[Sora]], [[亚马逊 Bedrock]], [[n8n]] -- Source page: wiki/sources/如何利用sora接口实现视频自动化生成工作流.md -- Notes: - - 新增 1 个 Source Page - - Concept 和 Entity 均已在 Source Page 中以 wikilink 形式建立关联，暂不创建独立页面（各出现 1 次，未达 ≥2 次阈值） - - 冲突检测：无已知冲突内容 - - 已在 index.md 添加 Source 条目 - -## [2026-04-25] ingest | If You Have Multiple Interests, Do Not Waste the Next 2-3 Years -- Source file: AI/If you have multiple interests, do not waste the next 2-3 years 如果你有多项兴趣爱好，不要浪费接下来的两三年时间。.md -- Status: ✅ 成功摄入 -- Summary: 系统论证多重兴趣是AI时代超能力的个人发展指南——核心主张：工业化专业化分工使人类沦为"愚蠢而依赖"的螺丝钉，第二次文艺复兴已经到来；个人成功三要素（自学+自利+自立）自然涌现通才型人才；品牌内容系统、创意密度方法论、系统经济是具体路径 -- Concepts created: [[Generalist]], [[Self-Education]], [[Self-Interest]], [[Self-Sufficiency]], [[Second-Renaissance]], [[Idea-Density]], [[Idea-Museum]], [[Brand-Environment]], [[Content-Creator]], [[System-Economy]], [[Attention-Economy]] -- Entities created: [[AdamSmith]], [[LeonardoDaVinci]] -- Source page: wiki/sources/if-you-have-multiple-interests-do-not-waste-the-next-2-3-years-如果你有多项兴趣爱好-不要浪费接下来的两三年时间.md -- Notes: - - 新增 1 个 Source Page、5 个 Concept 页面、2 个 Entity 页面 - - Concepts 全部符合"可抽象可复用"原则，创建独立页面 - - Entities: Adam Smith（≥2次引用分工理论）、Leonardo da Vinci（文艺复兴通才典范）均符合创建条件 - - 冲突检测：与 [[Multi-Agent System Reliability]] 的 Generalist 概念高度互补（后者从系统可靠性角度） - - 已在 overview.md 个人品牌与一人公司段落添加新来源摘要 - - 已在 index.md 添加 11 个 Concept 条目、2 个 Entity 条目 - -## [2026-04-25] ingest | 我用 Gemini 3 一口气做了 10 个应用，附教程 -- Source file: AI/我用 Gemini 3 一口气做了 10 个应用，附教程.md -- Status: ✅ 成功摄入 -- Summary: 使用 Google Gemini 3 模型通过三步方法论（限定垂直场景→提示词约束结构化输出→前端SVG容器）快速构建 10 个可视化应用。核心发现：AI 生成 SVG 代码+前端渲染是快速交付 AI 应用的关键路径。 -- Concepts touched: [[SVG可视化]], [[结构化输出]], [[Vibe-Coding]], [[AI应用开发]] -- Entities touched: [[Gemini-3]]（出现1次，不满足≥2次条件，暂不创建独立Entity页） -- Source page: wiki/sources/我用-gemini-3-一口气做了-10-个应用-附教程.md -- Notes: - - 新增 1 个 Source Page - - 已在 overview.md 添加 Gemini 3 十应用实战 段落，连接到 [[Vibe-Coding]] - - 已更新 index.md 条目（日期从 2026-04-18 更新为 2026-04-23） - - Entity 检查：Gemini-3 仅在本文出现，未达"出现≥2次"阈值，暂不创建独立页面 - - Concept 检查：SVG可视化/结构化输出等均未达"可抽象可复用"独立成页条件，暂纳入 Source Page Key Concepts - - 冲突检测：无冲突内容 - -## [2026-04-25] ingest | Multi-Agent System Reliability -- Source file: AI/Multi-Agent System Reliability.md -- Status: ✅ 成功摄入 -- Summary: 介绍4种提升多智能体系统可靠性的架构模式（Hierarchy/Consensus/Adversarial Debate/Knock-out），核心主张：停止拟人化LLM，将其视为分布式系统中不可靠的组件，通过架构约束而非提示词约束强制正确性 -- Concepts created: [[Hierarchy-Agent-Pattern]], [[Consensus-Voting-Pattern]], [[Adversarial-Debate-Pattern]], [[Knock-out-Pattern]], [[Tree-of-Thoughts]], [[Genetic-Algorithm]], [[Reliability-Engineering]] -- Entities created: [[Alex Ewerlöf]] -- Entities updated: 无（Alex Ewerlöf 为新实体） -- Source page: wiki/sources/multi-agent-system-reliability.md -- Notes: - - 新增 1 个 Source Page、1 个 Entity 页面、7 个 Concept 页面 - - Alex Ewerlöf Entity 在源文件中出现 ≥2 次（作者署名+引用），符合创建条件 - - 7 个 Concept 均符合"可抽象、可复用"原则，全部创建独立页面 - - 冲突检测：与 [[Designing for Agentic AI]] 互补而非冲突；与 [[Recursive Self-Optimization]] 共享自引用结构思想；与 [[Genetic-Algorithm]] 有明确关联（Knock-out 是 GA 的精简实现） - - 已在 overview.md Key Concepts 列表添加所有 7 个新概念 - - 已在 overview.md Key Entities 列表添加 [[Alex Ewerlöf]] - -## [2026-04-24] ingest | 全网最全！Nano Banana 2 使用指南（2025年12月更新） -- Source file: AI/全网最全！Nano Banana 2 使用指南（2025年12月更新） 1.md -- Status: ✅ 成功摄入 -- Summary: 介绍 Google Nano Banana 2（Gemini 3 Pro Image）推理型图像生成模型的国内使用方法，通过 DeepSider 浏览器插件实现无 VPN 直连访问，同时支持数十款 AI 大模型 -- Concepts created: 无（本次概念不足以独立建页） -- Entities created: [[DeepSider]], [[Nano Banana 2]] -- Entities updated: [[Google]]（新增 Nano Banana 2 产品信息） -- Source page: wiki/sources/全网最全-nano-banana-2-使用指南-2025年12月更新-1.md -- Notes: - - Nano Banana 2 与 [[Nano Banana Pro]] 为不同版本，Nano Banana 2 为更新版（2025年12月发布） - - [[Nano Banana Pro]] 已在 [[Google.md]] entity 中提及，本次新增 [[Nano Banana 2.md]] entity 独立页面 - -## [2026-04-24] ingest | 2025 年 11 个神级 AI 开源平替，GitHub 杀疯了 -- Source file: AI/2025 年 11 个神级 AI 开源平替，GitHub 杀疯了。.md -- Status: ✅ 成功摄入 -- Summary: 按 8 大领域（LLM/AI生图/生视频/AI智能体/AI编码/工作流/AI搜索/AI知识库）系统盘点 GitHub 上各领域最火的开源平替项目，核心洞察：国产开源模型在多领域达到或超越国际闭源竞品水平 -- Concepts created: [[AI开源平替]] -- Entities created: [[Flux]], [[HunyuanVideo]], [[Manus]], [[OpenManus]], [[Cline]], [[Perplexica]], [[Dify]], [[Stable Diffusion]] -- Entities updated: [[DeepSeek]], [[Qwen]], [[n8n]] -- Source page: wiki/sources/2025-年-11-个神级-ai-开源平替-github-杀疯了.md -- Notes: - - DeepSeek、Qwen、n8n 已在 Wiki 中存在，本次仅追加新版本信息 - - Flux（≥2次）、HunyuanVideo（≥2次）、Manus（≥2次）、OpenManus（≥2次）、Cline（≥2次）、Perplexica（≥2次）、Dify（≥2次）、Stable Diffusion（≥2次）均出现 ≥2 次，符合创建条件 - - OpenAI、MiniMax、Kimi K2、智谱 GLM 仅出现 1 次，未达到创建阈值 - - Perplexity 作为对比对象出现，但非本文主角，不创建独立页面 - - 冲突检测：内容与现有 Wiki 中 DeepSeek、n8n 等实体描述一致，无冲突 - - Meta 收购 Manus 是 2025 年重大事件，已体现在 [[Manus]] 实体页 - -## [2026-04-23] ingest | AI 解决方案专家培训课程 -- Source file: AI/AI 解决方案专家培训课程.md -- Status: ✅ 成功摄入 -- Summary: Coze 平台多行业 AI Agent 培训课程，涵盖国内版（coze.cn）和海外版（coze.com），提供覆盖金融、医疗、教育、电商、人力资源、泛娱乐、在线客服等 7 大行业共 50+ 可体验 Agent Demo，核心技术栈为 Prompt 工程、RAG、Function Call 和 Workflow 编排。 -- Concepts created: [[Coze-Workflow]] -- Entities created: [[Coze]], [[SONY]], [[滴滴]] -- Source page: wiki/sources/ai-解决方案专家培训课程.md -- Notes: - - Coze、SONY、滴滴三个实体在源文件中均出现 ≥2 次，符合创建条件 - - FaceFusion、F5-TTS、World Labs、抖音仅出现 1 次，未达到创建阈值（≥2次） - - Prompt Engineering、Function Call、Workflow Engineering 等核心概念已存在于 Wiki，本次作为 Key Concepts 引用 - - 冲突检测：Coze 平台与其他 AI 工具（Claude Code、Ollama 本地部署）属互补关系，无内容冲突 - -- Source file: AI/RAG从入门到精通系列1：基础RAG.md -- Status: ✅ 成功摄入 -- Summary: RAG 基础原理与实战：Indexing（文档加载→切分→向量化入库）→ Retrieval（向量相似度 Top-k 检索）→ Generation（问题+上下文→LLM 生成答案），Qwen+BAAI+LangChain+Qdrant 实战工具链。 -- Concepts created: [[Indexing]], [[Retrieval]], [[Generation]], [[Split]], [[Context-Window]] -- Entities created: [[LangChain]], [[Qwen]], [[Qdrant]] -- Source page: wiki/sources/rag从入门到精通系列1-基础rag.md -- Notes: - - RAG 概念页面 [[RAG]] 已存在于 wiki/concepts/RAG.md，已在 Source Page 中正确引用 - - 冲突检测：基础 RAG（Naive RAG）与 Advanced RAG / RAG Fusion 存在优化方向差异，待后续进阶内容补充后更新 Contradictions - - [[PyTorch研习社]] 为文章来源方，raw 文档中有注明，Source Page Key Entities 已记录 - - BAAI（Embedding Model）和 LlamaIndex 在 Source Page 中作为 Key Entities 记录，暂未创建独立 Entity 页面 - -## [2026-04-23] ingest | 固定镜头短视频制作的AI全流程解析 -- Source file: AI/固定镜头短视频制作的AI全流程解析.md -- Status: ✅ 成功摄入 -- Summary: 利用 AI 技术快速制作高播放量固定机位家装类短视频的全流程方法论，涵盖分镜拆解（Google AI Studio）、九宫格图像生成（Midjourney/Nano Banana）、首尾针动画（海螺AI/KAI）、快节奏剪辑（剪映）、声音设计五大步骤，10 分钟内完成成片。 -- Concepts created: [[固定机位]], [[首尾针动画]], [[九宫格法]] -- Entities created: [[Midjourney]], [[KAI]], [[剪映]] -- Source page: wiki/sources/固定镜头短视频制作的ai全流程解析.md -- Notes: - - 冲突检测：与传统视频制作理念（复杂镜头语言+丰富转场）存在冲突，已记录至 Source Page Contradictions 部分 - - Google/Nano Banana 实体已存在于 wiki/entities/Google.md，已在 Source Page Key Entities 中正确引用 - - 海螺AI 仅为提及（非关键工具），未创建独立 Entity 页面 - - 快节奏剪辑、卡点、内容连续变化、时间压缩等为描述性术语，不满足"可抽象可复用"原则，未创建独立 Concept - -## [2026-04-25] ingest | 大模型相关术语和框架总结｜LLM、MCP、Prompt、RAG、vLLM、Token、数据蒸馏 -- Source file: AI/大模型相关术语和框架总结｜LLM、MCP、Prompt、RAG、vLLM、Token、数据蒸馏.md -- Status: ✅ 成功摄入 -- Summary: 大模型生态核心术语入门速查手册，涵盖 LLM、Prompt、MCP、Agent、RAG、Embedding、LangChain、vLLM、Token、数据蒸馏等概念，用通俗语言和可视化类比解释大模型领域关键术语 -- Concepts created: [[Model Context Protocol]], [[vLLM]], [[LangChain]] -- Concepts updated: [[Large Language Model]]（添加来源引用）, [[AI Agent]]（添加 Model Context Protocol 关联 + 来源引用）, [[RAG]]（已包含来源） -- Entities identified: 无（shenwei 仅在本文出现 1 次，不满足 ≥2 次条件；OpenAI/vLLM 社区仅为引用来源，不满足关键影响条件） -- Source page: wiki/sources/大模型相关术语和框架总结｜llm-mcp-prompt-rag-vllm-token-数据蒸馏.md -- Notes: - - 冲突检测：与 [[llms-rag-ai-agent-三个到底什么区别]] 属互补关系（术语科普 vs 三层架构梳理），已记录至 Source Page Contradictions 部分 - - 无需创建 shenwei Entity（仅出现 1 次，不满足 ≥2 次条件） - - vLLM.md 中 KV Cache/PagedAttention/Continuous Batching 等子概念不单独创建页面，因其属于 vLLM 框架的内部技术细节，不满足"可抽象、可复用"原则 - - Embedding 已存在 [[Vector-Embedding]] Concept，LangChain 为框架类概念（已有充分讨论） - -## [2026-04-25] ingest | Nano Banana Pro 提示词指南与策略（上篇） -- Source file: AI/Nano-Banana Pro Prompting Guide & Strategies 1.md -- Status: ✅ 成功摄入 -- Summary: Google Nano Banana Pro 官方提示词指南上篇，涵盖 10 条黄金法则（编辑而非重生成、使用自然语言、提供上下文等）和前 9 个能力域（文本渲染/信息图、角色一致性/身份锁定、Google Search 信息锚定、高级编辑/修复/着色、2D/3D 维度转换、高分辨率/纹理、思考推理模式、故事板/概念艺术、结构控制/布局引导），附大量可直接复制的实战提示词模板。 -- Concepts identified: 无（Nano Banana Pro 特有概念均为具体应用技术，不满足可复用抽象原则） -- Entities identified: [[Google]]（已存在于 wiki/entities/Google.md，已更新 Key Products 添加 Google AI Studio / Nano Banana Pro / Google Colab） -- Source page: wiki/sources/nano-banana-pro-prompting-guide-strategies-1.md -- Notes: - - index.md 已修复旧条目（移除 expected/missing 标注，替换为完整标题和摘要） - - overview.md 已更新「Nano Banana Pro 提示词指南」段落，明确标注本文为上篇及涵盖的 9 个能力域 - - 冲突检测：与 [[全网最全-nano-banana-2-使用指南-2025年12月更新-1]] 存在范围重叠，已记录至 Source Page Contradictions 部分，结论为互补而非冲突 - - 无需新建 Entity 页面（shenwei 作者仅在本文出现 1 次，不满足 ≥2 次条件） - - 无需新建 Concept 页面（身份锁定/对话式编辑等为 Nano Banana Pro 特有应用技术，不满足可复用抽象条件） - -- Source file: AI/我的工具集.md -- Status: ✅ 成功摄入 -- Summary: 个人 AI 工具推荐清单，按类型分类（Text-to-Speech / Image-Editor / Image-to-Video / Web-Scraper / AI-Summary），覆盖 Google AI Studio（Wavespeed 图生视频、Vidu、海螺 AI）、Brightdata（网页爬取）、Decopy（AI 摘要）等服务。与 AI图生视频工具盘点属互补关系——本文为工具索引，后者为免费工具详细评测。 -- Concepts identified: 无（工具索引类来源，各概念已在其他来源中有充分讨论） -- Entities identified: [[Google]]（已存在于 wiki/entities/Google.md） -- Source page: wiki/sources/我的工具集.md -- Notes: - - 更新 index.md Sources 部分（替换 expected 标记行） - - 更新 overview.md AI Tools & Prompt Engineering 部分（新增「我的工具集」段落） - - Google Entity 已存在，无需重复创建 - - Vidu/海螺AI/Wavespeed/Brightdata/Decopy 仅在本文中出现 1 次，不满足 Entity ≥2 次创建条件 - - 无需新建 Concept 页面（各工具类型概念在其他来源中已充分覆盖） - - 冲突检测：与 [[二创视频必不可少-2025年最热门ai工具推荐合集-ai配音-声音克隆]] 存在互补关系（工具清单 vs 详细评测），已记录至 Source Page Contradictions 部分 - -## [2026-04-24] ingest | 如何写出完美的Prompt（提示词）？ -- Source file: AI/如何写出完美的Prompt（提示词）？.md -- Status: ✅ 成功摄入 -- Summary: 系统阐述 Prompt 构建底层逻辑的职场应用指南。核心理念：Prompt 是人与 AI 的协作协议，本质是将模糊需求转化为 AI 可执行的结构化任务。四大构建要素（角色+需求+场景+目标）+ 三层技巧体系（基础：需求拆解/上下文补全/格式定义/示例引导；进阶：思维链/任务拆分/角色赋能/预填回复/不确定性管理；高阶：跨模态联动/领域知识注入/反馈循环嵌入）+ 四大业务场景实战模板（内容创作/数据分析/方案策划/客户服务）+ 六大避坑指南。核心洞察：Prompt 能力本质 = 对问题清晰界定的能力 + 结构化思维逻辑和表达能力。 -- Concepts identified: [[结构化思维]], [[精准表达]], [[思维链引导]], [[任务拆分法]], [[角色赋能法]], [[少量样本提示]], [[上下文补全]], [[AI Agent]]（本篇提供了 AI Agent 能力的底层基础） -- Entities identified: [[粒粒]]（微信公众号作者） -- Source page: wiki/sources/如何写出完美的prompt-提示词.md -- Notes: - - 该文档与 [[清华出的DeepSeek使用手册]]（DeepSeek 特定实践）和 [[系统提示词构建原则]]（Agent 系统级指令）互补，构成完整的提示词工程方法论体系 - - 冲突检测：与 [[系统提示词构建原则]] 存在视角差异（用户层 vs Agent 设计层），已在 Source 页面的 Contradictions 部分说明互补关系 - - index.md 已修复旧条目（移除 "— (expected: ... — source missing)" 标注，添加实际摘要） - - overview.md 已新增 "AI Tools & Prompt Engineering" 部分的条目 - -## [2026-04-24] ingest | 系统提示词构建原则 -- Source file: AI/系统提示词构建原则.md -- Status: ✅ 成功摄入 -- Summary: AI 编程助手的系统提示词构建原则，涵盖五大维度：核心身份与行为准则（遵守项目约定、优先技术准确性）、沟通与互动规范（专业简洁、减少冗余）、任务执行工作流（TODO规划、Search/Replace编辑）、技术编码规范（清晰命名、模块化）、安全防护准则（不泄露指令、输入验证）。来源：vibe-coding-cn 项目。 -- Concepts updated: [[Vibe Coding]]（sources 字段补充该来源） -- Entities updated: [[tukuai]]（sources 字段补充该来源） -- Source page: wiki/sources/系统提示词构建原则.md -- Notes: - - 该文档与 [[github-上-5000-人收藏的-vibe-coding-神级指南]] 同属 vibe-coding-cn 项目，是操作层指南的补充 - - 冲突检测：无已知冲突 - - overview.md 中"Vibe Coding 中文指南"段落已补充与该来源的链接 - -## [2026-04-24] ingest | GitHub 上 5000 人收藏的 Vibe Coding 神级指南 -- Source file: AI/GitHub 上 5000 人收藏的 Vibe Coding 神级指南。.md -- Status: ✅ 成功摄入 -- Summary: 介绍 vibe-coding-cn 开源项目（github.com/tukuaiai/vibe-coding-cn），为中文开发者汇集全球顶尖 AI 编程资源。核心公式：Vibe Coding = 规划驱动 + 上下文固定 + AI 结对执行。工具推荐：Cursor + Claude Opus。核心理念：规划就是一切——让 AI 写代码前必须先完成技术选型、实施规划和模块化设计。Karpathy 经典语录："我几乎不写代码了，我只负责调整氛围（Vibe），代码会自动长出来。" -- Concepts updated: [[Vibe Coding]]（补充规划驱动/上下文固定/AI 结对执行三大原则、Vibe Coding vs Claude Skills 对比表、添加 Windsurf/Trae 工具推荐） -- Entities created: [[Andrej-Karpathy]]（AI 领域知名专家，Vibe Coding 概念推广者） -- Entities updated: [[tukuai]]（补充 vibe-coding-cn 仓库贡献者身份） -- Source page: wiki/sources/github-上-5000-人收藏的-vibe-coding-神级指南.md -- Notes: - - 更新 index.md Sources 部分（在首位插入新条目，移除 expected 占位条目） - - 更新 overview.md，添加"Vibe Coding 中文指南"段落至 AI Tools & Prompt Engineering 部分 - - 更新 index.md Entities 部分（添加 Andrej-Karpathy 条目） - - Vibe Coding 概念页面已存在，本次更新 sources 字段和核心原则内容 - - 冲突检测：Vibe Coding（氛围感/直觉式）与 Claude Skills（结构化 SOP）存在视角差异，已记录至 source page Contradictions 部分 - -## [2025-12-18] ingest | 不会Gemini的产品经理真的要被淘汰了 | 附保姆级PRD生成指南 -- Source file: AI/不会Gemini的产品经理真的要被淘汰了 附保姆级PRD生成指南.md -- Status: ✅ 成功摄入 -- Summary: 产品经理Kira2red分享大模型（Gemini）辅助PRD生成的保姆级教程——三步工作流：①用FeatureList构思需求框架（大模型生成层级式功能表）、②Mermaid画逻辑图（ER图/时序图/泳道图辅助理解）、③分页面逐一描述生成PRD+HTML原型。核心方法论："人负责想，大模型负责写"，可缩短文档工作时间90%以上。深层洞察：未来可能不需要PRD文档，产品经理需进化为"超级个体"，核心能力是市场洞察而非写文档。 -- Concepts created: [[FeatureList]], [[超级个体]], [[PRD生成工作流]] -- Entities updated: [[Gemini]]（关联本文工作流） -- Source page: wiki/sources/不会gemini的产品经理真的要被淘汰了-附保姆级prd生成指南.md -- Notes: - - 更新 index.md Sources 部分（在首位插入新条目） - - 更新 overview.md AI Tools & Prompt Engineering 小节（补充AI辅助PRD生成条目） - - Vibe Coding Concept 已存在（无需新建） - - FeatureList、超级个体、PRD生成工作流为新创建 Concept - - 无内容冲突 - -## [2026-04-23] ingest | 3.2 万人收藏的 Claude Skills，才是 AI 这条路上最值得研究的一套范式！ -- Source file: AI/3.2 万人收藏的 Claude Skills，才是 AI 这条路上最值得研究的一套范式！ 1.md -- Status: ✅ 成功摄入 -- Summary: Anthropic 官方 Claude Skills 仓库（github.com/anthropics/skills，3.2 万收藏）介绍。Skills = 写给 Claude 的"说明书" + "SOP"，将反复执行的有固定流程的任务拆解为 AI 能理解、能复用、能自动执行的一套流程。官方库包含三大类：办公自动化（Word/PDF/PPT/Excel）、开发者工具箱（MCP Server/自动化测试/Artifacts 构建）、创意类 Skill。核心洞察：Claude Skills 的爆发标志着从「提示词工程」向「流程工程」的范式转变；Vibe Coding 的尽头也是 Skills。 -- Concepts created: [[Claude Skills]], [[Workflow Engineering]] -- Source page: wiki/sources/3-2-万人收藏的-claude-skills-才是-ai-这条路上最值得研究的一套范式-1.md -- Notes: - - 更新 index.md Sources 部分（修正 source missing 条目） - - 更新 overview.md AI Tools & Prompt Engineering 小节（添加 Claude Skills 范式洞察） - - 创建 Claude-Skills 和 Workflow-Engineering 两个 Concept 页面 - - 添加 Concepts 条目到 index.md（Claude-Skills、Workflow-Engineering） - - 无内容冲突 - - Entity 页面（Anthropic/skillsmp/aitmpl 等）出现次数均 <2 次，未创建 -- Source page: wiki/sources/7-ways-i-use-notebooklm-to-make-my-life-easier.md -- Notes: - - 更新 index.md Sources 部分（替换 expected 占位条目）和 Concepts 部分（新增2个条目） - - 更新 overview.md AI Tools & Prompt Engineering 小节（补充 NotebookLM 7种用法条目） - - NotebookLM Entity 页面已存在，更新 sources 字段和内容 - - Source-Grounding 和 Passive-Learning 为新建 Concept 页面 - - 冲突检测：未发现与其他 Wiki 页面存在明显内容冲突 - -## [2026-04-24] ingest | Never write another prompt -- Source file: AI/Never write another prompt.md -- Status: ✅ 成功摄入 -- Summary: 介绍一款能将简单描述自动转化为详细结构化提示词的 AI 工具，支持变量插入和自定义编辑，大幅降低提示词工程门槛。与 Claude Prompt Library（现成提示词库）和 Nano Banana 提示词框架（结构化模板）同属提示词工程的不同路径。 -- Concepts covered: [[Prompt Engineering]], [[API Key]], [[Variables in Prompts]] -- Entities referenced: [[ChatGPT]], [[Google Gemini]] -- Source page: wiki/sources/never-write-another-prompt.md -- Notes: - - 更新 index.md Sources 部分（新增条目，按日期排序） - - 更新 overview.md AI Tools & Prompt Engineering 小节 - - 冲突检测：与 useful-prompt-lib.md 存在"是否需要预制提示词"视角差异（双方 Contradictions 均已记录） - - ChatGPT/Google Gemini 已存在于 Wiki，无需新建 Entity 页面 - -## [2026-04-23] ingest | Best 7 news API data feeds - AI News -- Source file: AI/Best 7 news API data feeds - AI News.md -- Status: ✅ 成功摄入 -- Summary: 7款主流新闻API横向评测（Webz.io/GNews/The Guardian/Bloomberg/Financial Times/Opoint/Mediastack），覆盖开放网/深网/暗网数据、金融情报、舆情监控、情感分析、内容聚合、AI预测分析等应用场景，为AI应用和数据分析场景选择新闻数据接口提供选型参考。 -- Concepts covered: [[News API]], [[Financial Intelligence]], [[Media Monitoring]], [[Sentiment Analysis]], [[Risk Assessment]], [[Content Aggregation]], [[Predictive Analysis]] -- Entities referenced: [[Webz.io]], [[GNews API]], [[The Guardian API]], [[Bloomberg API]], [[Financial Times API]], [[Opoint]], [[Mediastack API]] -- Source page: wiki/sources/best-7-news-api-data-feeds-ai-news.md -- Notes: - - 更新 index.md Sources 部分 - - 7个 Entity 均仅出现1次，未创建独立 Entity 页面 - - Concept 均为通用概念，已隐式覆盖，无冲突 - -## [2026-04-23] ingest | Claude Prompt Library 汇总表 -- Source file: AI/Useful Prompt Lib.md -- Status: ✅ 成功摄入 -- Summary: Anthropic Claude 官方提示词库完整汇总，收录 64+ 款专业化提示词，覆盖开发工具、效率工具、创意工具、营销工具、教育工具等 10+ 领域。TikTok 跨境电商推荐 Babel's Broadcasts（多语言推文）、Review Classifier（评论分类）、Data Organizer（非结构化→JSON）三剑客。 -- Concepts covered: [[Anthropic Prompt Library]], [[Babel's Broadcasts]], [[Review Classifier]], [[Data Organizer]], [[Prompt Engineering]] -- Entities referenced: [[Anthropic]], [[TikTok]] -- Source page: wiki/sources/useful-prompt-lib.md -- Notes: - - 更新 index.md Sources 部分 - - 更新 overview.md AI Tools & Prompt Engineering 小节 - - Anthropic/TikTok 均仅出现1次，未创建独立 Entity 页面 - - 冲突检测：与 never-write-another-prompt.md 存在"是否需要预制提示词"的冲突（已记录至 source page Contradictions 部分） - -## [2026-04-23] ingest | 二创视频必不可少！2025年最热门AI工具推荐合集-AI配音、声音克隆 -- Source file: AI/二创视频必不可少！2025年最热门AI工具推荐合集-AI配音、声音克隆.md -- Status: ✅ 成功摄入 -- Summary: 2025年AI配音及声音克隆工具推荐合集，评测ElevenLabs、海螺AI（MiniMax）、F5-TTS、TTSMaker、剪映、魔音工坊、AnyVoice等7款主流工具。涵盖免费/付费、国际/国内、技术门槛等多维度对比，为不同用户群体提供选型建议。 -- Concepts covered: [[AI配音]], [[声音克隆]] -- Entities referenced: [[ElevenLabs]], [[海螺AI]], [[F5-TTS]], [[TTSMaker]], [[剪映]], [[魔音工坊]], [[AnyVoice]], [[MiniMax]] -- Source page: wiki/sources/二创视频必不可少-2025年最热门ai工具推荐合集-ai配音-声音克隆.md -- Notes: - - 更新 index.md Sources 部分 - - Entity/Concept 均未创建独立页面（各工具仅在本文出现一次，不满足Entity≥2次条件；AI配音/声音克隆概念在其他来源中已有相关讨论，可后续扩展） - -## [2026-04-23] ingest | The Picture They Paint of You -- Source file: AI/The Picture They Paint of You.md -- Status: ✅ 成功摄入 -- Summary: 探讨 AI 工具的市场定位如何折射对人类工作者的隐性认知。对比 10+ 款 AI SRE 产品和 8+ 款 Coding Assistant 的营销话语，发现：AI SRE 被建构为"替代者"，Coding Assistant 被建构为"合作伙伴"。这种差异映射了组织内部对不同角色真实价值的认知分裂，暗示决策者与从业者之间对工作意义理解的根本分歧。 -- Concepts created: [[Taylorism]], [[Left-over-Principle]], [[Analogy-as-Straitjacket]] -- Source page: wiki/sources/the-picture-they-paint-of-you.md -- Notes: - - 新增 Sources 条目至 index.md - - 新增 3 个 Concept 页面：Taylorism.md、Left-over-Principle.md、Analogy-as-Straitjacket.md - - 冲突检测：与 wiki/sources/what-i-know-about-cloud-service-delivery-1.md 中 SRE 角色认知存在冲突（已记录至 source page Contradictions 部分） - - Entities: Anthropic、GitHub Copilot、OpenAI Codex、Cline、AWS DevOps Agent 均未创建独立页面（属产品类 Entity，命名类 Entity 价值待定） - -## [2026-04-23] ingest | Nano Banana 提示词框架 -- Source file: AI/Nano Banana 提示词框架.md -- Status: ✅ 成功摄入 -- Summary: AI 图像生成的结构化提示词框架，提供两套 JSON Schema 模板——物件描述框架（item / materials / details / condition）和人物描述框架（age / appearance / pose）——共用 shot / environment / lighting / camera / color_grade / style / quality / negatives 参数字段。示例展示了如何将专业摄影描述语言（材质/布光/相机参数）结构化填入模板。 -- Concepts covered: [[Nano Banana Prompting Framework]], [[Structured Prompt Engineering]], [[Negative Prompting]], [[Shot Composition]], [[Photography Lighting Description]], [[Camera Parameter Specification]] -- Entities referenced: [[Google]], [[Nano Banana]] -- Source page: wiki/sources/nano-banana-提示词框架.md -- Notes: - - 新增 Sources 条目至 index.md（替换 expected 标记行） - - 更新 overview.md AI Tools & Prompt Engineering 部分 - - Google Entity 已存在于 wiki/entities/Google.md，未重复创建 - -## [2026-04-23] ingest | 谷歌深夜甩出一份【Nano Banana Pro提示词指南】，手把手教你生产专业级内容，实战案例+提示词模版 -- Source file: AI/谷歌深夜甩出一份【Nano Banana Pro提示词指南】，手把手教你生产专业级内容，实战案例+提示词模版.md -- Status: ✅ 成功摄入 -- Summary: 谷歌发布的 Nano Banana Pro 官方提示词指南（《The Complete Guide to Nano Banana Pro》），核心主题是"将 AI 从趣味性图像生成升级为功能性专业资产生产"。10 大黄金法则：编辑而非重新生成、使用自然语言完整句子、具体且具描述性、提供上下文。9 个实战章节覆盖文本渲染/信息图、角色一致性、Google 搜索信息锚定、高级编辑、2D/3D 转换、高分辨率、思考推理、故事板、结构控制。 -- Concepts created: [[提示词工程]], [[身份锁定（Identity Locking）]], [[思维推理模式（Thinking Mode）]], [[信息图生成]], [[2D/3D 转换]], [[草图转成品（Sketch to Final）]] -- Entities created: [[谷歌]] -- Source page: wiki/sources/谷歌深夜甩出一份-nano-banana-pro提示词指南-手把手教你生产专业级内容-实战案例-提示词模版.md -- Notes: - - 新增 Sources 条目至 index.md（替换 expected 标记行） - - 新增 6 个 Concept 页面 - - 新增 1 个 Entity 页面：Google.md - - 更新 overview.md，新增"Nano Banana Pro 提示词指南"段落至 AI Tools & Prompt Engineering 部分 - - 冲突检测：暂无发现与其他 Wiki 页面的内容冲突 - -## [2026-04-23] ingest | 详细！离线部署大模型：ollama+deepseek+open-webui安装使用方法及常见问题解决 1 -- Source file: AI/详细！离线部署大模型：ollama+deepseek+open-webui安装使用方法及常见问题解决 1.md -- Status: ✅ 成功摄入 -- Summary: Ollama + DeepSeek-R1 + Open WebUI 本地离线部署完整指南，覆盖硬件要求、安装方法（macOS/Windows/Linux/Docker）、模型下载加速（魔塔/HF Mirror/夸克网盘）、API 安全配置（nginx + Bearer Token）和 Open WebUI Docker Compose 部署。 -- Entities created: [[Ollama]], [[Open WebUI]] -- Concepts created: [[Local LLM Deployment]], [[Docker LLM Deployment]] -- Source page: wiki/sources/详细-离线部署大模型-ollama-deepseek-open-webui安装使用方法及常见问题解决-1.md -- Notes: - - 新增 Sources 条目至 index.md（Sources 节顶部） - - 新增 Entity 页面：Ollama.md、Open-WebUI.md - - 新增 Concept 页面：Local-LLM-Deployment.md、Docker-LLM-Deployment.md - - 更新 overview.md：Key Entities 节和 AI Tools 节 - -## [2026-04-23] ingest | OpenAI ChatGPT 个性化定义 -- Source file: AI/OpenAI ChatGPT 个性化定义.md -- Status: ✅ 成功摄入 -- Summary: ChatGPT 自定义指令（Custom Instructions）的完整配置——定义用户身份（47岁、云计算背景、跨境电商创业者）、响应风格（高度有条理、详细解释、错误零容忍）和交互偏好（主动预判需求、不道德说教、URL统一末尾引用）。核心原则：[[Expert User Assumption]]（用户为所有领域专家）、[[Proactive AI]]（主动出击而非被动等待）、[[Error Accountability]]（主动反馈配置导致的回复质量下降）。 -- Concepts created: [[Personalization]], [[Custom Instructions]], [[Proactive AI]], [[Expert User Assumption]], [[Error Accountability]] -- Entities created: [[OpenAI]], [[ChatGPT]] -- Source page: wiki/sources/openai-chatgpt-个性化定义.md -- Notes: - - 新增 Sources 条目至 index.md（替换 expected 标记行） - - 新增 5 个 Concept 页面：Personalization.md、Custom-Instructions.md、Proactive-AI.md、Expert-User-Assumption.md、Error-Accountability.md - - 新增 2 个 Entity 页面：OpenAI.md（美国 AI 研究公司）、ChatGPT.md（OpenAI 对话产品） - - 更新 overview.md，新增"ChatGPT 个性化配置"段落至 AI Tools & Prompt Engineering 部分 - - 将 5 个新 Concept 添加至 overview.md Key Concepts 列表 - - 将 OpenAI、ChatGPT 添加至 overview.md Key Entities 列表 - - 冲突检测：暂无发现与其他 Wiki 页面的内容冲突——[[designing-for-agentic-ai]] 中的 Personalization 原则与本文配置案例一致，无矛盾 - -## [2026-04-23] ingest | A Formalization of Recursive Self-Optimizing Generative Systems -- Source file: AI/A Formalization of Recursive Self-Optimizing Generative Systems.md -- Status: ✅ 成功摄入 -- Summary: 递归自我优化生成系统的形式化理论模型——定义生成器空间 $\mathcal{G}$、优化算子 $O$、元生成算子 $M$、自映射 $\Phi$，稳定生成能力 $G^*$ = $\Phi$ 的不动点；用 λ-calculus Y 组合子表达自引用结构 $G^* \equiv Y\;\text{STEP}$。核心发现：递归自我优化自然涌现不动点结构，而非终止输出；为 Self-Improving AI 提供原则性理论基础。 -- Concepts created: [[Recursive Self-Optimization]], [[Generator Space]], [[Self-Referential Computation]], [[Fixed-Point Semantics]], [[Y-Combinator]] -- Entities created: [[tukuai]] -- Source page: wiki/sources/a-formalization-of-recursive-self-optimizing-generative-systems.md -- Notes: - - 新增 Sources 条目至 index.md（替换 expected 标记行） - - 新增 5 个 Concept 页面：Recursive-Self-Optimization.md、Generator-Space.md、Self-Referential-Computation.md、Fixed-Point-Semantics.md、Y-Combinator.md - - 新增 1 个 Entity 页面：tukuai.md（独立研究者，本文作者） - - 更新 overview.md，新增"Recursive Self-Optimizing Generative Systems"段落至 Multi-Agent AI Systems 部分 - - 将 5 个新 Concept 添加至 overview.md Key Concepts 列表 - - 将 tukuai 添加至 overview.md Key Entities 列表 - - 冲突检测：暂无发现与其他 Wiki 页面的内容冲突——本文为纯理论形式化，与 Wiki 中其他 Agent 应用案例属不同层次 - -## [2026-04-23] ingest | LLMs、RAG、AI Agent 三个到底什么区别？ -- Source file: AI/LLMs、RAG、AI Agent 三个到底什么区别？.md -- Status: ✅ 成功摄入 -- Summary: LLM、RAG、AI Agent 三者的定义与关系——LLM=思考（天才大脑），RAG=认知（记忆系统），Agent=执行（行动系统）。三者非竞争技术，而是在不同层面互补。未来不在于选择其一，而在于将三者结合架构设计。 -- Concepts created: [[Large Language Model]], [[RAG]], [[AI Agent]], [[ReAct Pattern]] -- Entities created: （无新 Entity 创建） -- Source page: wiki/sources/llms-rag-ai-agent-三个到底什么区别.md -- Notes: - - 新增 Sources 条目至 index.md（置于最前，按日期排序） - - 新增 3 个 Concept 页面：Large-Language-Model.md、RAG.md、AI-Agent.md - - 更新 overview.md Key Concepts 列表，添加 Large Language Model/RAG/AI Agent/ReAct Pattern - - 更新 overview.md，新增"LLM / RAG / AI Agent 三层架构"段落至 AI Tools & Prompt Engineering 部分 - - 更新 index.md Concepts 部分，添加 3 个新 Concept 条目 - - 冲突检测：暂无发现与其他 Wiki 页面的内容冲突——本文为基础概念梳理，与 Wiki 中 Agentic AI 相关内容一致 - -## [2026-04-23] ingest | Google 神级生产力工具，所有 GitHub 开源平替都找到了 -- Source file: AI/Google 神级生产力工具，所有 GitHub 开源平替都找到了。.md -- Status: ✅ 成功摄入 -- Summary: Google NotebookLM 的 6 款 GitHub 开源平替全景盘点——OpenNotebook（14.6k Stars 全功能）、SurfSense（11.4k Stars 综合研究智能体）、Podcastfy（播客垂直聚焦）、NotebookLlama（LlamaIndex 官方学习参考）、PageLM（教育场景）、InsightsLM（低代码架构）。覆盖从"全功能替代"到"垂直聚焦"的不同需求层次。 -- Concepts created: [[文档问答]], [[播客生成]], [[语义搜索]], [[混合搜索]], [[本地化部署]] -- Entities created: [[Google]], [[NotebookLM]], [[OpenNotebook]], [[SurfSense]], [[Podcastfy]], [[NotebookLlama]], [[PageLM]], [[InsightsLM]] -- Source page: wiki/sources/google-神级生产力工具-所有-github-开源平替都找到了.md -- Notes: - - 新增 Sources 条目至 index.md（替换 expected 标记行） - - 新增 Entity 页面：Google、NotebookLM、OpenNotebook、SurfSense、Podcastfy、NotebookLlama、PageLM、InsightsLM（共8个） - - 新增 Concept 页面：文档问答、播客生成、语义搜索、混合搜索、本地化部署（共5个） - - 更新 overview.md，新增"AI Tools & Prompt Engineering"部分的"NotebookLM 开源平替生态"段落 - - 无内容冲突——与现有 RAG、知识管理工具内容互补，未发现矛盾 - -## [2026-04-23] ingest | 教學 ChatGPT 先做知識整理，再讓 Canva、 Gamma AI 輸出簡報 -- Source file: AI/教學 ChatGPT 先做知識整理，再讓 Canva、 Gamma AI 輸出簡報.md -- Status: ✅ 成功摄入 -- Summary: AI 简报自动化工作流——先用 ChatGPT 做知识整理，再用 Canva / Gamma AI 输出演示文稿。两阶段工作流（思考者→设计师）比直接用 AI 生成简报效果更好。 -- Concepts created: [[AI簡報工作流]] -- Entities created: [[Canva]], [[Gamma-AI]] -- Source page: wiki/sources/教學-chatgpt-先做知識整理-再讓-canva-gamma-ai-輸出簡報.md -- Notes: - - 新增 Sources 条目至 index.md（替换 expected 标记行） - - 新增 Entity 条目：[[Canva]], [[Gamma-AI]] - - 新增 Concept 条目：[[AI簡報工作流]] - - 更新 overview.md，新增段落至 AI Tools & Prompt Engineering 部分 - - 无内容冲突 - -## [2026-04-23] ingest | Designing for Agentic AI -- Source file: AI/Designing for Agentic AI.md -- Status: ✅ 成功摄入 -- Summary: 阐述 GenAI（创作内容）vs Agentic AI（主动行动）的核心差异，以及为 Agentic AI 设计用户体验的 TCPCA 五原则——透明度、控制感、个性化、对话、主动预判。核心洞察：观察 AI 决策过程本身就是一种参与方式，设计隐喻从"响应用户点击/滑动"转向"AI 运行时的实时反馈"。 -- Concepts updated: [[Agentic AI]]（已存在，仅补充 TCPCA 五原则维度）, [[Transparency]], [[Control]], [[Personalization]], [[Conversation]], [[Anticipation]] -- Entities updated: [[Yuri Pessa]]（已存在，仅补充身份说明） -- Source page: wiki/sources/designing-for-agentic-ai.md -- Notes: - - 新增 Sources 条目至 index.md（置于 Sources 末尾，因源文件日期 2025-03-02 早于所有现有条目） - - 新增 overview.md 段落至 AI Tools & Prompt Engineering 部分 - - 无需新建 Entity/Concept 页面（Agentic-AI entity 已存在，TCPCA 五原则暂不满足独立 Concept 页面条件） - - 与 [[Google-5个-Agent-Skill-设计模式]] 同属 AI Agent 设计方法论 - -## [2026-04-23] ingest | 养虾日记5：深夜与苏轼聊AI，他说：被浪打下去还能爬起来的才叫风流 -- Source file: 微信公众号/养虾日记5：深夜与苏轼聊AI，他说：被浪打下去还能爬起来的才叫风流.md -- Status: ✅ 成功摄入 -- Summary: 用AI蒸馏历史人物思维框架创建"数字导师"——以苏东坡为首位实践，展示如何将千年古人心智模型（六道：进退由时/此心安处/辞达而已/逆境转化/自出新意/天人合一）转化为可运行的AI Skill。女娲·Skill造人术通过6个并行Agent从6维度采集信息，产出自包含的.skill文件。 -- Concepts created: [[数字导师]], [[思维蒸馏（女娲造人术）]], [[心智模型]], [[AI-Skill]] -- Entities created: [[苏东坡]], [[女娲]] -- Source page: wiki/sources/养虾日记5-深夜与苏轼聊ai-他说-被浪打下去还能爬起来的才叫风流.md -- Notes: - - 新增 Sources 条目至 index.md（置于养虾日记4之后） - - 新增 Entity 条目：[[苏东坡]] - - 新增 Concept 条目：[[数字导师]], [[思维蒸馏（女娲造人术）]] - - 与 [[养虾日记1/2/3/4]] 和 [[养龙虾5天血泪史]] 属同一「养虾日记」系列 - -## [2026-04-23] ingest | 一语点醒梦中人 -- Source file: AI/一语点醒梦中人.md -- Status: ✅ 成功摄入 -- Summary: 收录中国传统诗词与哲学典籍中的经典名句及其释义，涵盖儒道佛三家智慧——王维"行到水穷处，坐看云起时"的佛学顿悟、曾国藩"唯忘机可以消众机"的处世哲学、庄子"知其不可奈何而安之若命"的接受智慧、《老子》"大智若愚，大巧若拙"的守拙哲学、《金刚经》"一切有为法如梦幻泡影"的空性智慧。 -- Concepts covered: [[空性智慧]], [[守拙]], [[安之若命]], [[和光同尘]], [[忘机]], [[中庸之道]], [[有为法]] -- Entities referenced: [[王维]], [[曾国藩]], [[庄子]], [[苏东坡]], [[郑板桥]] -- Source page: wiki/sources/一语点醒梦中人.md -- Notes: - - 新增 Sources 条目至 index.md - - 新增 overview.md 段落"经典智慧与人生哲学" - - Entity/Concept 均未创建独立页面（各人物/概念仅在本文出现1次，未达≥2次阈值） - - 与 [[养虾日记5]]（苏东坡数字导师）存在潜在关联，可后续扩展 - -## [2026-04-22] ingest | 不谈技术：普通人该怎么在AI时代赚钱？ - 2|- Source file: 微信公众号/不谈技术：普通人该怎么在AI时代赚钱？.md - 3|- Status: ✅ 成功摄入 - 4|- Summary: AI时代普通人如何赚钱的思维框架——三大原则：品味值钱（判断力是护城河）、做端到端的事（不当代价）、用死亡过滤器（找到真正热爱的事）。核心洞察：AI不会让普通人变富，AI会让那些知道自己要做什么、并且对品质有执念的人变得极其强大。 - 5|- Concepts created: [[品味]], [[端到端]], [[死亡过滤器]], [[工具民主化]] - 6|- Entities created: [[乔布斯]] - 7|- Source page: wiki/sources/不谈技术-普通人该怎么在ai时代赚钱.md - 8|- Notes: - 9| - 与 [[个人品牌与一人公司]] 属同一主题（AI时代个人定位与杠杆） - 10| - 与 [[Ikigai框架]] 的"热情"维度高度相关 - 11| - 12|## [2026-04-10] ingest | 养虾日记4：一次「Context Limit Exceeded」错误排查 - 13|- Source file: 微信公众号/养虾日记4： 一次「Context Limit Exceeded」错误排查：我以为是小问题，结果踩了大坑.md - 14|- Status: ✅ 成功摄入 - 15|- Summary: OpenClaw Telegram Channel「Context Limit Exceeded」错误深度排查——问题表象是 context 耗尽，实际根因是 Telegram channel 的模型被切换为 deepseek-reasoner（仅 16K context），safeguard 模式预留 16K tokens 导致实际可用为 0。解决关键：Agent 级别模型配置优先级高于全局 compaction 配置，需在路由规则层修复。 - 16|- Concepts created: [[Context-Window]], [[Model-Fallback]], [[Compaction]], [[Agent-Routing-Rules]], [[Error-Surface-vs-Root-Cause]], [[Layered-Configuration]], [[Log-Driven-Debugging]], [[Hidden-Failure-Paths]] - 17|- Entities created: （无新增；[[OpenClaw]]/[[星枢]]/[[DeepSeek]]/[[MiniMax]] 均已在现有来源中出现，不满足 ≥2 次创建条件） - 18|- Source page: wiki/sources/养虾日记4-一次「context-limit-exceeded」错误排查-我以为是小问题-结果踩了大坑.md - 19|- Notes: - 20| - 新增 Sources 条目至 index.md（置于养龙虾5天血泪史之后） - 21| - 更新 overview.md，新增 [[养虾日记4]] 段落至 Multi-Agent AI Systems 部分 - 22| - 创建 8 个 Concept 页面：Context-Window.md、Model-Fallback.md、Compaction.md、Agent-Routing-Rules.md、Error-Surface-vs-Root-Cause.md、Layered-Configuration.md、Log-Driven-Debugging.md、Hidden-Failure-Paths.md - 23| - 更新 index.md Concepts 节，新增 8 个条目（按字母顺序插入） - 24| - 与 [[养龙虾5天血泪史]] 互补（记忆写入/压缩问题 vs 模型配置错误） - 25| - 冲突检测：无与其他 Wiki 页面的实质性内容冲突 - 26| - 27|## [2026-04-23] ingest | 养虾日记3：用 Obsidian + Gitea 为 AI 助手构庺持久化笔记系统 - 28|- Source file: 微信公众号/养虾日记3：用 Obsidian + Gitea 为 AI 助手构建持久化笔记系统.md - 29|- Status: ✅ 成功摄入 - 30|- Summary: 用 Obsidian + Gitea 为 AI 助手构建持久化笔记系统——解决"AI 对话结束输出就消失"的核心问题。核心架构：Obsidian 做知识库（iCloud Drive 三端同步）+ Gitea 做版本控制（Git 历史）+ OpenClaw obsidian skill 做写入接口。核心价值：把 AI 变成"会自动整理笔记的实习生"。融合了 Karpathy 的 LLM Wiki 理念：让 AI 增量构建 Wiki，页面间互链，知识越积越厚。 - 31|- Concepts created: [[LLM Wiki]], [[Obsidian Git]], [[Graph View]], [[Obsidian Web Clipper]], [[QMD]], [[版本管理]], [[被动更新]], [[双链笔记]] - 32|- Entities created: [[Obsidian]], [[Gitea]] - 33|- Source page: wiki/sources/养虾日记3-用-obsidian-gitea-为-ai-助手构建持久化笔记系统.md - 34|- Notes: - 35| - 新增 Sources 条目至 index.md（置于最前） - 36| - 更新 overview.md，替换原 [[养虾日记1]] 段落为 [[养虾日记3]] - 37| - 创建 Entity 页面：Obsidian.md, Gitea.md - 38| - 创建 Concept 页面：LLM-Wiki.md - 39| - Gitea 已在 Entity 中存在（无需重复创建，仅更新） - 40| - 冲突：无已知冲突 - 41| - 42|## [2026-04-23] ingest | 养龙虾5天血泪史：我的AI Agent为什么总失忆？OpenClaw 记忆调试全记录 - 43|- Source file: 微信公众号/养龙虾5天血泪史：我的AI Agent为什么总失忆？OpenClaw 记忆调试全记录.md - 44|- Status: ✅ 成功摄入 - 45|- Summary: AI Agent 记忆失效问题的5天专项调试全记录——发现5类根本原因（上下文压缩、搜索后端、检索触发、压缩协同、系统配置），对应10条黄金法则。核心洞察：写入纪律比读取纪律更重要；压缩不是敌人，未写入的上下文才是；系统提示词从209,652精简到9,349令牌（减少28%）。 - 46|- Concepts created: 上下文压缩、上下文刷新、写入纪律、交接协议、启动序列 - 47|- Entities created: — - 48|- Source page: wiki/sources/养龙虾5天血泪史-我的ai-agent为什么总失忆-openclaw-记忆调试全记录.md - 49|- Notes: - 50| - 新增 Sources 条目至 index.md（置于养虾日记1、2之后） - 51| - 更新 overview.md，新增 [[养龙虾5天血泪史]] 段落至养虾日记系列部分 - 52| - 创建 5 个 Concept 页面（上下文压缩/上下文刷新/写入纪律/交接协议/启动序列） - 53| - Hybrid-Search 概念页面已存在（无需重复创建） - 54| - 冲突已记录于 source page Contradictions 部分（与 Second Brain 的 MEMORY.md 定位差异、与 personal-crm 的联系人记录方式差异） - 55| - 56|## [2026-04-23] ingest | 养虾日记1：我用 OpenClaw 管了 28 万张照片 - 57|- Source file: 微信公众号/养虾日记1：我用 OpenClaw 管了 28 万张照片：一次真实的多设备照片整理实战.md - 58|- Status: ✅ 成功摄入 - 59|- Summary: AI Agent 照片整理实战——使用 OpenClaw 成功整理了 NAS 上 28 万张、跨越 20 年的家庭照片。OpenClaw 通过「提问澄清 → 方案制定 → 批次拆分（8 批次）→ Cron 凌晨自动执行 → Telegram Summary 报告」全流程自动化。核心机制：MD5 精确去重 + 小文件清理（<100KB）+ 安全删除策略（To-Be-Deleted 目录）。核心感悟：AI Agent 的价值是思维方式升级。 - 60|- Concepts created: — - 61|- Entities created: — - 62|- Source page: wiki/sources/养虾日记1-我用-openclaw-管了-28-万张照片-一次真实的多设备照片整理实战.md - 63|- Notes: - 64| - 新增 Sources 条目至 index.md（置于最前） - 65| - 更新 overview.md，新增 [[养虾日记1]] 段落至 Self-Improving 部分，新增 [[AI-Agent思维方式]]/[[批次任务拆分]]/[[精确去重]]/[[小文件清理]]/[[安全删除策略]]/[[Telegram通知]] 至 Key Concepts - 66| - Entity 数量不足阈值（OpenClaw/Synology Photos/NAS 均已存在或仅出现 1 次），未创建新 Entity 页面 - 67| - Concept 数量不足阈值（所有概念均为本篇特定实践，不满足可抽象/可复用条件），未创建独立 Concept 页面 - 68| - 冲突已记录于 source page Contradictions 部分（与 Self-Healing-Home-Server 的规划者 vs 修复者角色差异） - 69| - 70|## [2026-04-23] ingest | X Account Analysis - 71|- Source file: Agent/usecases/x-account-analysis.md - 72|- Status: ✅ 成功摄入 - 73|- Summary: 基于 OpenClaw + Bird Skill 的 X 账号定性分析——通过 Cookie 认证读取真实账号推文，AI 分析内容质量模式（为何有时 1000+ 赞有时 <5 赞）、话题偏好与互动差异原因。免费替代 $10-$50/月订阅服务。 - 74|- Concepts created: — - 75|- Entities created: — - 76|- Source page: wiki/sources/x-account-analysis.md - 77|- Notes: - 78| - 新增 Sources 条目至 index.md（置于最前） - 79| - 更新 overview.md，新增 [[x-account-analysis]] 段落至 X/Twitter Automation 部分（补充原 x-twitter-automation 段落的互补关系描述） - 80| - 更新 wiki/sources/x-twitter-automation.md，移除"（尚未摄入）"标注 - 81| - Entity/Concept 数量不足阈值（每项仅在本文中出现 1 次），未创建新实体/概念页面；[[OpenClaw]] 已存在于 Key Entities - 82| - 新增 Key Concepts: [[Social-Media-Analytics]], [[Credential-Isolation]] - 83| - 84|## [2026-04-23] ingest | Phone Call Notifications - 85|- Source file: Agent/usecases/phone-call-notifications.md - 86|- Status: ✅ 成功摄入 - 87|- Summary: AI Agent 通过 clawr.ing 托管电话服务主动向用户拨打电话通知——Agent 评估事件优先级（股价暴跌/紧急邮件/日程提醒），自动拨叫用户真实号码，用户可实时提问，Agent 双向对话响应。与 [[phone-based-personal-assistant]] 互补（Agent 去电通知 vs 用户来电接收）。 - 88|- Concepts created: [[Voice Notification Channel]], [[Two-Way Voice Conversation]], [[Call-Worthy Threshold]] - 89|- Entities created: [[clawr.ing]], [[clawhub.ai]] (updated) - 90|- Source page: wiki/sources/phone-call-notifications.md - 91|- Notes: - 92| - 新增 Sources 条目至 index.md（置于最前） - 93| - 更新 overview.md，新增 [[phone-call-notifications]] 段落至 AI Tools & Prompt Engineering 部分，新增 [[clawr.ing]]/[[clawhub.ai]] 至 Key Entities，新增 [[Voice Notification Channel]]/[[Two-Way Voice Conversation]]/[[Call-Worthy Threshold]]/[[PSTN Calling]] 至 Key Concepts - 94| - 新增 Entity: wiki/entities/clawr.ing.md；更新 wiki/entities/ClawHub.md（添加 clawr.ing 作为托管 skill） - 95| - 新增 Concept: wiki/concepts/Voice-Notification-Channel.md、wiki/concepts/Two-Way-Voice-Conversation.md、wiki/concepts/Call-Worthy-Threshold.md - 96| - 更新 overview.md Conflict Areas，新增"Agent 去电通知 vs Agent 来电接收"冲突点 - 97| - 98|## [2026-04-23] ingest | Autonomous Educational Game Development Pipeline - 99|- Source file: Agent/usecases/autonomous-game-dev-pipeline.md - 100|- Status: ✅ 成功摄入 - 101|- Summary: AI Agent 全自动管理教育游戏开发生命周期——"Bugs First" 优先策略 + Round Robin 轮询 + 纯 HTML5/CSS3/JS 技术栈，单人实现每 7 分钟产出 1 款游戏或 1 个 bugfix，41+ 款游戏维护。 - 102|- Concepts created: [[Bugs First]], [[Round Robin Strategy]], [[Conventional Commits]], [[Feature Branch Workflow]], [[HTML5 Game Development]] - 103|- Entities created: — - 104|- Source page: wiki/sources/autonomous-game-dev-pipeline.md - 105|- Notes: - 106| - 新增 Sources 条目至 index.md（置于最前） - 107| - 更新 overview.md，新增 [[autonomous-game-dev-pipeline]] 段落至 AI Tools & Prompt Engineering 部分 - 108| - Entity/Concept 数量不足阈值，未创建新实体页面；[[OpenClaw]] 实体已存在于 index.md - 109| - 110|## [2026-04-23] ingest | arXiv Paper Reader - 111|- Source file: Agent/usecases/arxiv-paper-reader.md - 112|- Status: ✅ 成功摄入 - 113|- Summary: AI Agent 驱动的 arXiv 论文阅读助手——通过 `arxiv-reader` skill（3 工具：`arxiv_fetch`、`arxiv_sections`、`arxiv_abstract`）直接从 arXiv 下载 LaTeX 源码并自动扁平化展开，消除 PDF 下载后切换论文丢失上下文和 LaTeX 符号难以解析的痛点；支持摘要浏览、多论文对比排序、选择性细读和会话式分析；本地缓存使重复访问秒级响应；纯 Node.js 零依赖部署。 - 114|- Concepts created: [[arXiv-API]], [[LaTeX-Flattening]], [[Local-Caching]], [[Paper-Abstract-Batch-Fetching]] - 115|- Entities created: [[Prismer-AI]] - 116|- Source page: wiki/sources/arxiv-paper-reader.md - 117|- Notes: - 118| - 新增 Sources 条目至 index.md（替换 "source missing" placeholder） - 119| - 更新 overview.md，在 YouTube Automation 部分后新增 [[arXiv-Paper-Reader]] 段落，在 Key Concepts 列表新增 4 个新概念 - 120| - 创建 Entity 页面：Prismer-AI.md（GitHub 组织，`arxiv-reader` skill 维护方） - 121| - 创建 Concept 页面：arXiv-API.md（arXiv 开放 API）、LaTeX-Flattening.md（LaTeX 扁平化技术）、Local-Caching.md（本地缓存模式）、Paper-Abstract-Batch-Fetching.md（批量摘要对比模式） - 122| - 与 [[academic-historian]] 同属学术研究场景互补——前者侧重理工科论文，后者侧重人文社科 - 123| - 与 [[YouTube-Content-Pipeline]] 的 Research Agent 共享研究工作流设计模式 - 124| - 冲突检测：无已知实质冲突 - 125| - 126|## [2026-04-22] ingest | Semantic Memory Search - 127|- Source file: Agent/usecases/semantic-memory-search.md - 128|- Status: ✅ 成功摄入 - 129|- Summary: 通过 memsearch（基于 Milvus 向量数据库）为 OpenClaw Markdown 记忆添加语义搜索能力——用自然语言提问即可找到相关内容，无需精确措辞。混合搜索（稠密向量 + BM25 + RRF）兼顾语义相似性和关键词精确匹配；SHA-256 内容哈希实现增量索引节省成本；文件监视器自动重建索引；支持本地模式无需 API Key。核心理念：Markdown 是唯一真相，向量索引是派生缓存。 - 130|- Concepts created: [[Hybrid Search]], [[Reciprocal Rank Fusion]], [[Content Hashing]], [[File Watcher]] - 131|- Entities created: [[memsearch]], [[Milvus]] - 132|- Source page: wiki/sources/semantic-memory-search.md - 133|- Notes: - 134| - 新增 Sources 条目至 index.md（替换 "source missing" placeholder） - 135| - 更新 overview.md，在 Productivity & Knowledge Management 部分新增 [[semantic-memory-search]] 段落，在 Key Concepts 列表新增 6 个新概念 - 136| - 创建 Entity 页面：Memsearch.md（ZillizTech memsearch CLI/库）、Milvus.md（开源向量数据库） - 137| - 创建 Concept 页面：Hybrid-Search.md（混合搜索策略）、Reciprocal-Rank-Fusion.md（排名融合算法）、Content-Hashing.md（增量索引机制）、File-Watcher.md（自动重建索引） - 138| - 与 [[Knowledge-Base-RAG]] 同属 RAG 技术栈的不同场景——后者侧重 URL 入库，前者侧重现有 Markdown 文件的语义索引 - 139| - 冲突检测：wiki/concepts/Semantic-Search.md 已引用 [[Hybrid Search]]，与本 Source 一致；wiki/concepts/Knowledge-Base-RAG.md 有 Hybrid Search 说明，与本 Source 一致，暂无实质冲突 - 140| - 141|## [2026-04-22] ingest | OpenClaw as Desktop Cowork (AionUi) — Remote Rescue & Multi-Agent Hub - 142|- Source file: Agent/usecases/aionui-cowork-desktop.md - 143|- Status: ✅ 成功摄入 - 144|- Summary: 通过 AionUi 桌面应用将 OpenClaw 作为可视化 Cowork Agent 运行——提供文件感知工作空间（可见文件读写/命令/网页浏览），内置 OpenClaw 部署专家通过 Telegram/WebUI 远程诊断修复（`openclaw doctor`），统一 MCP 配置全局同步到 12+ Agent，支持 WebUI/Telegram/Lark/DingTalk 多渠道远程访问。 - 145|- Concepts created: [[CoworkWorkspace]], [[RemoteRescuePattern]], [[Multi-AgentHub]], [[MCPOnceAllAgents]] - 146|- Entities created: [[AionUi]] - 147|- Source page: wiki/sources/aionui-cowork-desktop.md - 148|- Notes: - 149| - 新增 Sources 条目至 index.md（替换 "source missing" placeholder） - 150| - 更新 overview.md，在 AI Tools & Prompt Engineering 部分新增 [[aionui-cowork-desktop]] 段落，在 Key Entities 部分新增 [[AionUi]]，在 Key Concepts 部分新增 4 个新概念 - 151| - 创建实体页面 wiki/entities/AionUi.md - 152| - 创建概念页面：CoworkWorkspace.md, RemoteRescuePattern.md, Multi-AgentHub.md, MCPOnceAllAgents.md - 153| - 154|## [2026-04-22] ingest | Family Calendar Aggregation & Household Assistant - 155|- Source file: Agent/usecases/family-calendar-household-assistant.md - 156|- Status: ✅ 成功摄入 - 157|- Summary: AI Agent 作为家庭日程协调中心——聚合 5+ 个分散日历（工作/个人/家庭/学校/课外）生成每日晨间简报；通过环境消息监控（Ambient Message Monitoring）自动从 iMessage 中识别预约并创建日历事件（含行车时间缓冲）；维护家庭库存 JSON，支持照片 OCR 和小票识别更新；生成购物清单。核心洞察：Ambient > Active，Mac Mini 是最优硬件。 - 158|- Concepts created: [[AmbientMessageMonitoring]], [[HouseholdInventoryTracking]] - 159|- Entities created: [[SparkryAI]] - 160|- Source page: wiki/sources/family-calendar-household-assistant.md - 161|- Notes: - 162| - 新增 Sources 条目至 index.md（替换 "source missing" placeholder） - 163| - 更新 overview.md，在 AI Tools & Prompt Engineering 部分新增 [[family-calendar-household-assistant]] 段落 - 164| - 新建 Concept 页面：AmbientMessageMonitoring.md（核心差异化机制）、HouseholdInventoryTracking.md（物资追踪模式） - 165| - 新建 Entity 页面：SparkryAI.md（牙医预约案例的来源） - 166| - 与 [[Custom Morning Brief]] 互补：同一晨间简报模式，个人场景 vs 家庭场景 - 167| - 与 [[Second Brain]] 共享 OpenClaw 持久记忆能力 - 168| - 冲突检测：暂无发现与其他 Wiki 页面的内容冲突 - 169| - 170|## [2026-04-22] ingest | Personal Knowledge Base (RAG) - 171|- Source file: Agent/usecases/knowledge-base-rag.md - 172|- Status: ✅ 成功摄入 - 173|- Summary: AI Agent 驱动的个人知识库 RAG 系统——通过 Telegram Topic 或 Slack Channel 投递任意 URL（网页/推文/YouTube 字幕/PDF），Agent 自动抓取内容并以 Embedding 向量入库；支持语义搜索，返回排名结果并附带来源；可被其他工作流（如 [[YouTube-Content-Pipeline]]）主动查询。核心理念：**捕获像发短信一样简单，检索像搜索一样容易**。 - 174|- Concepts created: [[Semantic-Search]], [[Content-Ingestion]] - 175|- Source page: wiki/sources/knowledge-base-rag.md - 176|- Notes: - 177| - 新增 Sources 条目至 index.md（替换 "source missing" placeholder） - 178| - 更新 overview.md，在 Productivity & Knowledge Management 部分新增 [[Personal Knowledge Base (RAG)]] 段落 - 179| - 与 [[Second Brain]] 互补：Second Brain 侧重对话记忆，本方案侧重结构化知识检索 - 180| - 与 [[YouTube-Content-Pipeline]] 关联：后者在工作流中主动查询知识库 - 181| - [[Knowledge-Base-RAG]] 概念页已存在（2026-04-22 youtube-content-pipeline ingest 时创建），本次补充 Semantic-Search 和 Content-Ingestion 两个子概念 - 182| - Entity 页面（OpenClaw、ClawHub、Telegram、Slack）均已在 overview.md Key Entities 中覆盖，无需新建 - 183| - Contradiction：暂无发现与其他 Wiki 页面的内容冲突 - 184|- Status: ✅ 成功摄入 - 185|- Summary: AI Agent 驱动的 YouTube 选题发现与选题自动化流水线——每小时 Cron Job 扫描 Web + X/Twitter 突发 AI 新闻，向 Telegram 推送选题；维护 90 天视频目录（播放量 + 主题分析）避免选题重复；通过 SQLite 向量嵌入实现语义去重；在 Slack 分享链接时自动研究主题、搜索 X、查询知识库并创建带大纲的 Asana 任务卡。 - 186|- Concepts created: [[Semantic-Deduplication]], [[Vector-Embedding]], [[Knowledge-Base-RAG]] - 187|- Source page: wiki/sources/youtube-content-pipeline.md - 188|- Notes: - 189| - 新增 Sources 条目至 index.md（替换 "source missing" placeholder） - 190| - 更新 overview.md，在 YouTube Automation 部分新增 [[YouTube-Content-Pipeline]] 段落 - 191| - 与 [[Daily-YouTube-Digest]] 互补：后者侧重订阅频道更新监控，前者侧重全网趋势主动发现 - 192| - 与 [[Content-Factory]] 共享并行子 Agent 执行模式 - 193| - Entity 页面（OpenClaw、Asana、Slack）均已存在，无需新建 - 194| - 新增 3 个 Concept 页面并注册至 index.md Concepts 索引 - 195| - Contradiction：暂无发现与其他 Wiki 页面的内容冲突 - 196|- Source file: Agent/usecases/polymarket-autopilot.md - 197|- Status: ✅ 成功摄入 - 198|- Summary: 基于 AI Agent 的 Polymarket 预测市场自动驾驶交易系统，实现 24/7 市场监控与自动化分析。AI Agent 自动监控 Polymarket 市场数据、智能分析预测概率变化、自动执行交易策略、定时推送市场洞察。 - 199|- Concepts created: [[Prediction Market]], [[Agentic Trading]], [[Market Monitoring]] - 200|- Entities created: [[Polymarket]] - 201|- Source page: wiki/sources/polymarket-autopilot.md - 202|- Notes: - 203| - 新增 Sources 条目至 index.md（替换 placeholder） - 204| - 更新 overview.md，在 Multi-Agent Monitoring 部分的 Dynamic Dashboard 段落中补充 polymarket-autopilot 引用 - 205| - 与 [[Dynamic Dashboard]] 存在关联（监控仪表盘的具体用例） - 206| - 与 [[earnings-tracker]] 属于同类模式（市场数据监控 + 定时推送） - 207| - Polymarket 已在 overview.md Key Entities 中提及，无需重复创建 Entity 页面 - 208| - Contradiction：暂无发现与其他 Wiki 页面的内容冲突 - 209| - 210|## [2026-04-22] ingest | Local CRM Framework with DenchClaw - 211|- Source file: Agent/usecases/local-crm-framework.md - 212|- Status: ✅ 成功摄入 - 213|- Summary: DenchClaw 将 OpenClaw 转化为本地 CRM、销售自动化和生产力平台，通过 `npx denchclaw` 一键安装完整技术栈（DuckDB + Web UI + OpenClaw Profile + 浏览器自动化）。核心创新：所有设置/视图以 YAML/Markdown 文件存储，Agent 可直接修改 UI 而无需 API 抽象层；Chrome Profile 克隆使 Agent 继承用户认证状态，可直接导入 HubSpot 等平台数据。 - 214|- Concepts created: [[File-System-First-UI]], [[DuckDB]] - 215|- Entities created: [[DenchClaw]] - 216|- Source page: wiki/sources/local-crm-framework.md - 217|- Notes: - 218| - 新增 Sources 条目至 index.md（置于首位） - 219| - 更新 overview.md，在 [[personal-crm]] 附近添加 Local CRM Framework 段落 - 220| - 创建 1 个 Entity 页面：DenchClaw.md - 221| - 创建 2 个 Concept 页面：DuckDB.md、File-System-First-UI.md - 222| - 与 [[Second Brain]] 均基于 OpenClaw 的记忆/持久化能力，属同类应用的不同垂直场景 - 223| - 与 [[personal-crm]] 同属个人 CRM 场景的不同实现方案 - 224| - 与 [[multi-channel-assistant]] 共享 Telegram/消息平台作为交互入口 - 225| - 核心设计哲学：文件系统即 Agent 原生 UI + DuckDB 嵌入式数据库 + Chrome Profile 克隆 - 226| - Contradiction：暂无发现与其他 Wiki 页面的内容冲突 - 227| - 228|## [2026-04-22] ingest | Goal-Driven Autonomous Tasks - 229|- Source file: Agent/usecases/overnight-mini-app-builder.md - 230|- Status: ✅ 成功摄入 - 231|- Summary: AI Agent 从被动执行者转变为主动规划者的目标驱动型自主任务系统。通过 Brain Dump 一次性倾倒所有目标，OpenClaw 每日清晨自动生成 4-5 个贴近目标的自主任务（研究/写作/MVP构建），通过 Next.js Kanban 看板实时追踪。核心价值：用户定义目的地，Agent 自动分解并执行每日步骤。还包含过夜惊喜 Mini-App 构建模式。核心工程实践：Git-style append-only 日志解决多 Agent 竞态条件；Token-Light Design 保持 AUTONOMOUS.md 在 50 行以内。 - 232|- Concepts created: [[Sub-Agent-Race-Condition]], [[Token-Light-Design]], [[Brain-Dump]] - 233|- Entities created: （无新增，[[OpenClaw]]/[[Alex Finn]]/[[Next.js]] 均已存在） - 234|- Source page: wiki/sources/overnight-mini-app-builder.md - 235|- Notes: - 236| - 新增 Sources 条目至 index.md（替换 placeholder，原标题为 overnight-mini-app-builder） - 237| - 更新 overview.md，将 Market Research & Product Factory 段落替换为 Goal-Driven Autonomous Tasks 段落，补充 Git-style append-only 模式和 Token-Light Design 洞察 - 238| - 更新 Alex-Finn.md，将 overnight-mini-app-builder 添加至 sources - 239| - 创建 3 个 Concept 页面：Sub-Agent-Race-Condition.md、Token-Light-Design.md、Brain-Dump.md - 240| - 与 [[Project State Management]] 的看板 vs 事件溯源存在潜在冲突（已记录于 Source Page Contradictions） - 241| - 与 [[market-research-product-factory]] 同属 Alex Finn 启发的 OpenClaw 高阶用法，前者侧重任务追踪和持续执行，后者侧重产品机会发现 - 242| - 243|## [2026-04-17] ingest | Habit Tracker & Accountability Coach - 244|- Source file: Agent/usecases/habit-tracker-accountability-coach.md - 245|- Status: ✅ 成功摄入 - 246|- Summary: AI Agent 作为主动问责伙伴，通过 Telegram/SMS 每日定时签到，替代被动习惯追踪 App。核心机制：主动问责 + 连续打卡追踪 + 自适应语气 + 每周模式分析。关键洞察：主动询问比被动记录更能驱动行为改变；保持 3-5 个习惯可避免签到疲劳；[[Adaptive Tone]] 自适应语气是关键差异化因素。 - 247|- Concepts created: [[Adaptive-Tone]], [[Active-Accountability]], [[Streak-Tracking]], [[Check-in-Fatigue]], [[Weekly-Pattern-Analysis]] - 248|- Entities created: （无新增，[[Telegram Bot API]]/[[Twilio]]/[[Google Sheets API]] 各仅出现 1 次，不满足≥2次创建条件；[[OpenClaw]] 已存在） - 249|- Source page: wiki/sources/habit-tracker-accountability-coach.md - 250|- Notes: - 251| - 新增 Sources 条目至 index.md（替换 placeholder） - 252| - 更新 overview.md，添加 Habit Tracker & Accountability Coach 段落，补充 [[Adaptive Tone]], [[Active Accountability]], [[Streak Tracking]], [[Check-in Fatigue]], [[Weekly Pattern Analysis]] 至 Key Concepts - 253| - 创建 5 个 Concept 页面：Adaptive-Tone.md、Active-Accountability.md、Streak-Tracking.md、Check-in-Fatigue.md、Weekly-Pattern-Analysis.md - 254| - 已有相关 Concept：[[Scheduled-Reminder]]（定时签到技术基础）、[[Agent-Personality]]（Adaptive Tone 的上层设计）、[[Morning Briefing]]（同一 Cron + AI 推送模式）、[[Food-Sensitivity-Tracking]]（同一框架的不同垂直场景） - 255| - 已有相关 Entity：[[OpenClaw]]（底层运行平台） - 256| - 与 [[Health & Symptom Tracker]] 属同一框架（OpenClaw + Telegram + Cron Job + 每周分析），但垂直于个人习惯养成 - 257| - Contradiction：与[[Todoist Task Manager]] 同属 OpenClaw 生产力工具集，但 Todoist 侧重任务管理，Habit Tracker 侧重个人行为改变——不冲突，属于互补关系 - 258| - 与传统习惯 App（Streaks/Habitica）的对比：传统 App 强调被动记录和视觉激励；本方案强调主动询问和个性化文字激励 - 259| - 260|## [2026-04-22] ingest | Todoist Task Manager - 261|- Source file: Agent/usecases/todoist-task-manager.md - 262|- Status: ✅ 成功摄入 - 263|- Summary: AI Agent 通过 Todoist API 实现自然语言驱动的任务管理自动化——Agent 解析自然语言指令 → Todoist REST API 创建结构化任务（含截止/项目/标签）→ Cron Job 定时扫描逾期任务主动推送提醒。核心价值：用户只需发一条消息即可完成全套操作，AI 主动追踪逾期任务。 - 264|- Concepts created: [[Todoist API]], [[AI-Driven Task Extraction]], [[Recurring Tasks]] - 265|- Entities created: （无新增，[[Todoist]]/[[OpenClaw]]/[[SuperCall]] 已存在） - 266|- Source page: wiki/sources/todoist-task-manager.md - 267|- Notes: - 268| - 新增 Sources 条目至 index.md（替换 placeholder） - 269| - 更新 overview.md，添加 Todoist Task Manager 段落，补充 [[Morning Briefing]], [[Todoist API]], [[AI-Driven Task Extraction]], [[TaskAutomation]], [[Recurring Tasks]] 至 Key Concepts - 270| - 更新 entities/Todoist.md，添加 todoist-task-manager 至 sources - 271| - 创建 3 个 Concept 页面：Todoist-API.md、AI-Driven-Task-Extraction.md、Recurring-Tasks.md - 272| - [[Project State Management]] 冲突记录：Todoist（结构化字段/API驱动）与 Markdown 事件流（完整上下文/自托管）各有适用场景 - 273| - 与 [[multi-channel-assistant]] 中 Todoist 集成属同一技术栈，侧重不同：前者侧重多渠道统一入口，后者侧重任务管理深度自动化 - 274| - 275|## [2026-04-22] ingest | Dynamic Dashboard with Sub-agent Spawning - 276|- Source file: Agent/usecases/dynamic-dashboard.md - 277|- Status: ✅ 成功摄入 - 278|- Summary: 基于子代理并行执行的多数据源实时监控仪表盘——通过子代理并行抓取 GitHub/Twitter/Polymarket/系统健康等多数据源，定时聚合结果推送 Discord，支持告警阈值和历史趋势存储。用对话式指令替代数周前端开发，立即获得实时洞察。 - 279|- Concepts created: [[Dynamic-Dashboard]], [[Alerting]] - 280|- Entities created: （无新增，[[OpenClaw]] 已存在） - 281|- Source page: wiki/sources/dynamic-dashboard.md - 282|- Notes: - 283| - 新增 Sources 条目至 index.md（插入顶部） - 284| - 更新 overview.md，添加 Multi-Agent Monitoring & Automation 段落，补充 [[Dynamic-Dashboard]] 和 [[Alerting]] 至 Key Concepts - 285| - 创建 2 个 Concept 页面：Dynamic-Dashboard.md、Alerting.md - 286| - 已有相关 Concept：[[Parallel-Agent-Execution]]（子代理并行）、[[Scheduled-Task-Flywheel]]（定时任务） - 287| - 已有相关 Entity：[[OpenClaw]]（多代理框架） - 288| - 冲突：与 [[content-factory]] 存在场景重叠（并行执行模式），但前者侧重数据监控，后者侧重内容创作 - 289| - 290|## [2026-04-22] ingest | Pre-Build Idea Validator - 291|- Source file: Agent/usecases/pre-build-idea-validator.md - 292|- Status: ✅ 成功摄入 - 293|- Summary: AI 项目启动前的竞争分析门控机制——在写代码之前通过 idea-reality-mcp 扫描 GitHub/Hacker News/npm/PyPI/Product Hunt 五个数据源，返回 reality_signal 分数（0-100）评估赛道拥挤度，防止 Agent 在已饱和赛道投入资源。 - 294|- Concepts created: [[Pre-Build Validation]], [[Reality-Signal]], [[Competition-Analysis]], [[Pivot-Strategy]], [[Agent-Build-Gate]] - 295|- Entities created: [[idea-reality-mcp]] - 296|- Source page: wiki/sources/pre-build-idea-validator.md - 297|- Notes: - 298| - 新增 Sources 条目至 index.md（插入顶部） - 299| - 更新 overview.md，添加 pre-build-idea-validator 段落并补充 4 个新概念至 Key Concepts - 300| - 创建 5 个 Concept 页面：Pre-Build-Validation.md、Reality-Signal.md、Competition-Analysis.md、Pivot-Strategy.md、Agent-Build-Gate.md - 301| - 创建 1 个 Entity 页面：idea-reality-mcp.md - 302| - Hacker-News 和 Product-Hunt 仅出现 1 次，不满足 ≥2 次的 Entity 创建阈值，未创建 - 303| - 与 market-research-product-factory 互补：后者挖痛点找方向，前者在动手前验证赛道的竞争密度 - 304| - 冲突：无 - 305| - 306|## [2026-04-22] ingest | Autonomous Project Management with Subagents - 307|- Source file: Agent/usecases/autonomous-project-management.md - 308|- Status: ✅ 成功摄入 - 309|- Summary: 去中心化多 Agent 项目协调模式——通过共享 STATE.yaml 实现并行自主执行，主会话遵循 CEO 模式（仅做策略决策），Git 作为审计日志记录所有状态变更。核心洞察：文件协调优于中心编排器，主会话越薄响应越快。 - 310|- Concepts created: [[PM Delegation Pattern]], [[CEO Pattern]], [[Shared State Coordination]], [[Git-as-Audit-Log]] - 311|- Entities created: [[Nicholas Carlini]] - 312|- Source page: wiki/sources/autonomous-project-management.md - 313|- Notes: - 314| - 新增 Sources 条目至 index.md（插入顶部） - 315| - 更新 overview.md，添加 4 个新概念至 Key Concepts - 316| - 创建 4 个 Concept 页面：PMDelegationPattern.md、CEOPattern.md、SharedStateCoordination.md、GitAsAuditLog.md - 317| - 创建 1 个 Entity 页面：NicholasCarlini.md - 318| - 冲突记录：与 [[project-state-management]] 的任务管理范式冲突（动态文件 vs 静态看板） - 319| - Nicholas Carlini 未在原 Wiki 中出现，作为启发来源创建 Entity 页面 - 320| - 321|- Source file: Agent/usecases/daily-reddit-digest.md - 322|- Status: ✅ 成功摄入 - 323|- Summary: AI Agent 驱动的 Reddit 每日精选摘要自动化——通过 OpenClaw + reddit-readonly skill，每日定时抓取多 Subreddit 热门帖子，AI 记忆偏好持续优化规则，纯读取模式无需认证。 - 324|- Concepts created: [[Daily-Digest]], [[Reddit Read-Only]], [[Preference Learning]] - 325|- Entities created: [[reddit-readonly]] - 326|- Source page: wiki/sources/daily-reddit-digest.md - 327|- Notes: - 328| - 更新 index.md，替换缺失标记为正式条目 - 329| - 更新 overview.md，添加至 YouTube Automation / Daily Digest 章节 - 330| - OpenClaw Entity 页面已存在，无需新建 - 331| - Preference Learning Concept 已在 inbox-declutter 中引用，无需新建 - 332| - 333|## [2026-04-22] ingest | Inbox De-clutter - 334|- Source file: Agent/usecases/inbox-declutter.md - 335|- Status: ✅ 成功摄入 - 336|- Summary: AI Agent 每日自动整理 Newsletter 邮件摘要——通过 Cron Job 每日 20:00 阅读过去 24 小时 Newsletter 新邮件，生成精华摘要并附链接，根据用户反馈持续学习偏好。需前置 Gmail OAuth Setup。 - 337|- Concepts created: [[Email Triage]], [[Newsletter Digest]], [[Preference Learning]] - 338|- Entities created: [[Gmail OAuth]] - 339|- Source page: wiki/sources/inbox-declutter.md - 340|- Notes: - 341| - 新增 Sources 条目至 index.md（插入顶部） - 342| - 更新 overview.md，添加 inbox-declutter 描述段落（作为 [[custom-morning-brief]] 的相似模式） - 343| - 创建 Concept 页面：Email-Triage.md、Newsletter-Digest.md、Preference-Learning.md - 344| - 创建 Entity 页面：Gmail-OAuth.md - 345| - 与 [[custom-morning-brief]] 属同一 Cron Job + AI 摘要模式的不同垂直场景 - 346| - 冲突：无 - 347| - 348|## [2026-04-22] ingest | Market Research & Product Factory - 349|- Source file: Agent/usecases/market-research-product-factory.md - 350|- Status: ✅ 成功摄入 - 351|- Summary: AI Agent 驱动的"从市场调研到产品构建"全自动化流水线——通过 Last 30 Days skill 挖掘 Reddit 和 X 近30天真实用户痛点，OpenClaw 根据痛点构建 Web 应用 MVP。核心价值：发短信即可完成"发现问题→验证需求→构建方案"全流程，无需技术背景。 - 352|- Concepts created: [[Pain Point Mining]], [[Startup MVP Pipeline]], [[Agent-Driven Market Research]], [[Last 30 Days Method]] - 353|- Source page: wiki/sources/market-research-product-factory.md - 354|- Notes: - 355| - 新增 Sources 条目至 index.md - 356| - 更新 overview.md，添加 Market Research & Product Factory 描述段落 - 357| - 添加 Pain Point Mining、Startup MVP Pipeline、Agent-Driven Market Research、Last 30 Days Method 到 Key Concepts - 358| - Alex Finn 出现2次（content-factory + market-research），但按出现频次标准不满足 Entity 创建条件，跳过 - 359| - Matt Van Horne 仅出现1次，跳过 Entity 页面创建 - 360| - 冲突：无已知冲突 - 361| - 362|## [2026-04-22] ingest | Phone-Based Personal Assistant - 363|- Source file: Agent/usecases/phone-based-personal-assistant.md - 364|- Status: ✅ 成功摄入 - 365|- Summary: 通过 ClawdTalk + Telnyx 将任意手机变成 AI 助理语音入口——拨打电话即可与 OpenClaw 对话，支持日历查询、Jira 任务更新、网络搜索，无需智能手机 App 或浏览器，覆盖驾驶、步行等双手占用场景。与 [[multi-channel-assistant]] 互补：文字入口覆盖图文交互，语音入口覆盖无屏场景。 - 366|- Concepts created: [[Voice Interface]], [[Telephony Integration]] - 367|- Entities created: [[ClawdTalk]], [[Telnyx]] - 368|- Source page: wiki/sources/phone-based-personal-assistant.md - 369|- Notes: - 370| - 新增 Sources 条目至 index.md（插入 Multi-Channel Personal Assistant 之后） - 371| - 更新 overview.md，添加 phone-based-personal-assistant 描述段落，添加 Voice Interface、Telephony Integration 到 Key Concepts - 372| - 创建 2 个 Entity 页面：ClawdTalk.md、Telnyx.md - 373| - 创建 2 个 Concept 页面：Voice-Interface.md、Telephony-Integration.md - 374| - 冲突已记录（已在 overview.md Conflict Area #10）：[[phone-based-personal-assistant]] 通用语音 Agent vs [[event-guest-confirmation]] SuperCall 沙盒 Persona - 375| - 376|## [2026-04-22] ingest | Event Guest Confirmation - 377|- Source file: Agent/usecases/event-guest-confirmation.md - 378|- Status: ✅ 成功摄入 - 379|- Summary: 基于 OpenClaw + SuperCall 的活动嘉宾自动确认方案——通过 AI 语音电话批量外呼客人，确认出席状态并收集备注（饮食禁忌、Plus-One、到达时间等），通话完成后生成出席确认/未出席/未接听三分类摘要。核心价值：真人电话比短信回复率高；SuperCall 沙盒 persona 设计确保安全隔离，无 Prompt Injection 风险；每通电话独立重置，无对话间信息混淆。 - 380|- Concepts created: [[Sandboxed Persona]] - 381|- Entities created: （无新实体；OpenClaw 已在其他来源中出现） - 382|- Source page: wiki/sources/event-guest-confirmation.md - 383|- Notes: - 384| - 新增 Sources 条目至 index.md（插入 Multi-Channel Personal Assistant 之后） - 385| - 更新 overview.md，添加 AI Tools & Productivity 小节描述 - 386| - 更新 overview.md Conflict Area #10，添加 SuperCall 沙盒 Persona vs 通用语音 Agent 对比 - 387| - 创建 1 个 Concept 页面：Sandboxed-Persona.md - 388| - 389|## [2026-04-22] ingest | Multi-Channel Personal Assistant - 390|- Source file: Agent/usecases/multi-channel-assistant.md - 391|- Status: ✅ 成功摄入 - 392|- Summary: 基于 Telegram Topic 路由 + OpenClaw 的多渠道个人助理方案——以 Telegram 为统一入口，通过 Topic 隔离不同上下文（config/updates/video-ideas/personal-crm/earnings/knowledge-base），整合 Google Workspace（gog）、Slack、Todoist、Asana，实现"说一句话完成全套工作"。核心价值：消除应用切换疲劳，AI 主动推送定时提醒。 - 393|- Concepts created: [[Topic-Based Routing]], [[Scheduled Reminder]] - 394|- Entities created: [[Asana]], [[gog]] - 395|- Source page: wiki/sources/multi-channel-assistant.md - 396|- Notes: 与 [[multi-agent-team]] 存在互补关系——Multi-Agent Team 为底层专业化分工，Multi-Channel Assistant 为用户交互层。 - 397| - 398|## [2026-04-22] ingest | Project State Management System: Event-Driven Alternative to Kanban - 399|- Source file: Agent/usecases/project-state-management.md - 400|- Status: ✅ 成功摄入 - 401|- Summary: 用事件驱动系统替代传统看板——自然语言对话自动记录项目事件（progress/blocker/decision/pivot），PostgreSQL/SQLite 存储完整事件历史，Git 提交自动关联项目，每日 Cron 生成站会报告。消灭手动拖拽卡片的摩擦，保留完整决策上下文，让项目状态查询和每日站会自动化。 - 402|- Concepts created: [[Event Sourcing]], [[Project State]] - 403|- Entities created: （无新实体；OpenClaw 已存在于多个来源中，无需独立 Entity 页面） - 404|- Source page: wiki/sources/project-state-management.md - 405|- Notes: - 406| - 新增 Sources 条目至 index.md（插入 Sources 首行） - 407| - 更新 overview.md Conflict Area #1，扩展 Kanban vs Event Sourcing 对比描述 - 408| - 创建 2 个 Concept 页面：EventSourcing.md、ProjectState.md - 409| - 冲突已记录：Event Sourcing（自动追踪+上下文保留）vs Kanban（可视化协作+团队同步） - 410|- Source file: Agent/usecases/health-symptom-tracker.md - 411|- Status: ✅ 成功摄入 - 412|- Summary: 通过 Telegram 话题 + OpenClaw AI Agent 自动追踪食物与症状，实现食物敏感性识别。每日三餐定时提醒（8AM/1PM/7PM）确保日志一致性，OpenClaw 自动解析消息并带时间戳写入 Markdown 日志，每周日分析关联模式识别潜在触发因素。无需专用 App，完全自托管。 - 413|- Concepts created: [[Food Sensitivity Tracking]], [[Automated Health Logging]] - 414|- Entities created: （无新实体；OpenClaw 实体已存在） - 415|- Source page: wiki/sources/health-symptom-tracker.md - 416|- Notes: - 417| - 新增 Sources 条目至 index.md（插入首行） - 418| - 新增健康追踪主题至 overview.md - 419| - 冲突记录：与 habit-tracker-accountability-coach 的习惯追踪 vs 健康数据追踪侧重对比 - 420| - 421| - 422|## [2026-04-22] ingest | Second Brain - 423|- Source file: Agent/usecases/second-brain.md - 424|- Status: ✅ 成功摄入 - 425|- Summary: AI Agent 作为个人第二大脑的记忆捕获与检索系统——通过短信/Telegram/Discord 零摩擦捕获任何内容，OpenClaw 永久记忆存储，Next.js 可搜索仪表盘提供全局检索。核心洞见：捕获像发短信一样简单，检索像搜索一样简单。灵感来源：Alex Finn YouTube 视频 + Tiago Forte《Building a Second Brain》。 - 426|- Concepts created: [[Zero-Friction Capture]], [[Cumulative Memory]], [[Conversational Interface]], [[Text-and-Search]] - 427|- Entities created: [[Tiago Forte]] - 428|- Entities updated: [[OpenClaw]]（追加 second-brain 到 sources）, [[Alex Finn]]（追加 second-brain 到 sources） - 429|- Source page: wiki/sources/second-brain.md - 430|- Notes: - 431| - 新增 Sources 条目至 index.md（替换 placeholder） - 432| - 更新 overview.md，添加 Second Brain 段落，补充 4 个新概念至 Key Concepts - 433| - 创建 4 个 Concept 页面：Zero-Friction-Capture.md、Cumulative-Memory.md、Conversational-Interface.md、Text-and-Search.md - 434| - 创建 1 个 Entity 页面：Tiago-Forte.md - 435| - 与 [[dataview-让我从"笔记黑洞"里逃出来的-obsidian-神器-1]] 存在冲突记录：Obsidian + Dataview（结构化查询）vs Second Brain（极简搜索）——互补而非互斥 - 436| - 与 [[custom-morning-brief]] 和 [[self-healing-home-server]] 属相似模式（零摩擦信息捕获 + AI 主动管理），已记录为 Connections - 437| - 与 [[habit-tracker-accountability-coach]] 的互补关系：Second Brain 管理想法/链接/书目，Habit Tracker 管理习惯行为——场景不同但方法论相似 - 438| - 冲突检测：无与其他已摄入来源的实质性内容冲突 - 439| - 440| - 441|- Status: ✅ 成功摄入 - 442|- Summary: AI Agent 作为家庭服务器基础设施的全天候自动驾驶代理——OpenClaw + SSH + Cron Job 系统实现自动健康监控、故障自愈（重启 Pod/扩缩容/修复配置）、邮件分拣、每日 8AM 晨报（天气/日历/系统状态/看板）、知识库录入和安全审计。核心洞察：Cron Job 是真正的产品；知识提取具有复利效应；AI 会硬编码 secrets，TruffleHog pre-push hooks 是必须配置的防线；Local-first Git 是防止 API Key 暴露的架构基础。 - 443|- Concepts created: [[Morning Briefing]], [[Email Triage]], [[Local-first Git]], [[Defense-in-Depth]] - 444|- Entities created: [[K3s]], [[Gitea]], [[TruffleHog]] - 445|- Entities updated: [[OpenClaw]]（追加 self-healing-home-server 到 sources） - 446|- Source page: wiki/sources/self-healing-home-server.md - 447|- Notes: - 448| - 新增 Sources 条目至 index.md（替换缺失条目） - 449| - 更新 overview.md，添加 "Self-Healing Infrastructure Agent" 章节 - 450| - 创建 3 个 Entity 页面：K3s.md、Gitea.md、TruffleHog.md - 451| - 创建 4 个 Concept 页面：Morning-Briefing.md、Email-Triage.md、Local-first-Git.md、Defense-in-Depth.md - 452| - 冲突已记录：Prometheus/Grafana 监控方案（人工介入）vs AI Agent 自愈方案（全自动闭环） - 453| - 454|## [2026-04-22] ingest | AI-Powered Earnings Tracker - 455|- Source file: Agent/usecases/earnings-tracker.md - 456|- Status: ✅ 成功摄入 - 457|- Summary: AI Agent 自动化追踪科技公司财报——每周日 Cron Job 扫描财报日历并通过 Telegram 推送，用户选择后为每家公司创建一次性 Cron Job，财报发布后自动搜索结果并生成结构化摘要（beat/miss、营收、EPS、AI 亮点）。 - 458|- Concepts created: （无新概念；Cron Job 已在其他来源中建立） - 459|- Entities created: （无新实体；OpenClaw 已存在；科技公司 NVDA/MSFT 等无需独立页面） - 460|- Source page: wiki/sources/earnings-tracker.md - 461|- Notes: - 462| - 新增 Sources 条目至 index.md（插入首行） - 463| - 无需更新 overview.md（与现有 OpenClaw + Cron Job 主题一致） - 464| - 无需创建 Entity/Concept 页面 - 465| - 无冲突 - 466| - 467|## [2026-04-23] ingest | Multi-Agent Specialized Team (Solo Founder Setup) - 468|- Source file: Agent/usecases/multi-agent-team.md - 469|- Status: ✅ 成功摄入 - 470|- Summary: 用多个专业化 AI Agent 组建团队，解决一人创业者（Solo Founder）身兼数职的困境——4 个专业 Agent（Milo/策略、Josh/商业、Marketing/营销、Dev/开发）通过共享记忆 + 私有上下文 + Telegram 单一控制平面协调运作，定时任务驱动主动工作流。 - 471|- Concepts created: [[Agent Personality]], [[Agent Specialization]], [[Shared Memory Architecture]], [[Private Context]], [[Single Control Plane]], [[Scheduled Task Flywheel]], [[Parallel Agent Execution]] - 472|- Entities updated: [[OpenClaw]]（追加 multi-agent-team 到 sources） - 473|- Source page: wiki/sources/multi-agent-team.md - 474|- Notes: - 475| - 新增 Sources 条目至 index.md（插入首行） - 476| - 更新 overview.md Key Concepts，添加 5 个新概念 - 477| - 创建 6 个 Concept 页面 - 478| - 更新 OpenClaw.md sources 字段 - 479| - 冲突已记录：Multi-Agent Team（并行专业化分工）vs Content Factory（链式协作） - 480| - 481|## [2026-04-23] ingest | Daily YouTube Digest - 482|- Source file: Agent/usecases/daily-youtube-digest.md - 483|- Status: ✅ 成功摄入 - 484|- Summary: AI Agent 每日 YouTube Digest 全自动流水线——通过 youtube-full skill（ClawHub）监控订阅频道新视频，用 TranscriptAPI.com 提取字幕，AI 生成要点摘要后推送。两种模式：频道列表 + 关键词搜索。`channel/latest` 免费检查，`seen-videos.txt` 避免重复付费。核心洞察：把算法推荐的"被动消费"转变为系统化的"主动学习"。 - 485|- Concepts created: [[Daily-Digest]], [[Transcript-Based Summarization]], [[Channel-Based Monitoring]], [[Keyword-Based Monitoring]], [[Credit-Efficient Processing]] - 486|- Entities updated: [[OpenClaw]]（追加 sources） - 487|- Entities created: [[TranscriptAPI.com]], [[ClawHub]], [[Recapio]] - 488|- Source page: wiki/sources/daily-youtube-digest.md - 489|- Notes: - 490| - 新增 Sources 条目至 index.md（顶部插入） - 491| - 更新 overview.md，补充 AI-Powered Daily Digest 章节到 YouTube Automation - 492| - 更新 OpenClaw.md sources - 493| - 创建 3 个 Entity 页面：TranscriptAPI.com.md、ClawHub.md、Recapio.md - 494| - 创建 5 个 Concept 页面：Daily-Digest.md、Transcript-Based-Summarization.md、Channel-Based-Monitoring.md、Keyword-Based-Monitoring.md、Credit-Efficient-Processing.md - 495| - 与 [[实战笔记-本地部署-rsshub-并获取-youtube-订阅]] 的互补关系已在 Contradictions 节记录（RSSHub 被动监控 vs AI Digest 主动学习） - 496| -- Source file: Agent/usecases/meeting-notes-action-items.md -- Status: ✅ 成功摄入 -- Summary: AI Agent 将会议转录文本（Otter.ai、Google Meet、Zoom）自动转换为结构化摘要，提取行动项并创建 Jira/Linear/Todoist/Notion 任务，发送 Slack/Discord 摘要，支持截止日提醒。核心洞察：自动任务创建比摘要本身更有价值，无法转化为追踪任务的会议记录只是"文档剧场"。 -- Concepts created: [[MeetingNotes]], [[ActionItemTracking]], [[TaskAutomation]], [[TranscriptProcessing]] - -## [2026-04-23] ingest | 14个免费的AI图生视频工具，用AI让图片动起来 -- Source file: AI/14个免费的AI图生视频工具，用AI让图片动起来 - AI视频教程 AI自动化工作流定制服务 AI培训学习平台 黑喵大叔.md -- Status: ✅ 成功摄入 -- Summary: 14个免费AI图生视频工具盘点——覆盖阿里巴巴（绘蛙、通义万相、万相营造）、字节跳动（即梦AI）、快手（可灵AI）、智谱AI（智谱清影）、MiniMax（海螺AI）、生数科技（Vidu）、爱诗科技（PixVerse）、潞晨科技（Video Ocean）、智象未来（Viva）、MewXAI（艺映AI）、Stability AI（Stable Video）等厂商。核心能力：文本提示词控制、动作模板、运镜参数、首尾帧控制、主体一致性、音效自动生成。电商/视频创作/广告三大应用场景。 -- Concepts created: [[AI图生视频]], [[AI文生视频]], [[主体一致性]], [[运镜控制]], [[首尾帧控制]], [[提示词控制]] -- Entities created: 14个工具均作为 Key Entities 记录于 Source 页面 -- Source page: wiki/sources/14个免费的ai图生视频工具-用ai让图片动起来-ai视频教程-ai自动化工作流定制服务-ai培训学习平台-黑喵大叔.md -- Notes: - - 更新 index.md，修正条目日期为 2025-12-05 并补充摘要描述 - - 更新 overview.md，新增 AI图生视频工具盘点章节 - - 创建 Concept 页面：AI图生视频.md、AI文生视频.md - - 所有14个工具作为 Key Entities 记录于 Source 页面，未创建独立 Entity 页面（每个工具仅出现1次，未达≥2阈值） - - Contradictions：无冲突 - -## [2026-04-23] ingest | 文字生成视频网站推荐 -- Source file: AI/文字生成视频网站推荐.md -- Status: ✅ 成功摄入 -- Summary: 5款文字生成视频AI工具推荐——万彩AI（完全免费，适合新手）、百度AI开放平台（大厂多模态技术）、Zeemo（多语言字幕，$79+）、Vizard（长视频自动剪辑）、快影（腾讯系模板剪辑）。总结推荐：最实惠选万彩AI，技术型选百度，多语言选Zeemo，长视频选Vizard。 -- Concepts created: [[文字生成视频]], [[AI视频生成工具]], [[数字人]] -- Source page: wiki/sources/文字生成视频网站推荐.md -- Notes: - - 新增 Sources 条目至 index.md（替换 expected 标记行） - - overview.md 中已存在与 [[AI图生视频工具盘点]] 的互补关系说明，无需更新 - - 所有工具作为 Key Entities 记录于 Source 页面，未创建独立 Entity 页面（每个工具仅出现1次，未达≥2阈值） - - Contradictions：无冲突 - -## [2026-04-23] ingest | 清华出的DeepSeek使用手册，104页，真的是太厉害了！（免费领取） -- Source file: AI/清华出的DeepSeek使用手册，104页，真的是太厉害了！（免费领取）.md -- Status: ✅ 成功摄入 -- Summary: 清华大学发布的《DeepSeek从入门到精通2025》官方使用手册（104页），由新闻与传播学院元宇宙文化实验室余梦珑博士后及团队撰写。手册核心价值在于"授人以渔"——不仅教用户"怎么问"，更教"为什么这么问"，帮助用户掌握提示词底层逻辑。涵盖 DeepSeek-R1 模型选择、提示语设计技巧、避免 AI 幻觉策略。内容实用性与理论深度兼备，适合不同层次读者。 -- Concepts created: [[DeepSeek-R1]], [[提示语设计]], [[AI幻觉]], [[通用人工智能（AGI）]], [[推理模型]] -- Entities created: [[DeepSeek]], [[余梦珑]] -- Source page: wiki/sources/清华出的deepseek使用手册-104页-真的是太厉害了-免费领取.md -- Notes: - - 新增 Sources 条目至 index.md（替换 expected 标记行） - - overview.md 新增 DeepSeek 使用手册条目，归入 AI Tools & Prompt Engineering 部分 - - 创建 Entity 页面：DeepSeek.md（公司）、余梦珑.md（作者） - - Concept 页面：RAG.md、Large-Language-Model.md、AI-Agent.md 已覆盖相关概念（幻觉、推理模型），无需新建 - - Contradictions：与 [[llms-rag-ai-agent-三个到底什么区别]] 互补而非冲突——前者聚焦 DeepSeek 特定实践，后者聚焦 LLM/RAG/Agent 三层架构宏观对比，均记录于 Contradictions 小节 - -## [2026-04-23] ingest | How to Get the RSS Feed For Any YouTube Channel -- Source file: AI/How to Get the RSS Feed For Any YouTube Channel.md -- Status: ✅ 成功摄入 -- Summary: 作者 Chuck Carroll 分享获取 YouTube 频道 RSS Feed 的简单方法——在频道页面右键选择"查看页面源代码"，搜索 `channel_id=`，提取 RSS Feed URL 格式为 `https://www.youtube.com/feeds/videos.xml?channel_id=`。无需第三方服务，适合 RSS 阅读器用户。 -- Concepts created: [[RSS Feed]], [[Channel ID]] -- Entities updated: [[YouTube]], [[Chuck Carroll]] -- Source page: wiki/sources/how-to-get-the-rss-feed-for-any-youtube-channel.md -- Notes: - - RSS Feed 和 Channel ID Concept 已存在于 overview.md 相关章节 - - YouTube Entity 已存在于 overview.md Key Entities 列表 - - 无需新建 Entity 或 Concept 页面 - - 无内容冲突 - -## [2026-04-23] ingest | codecrafters-io/build-your-own-x -- Source file: raw/AI/codecrafters-iobuild-your-own-x Master programming by recreating your favorite technologies from scratch.md -- Status: ✅ 成功摄入 -- Summary: GitHub 精选教程列表，26+ 技术领域分步骤指南，引用 Richard Feynman "What I cannot create, I do not understand" 作为核心理念，通过从零重建主流技术实现深度技术理解。 -- Entities created: CodeCrafters, DanielStefanovic, RichardFeynman -- Concepts created: Build-Your-Own-X, Learn-By-Building -- Source page: wiki/sources/codecrafters-iobuild-your-own-x-master-programming-by-recreating-your-favorite-technologies-from-scratch.md -- Notes: - - 冲突检测：BYOX vs 传统课程式学习（理论优先 vs 实践优先）已记录于 Source Page Contradictions - - index.md 和 overview.md 均已更新 - - 覆盖 26+ 领域：3D Renderer, Web Browser, Database, Docker, Git, OS, Programming Language, Neural Network 等 - - 支持 15+ 编程语言：C++, Python, Java, JavaScript, Go, Rust, Haskell, TypeScript 等 - - 与 Vibe Coding 互补：BYOX 理解原理，Vibe Coding 高效实现 - -## [2026-04-18] ingest | 电商如何选品 - 如何找到爆款选品策略 -- Source file: 跨境电商/电商如何选品 如何找到爆款 选品策略.md -- Status: ✅ 成功摄入 -- Summary: YouTube 视频摘要，20 种电商选品策略 + 情境配对 + 季节性规划 + POD 低成本测款 + 工具辅助分析（Salesmartly / Erank / Pinterest / Etsy 趋势）。核心观点：未来品牌需针对细分市场而非大众市场；情境配对产品组合提升客单价；POD 模式降低库存风险。 -- Concepts touched: [[电商选品策略]], [[爆款产品]], [[POD模式]], [[情境配对]], [[季节性选品]], [[细分市场定位]] -- Entities touched: [[Salesmartly]], [[Erank]], [[TikTok Shop]], [[Etsy]], [[Pinterest]] -- Source page: wiki/sources/电商如何选品-如何找到爆款-选品策略.md -- Notes: - - 新增 1 个 Source Page（wiki/sources/电商如何选品-如何找到爆款-选品策略.md） - - Concepts 和 Entities 均以 wikilink 形式建立关联，暂不创建独立页面 - - 冲突检测：与 [[做TK跨境思路不对努力白费]] 的平台优先级存在差异，但两者针对产品类型不同（Etsy/POD 手工艺 vs TikTok 快消品），属互补而非冲突 - - 已在 index.md 添加 Source 条目 - - 已在 overview.md TikTok E-commerce Operations 小节新增条目，置于 [[做TK跨境思路不对努力白费]] 之前 - -## [2026-01-26] ingest | 3.2 万人收藏的 Claude Skills，才是 AI 这条路上最值得研究的一套范式！ -- Source file: AI/3.2 万人收藏的 Claude Skills，才是 AI 这条路上最值得研究的一套范式！.md -- Status: ✅ 成功摄入（重复来源，slug 不同） -- Summary: Anthropic 官方 Skills 仓库（github.com/anthropics/skills）介绍；Skills = 说明书 + SOP；标志从「提示词工程」向「流程工程」的范式转变；Vibe Coding 尽头也是 Skills；三大聚合站和 Awesome-Claude-Skills 仓库推荐 -- Concepts identified: 无（已存在于之前摄取） -- Source page: wiki/sources/3-2-万人收藏的-claude-skills-才是-ai-这条路上最值得研究的一套范式.md -- Notes: - - 同来源文章以不同 slug 重复摄取（与 wiki/sources/3-2-万人收藏的-claude-skills-才是-ai-这条路上最值得研究的一套范式-1.md 内容完全一致） - - index.md 已添加新条目 - - 无需新建 Entity 或 Concept 页面 - - 无新内容冲突 - -## [2026-04-26] ingest | Building your Quartz -- Source file: Home Office/Building your Quartz -- Status: ✅ 成功摄入 -- Summary: Quartz 静态网站的本地预览与自托管部署指南。涵盖 `npx quartz build --serve` 本地热重载预览、Nginx/Apache/Caddy 三种 Web 服务器自托管配置（处理无扩展名链接）、baseUrl 配置对 RSS Feed 和 Sitemap 的影响。Obsidian 笔记 → Quartz 构建 → 自托管构成完整个人知识发布链条。 -- Concepts touched: [[Quartz]], [[Static Site Generator]], [[npx quartz build]], [[try_files]], [[RewriteRule]], [[baseUrl]] -- Entities touched: [[Obsidian]], [[GitHub Pages]] -- Source page: wiki/sources/building-your-quartz.md -- Notes: - - 新增 1 个 Source Page（wiki/sources/building-your-quartz.md） - - Concept 和 Entity 均以 wikilink 形式建立关联，Quartz/Nginx/Apache/Caddy 均已在 overview.md 中被提及，不创建独立页面 - - 检测到 1 处潜在冲突（自托管 vs Vercel/Netlify），已记录于 Source Page Contradictions 节 - - index.md Sources 节添加新条目 - - overview.md Productivity & Knowledge Management 部分添加 Quartz 段落 - -## [2026-04-23] ingest | 我做了个 Skill：让 AI 帮你生成 Logo 和图标 -- Source file: raw/Skills/我做了个 Skill：让 AI 帮你生成 Logo 和图标.md -- Status: ✅ 成功摄入 -- Summary: 介绍 Claude Code Skill `baoyu-imagine`（`npx baoyu-imagine` 安装），通过 Logo 专用提示词策略驱动 AI 生图工具生成专业 Logo 和图标。支持扁平化/几何/手绘/渐变等多种风格，SVG（矢量）和 PNG 格式导出。让非设计师快速产出专业品牌视觉资产。 -- Concepts created: AI-Logo-Generation -- Entities created: baoyu -- Source page: wiki/sources/我做了个-skill-让-ai-帮你生成-logo-和图标.md -- Notes: - - 新增 1 个 Source Page（wiki/sources/我做了个-skill-让-ai-帮你生成-logo-和图标.md） - - 新增 1 个 Concept 页面（AI-Logo-Generation） - - 新增 1 个 Entity 页面（baoyu） - - index.md Sources / Entities / Concepts 三个章节均已追加条目 - - overview.md AI Tools & Prompt Engineering 部分添加 baoyu-imagine AI Logo 生成段落，Key Concepts 追加 baoyu-imagine / AI-Logo-Generation / Claude-Code-Skill - - 无内容冲突（baoyu-imagine 与通用 AI 生图工具形成互补） - -## [2026-04-16] ingest | Obsidian CLI -- Source file: raw/Skills/Obsidian CLI.md -- Status: ✅ 成功摄入 -- Summary: Obsidian v1.12+ 内置的官方命令行工具文档，覆盖 60+ 命令（日常操作/文件管理/插件管理/属性操作/开发者命令/版本管理/发布/同步等），提供 TUI 交互模式和单命令两种使用方式。开发者命令通过 Chrome DevTools Protocol 实现截图、控制台执行、插件热重载。AI Agent 可通过标准化 CLI 接口实现笔记增删改查、日程管理、搜索、任务操作等全部 GUI 功能，无需图形界面。 -- Concepts updated: [[Obsidian-CLI]]（补充 8 大能力域：日常操作/文件管理/插件管理/属性操作/开发者命令/版本管理/工作区管理/TUI 交互） -- Entities updated: [[Obsidian]]（添加 obsidian-cli 来源引用，更新 last_updated） -- Source page: wiki/sources/obsidian-cli.md -- Notes: - - 新增 1 个 Source Page（wiki/sources/obsidian-cli.md） - - 更新 Obsidian-CLI concept 页面，补充 8 大能力域和 TUI 交互模式说明 - - 更新 Obsidian entity 页面，添加 sources 字段 - - 更新 wiki/index.md Sources 节（新增 Obsidian CLI 条目，置顶） - - 更新 wiki/overview.md Productivity & Knowledge Management 部分（补充 Obsidian-CLI 与其他 Agent 集成方案的互补关系） - - 冲突记录：与 [[obsidian-必装-skills]] 中 obsidian-cli 的描述存在"官方内置"vs"kepano 发布 Skill"的视角差异，已记录至 Source Page Contradictions，结论为两者均正确（obsidian-cli 既是 Obsidian 官方内置功能，也是 kepano Skills 项目收录整理的工具） - - 新建 Concept/Entity 页面：无（Obsidian-CLI concept 页面已于 2026-04-21 创建，本次仅更新内容；Obsidian entity 页面已存在，本次仅更新 sources 字段） - -## [2026-04-23] ingest | WSL2 启动与网络配置指南 -- Source file: raw/Home Office/WSL2 启动与网络配置指南.md -- Status: ✅ 成功摄入 -- Summary: WSL2（Windows Subsystem for Linux 2）安装启动与网络配置实操指南。核心内容：① wsl --install 快速安装 Ubuntu；② .wslconfig 启用 networkingMode=mirrored 镜像网络模式解决 localhost 代理失效问题；③ 终端环境变量手动配置代理；④ ghproxy.com 反向代理加速 GitHub 下载。关键洞察：NAT 模式是 WSL2 无法访问 Windows 宿主机代理的根本原因，镜像网络模式是推荐解决方案。 -- Concepts created: WSL2、镜像网络模式、NAT模式、ghproxy -- Entities created: WSL2、ghproxy -- Source page: wiki/sources/wsl2-启动与网络配置指南.md -- Notes: - - 新增 1 个 Source Page（wsl2-启动与网络配置指南.md） - - 更新 wiki/index.md（Sources 章节补全缺失条目） - - 更新 wiki/overview.md（Home Server Automation 部分新增 WSL2 章节段落；Key Entities 部分新增 WSL2 和 ghproxy 条目） - - 无内容冲突 - - 新建 Concept/Entity 页面：无（WSL2 和 ghproxy 作为 Entity/Concept 在 overview.md 中描述，未创建独立页面） - -## [2026-04-24] ingest | Blogwatcher Daily 技能收藏 -- Source file: Skills/blogwatcher-daily收藏.md -- Status: ✅ 成功摄入 -- Summary: Hermes Agent 自定义 Skill `blogwatcher-daily` 的收藏笔记，实现 31 个 RSS/YouTube 订阅频道的自动化监控与每日摘要生成。通过 SQLite 数据库按 URL 去重，日常扫描追加写入 `YYYY-MM-DD.md` 日报，强制回扫写入独立文件。YouTube 频道通过本地 RSSHub 代理转换为 RSS Feed。 -- Concepts created: 无（RSS Monitoring、Cron Job、RSSHub、每日日报 等均为已有或通用概念，在 overview.md Key Concepts 中已有覆盖） -- Entities created: 无（blogwatcher-daily 作为 Skill 名在 sources 中描述；feedparser 仅出现1次，不满足 ≥2 次创建条件） -- Source page: wiki/sources/blogwatcher-daily收藏.md -- Notes: - - 新增 1 个 Source Page - - 更新 wiki/index.md（Sources 章节补全缺失条目） - - 更新 wiki/overview.md（YouTube Automation 部分 RSSHub 段落新增对 blogwatcher-daily 的关联说明） - - 无内容冲突 - - 新建 Concept/Entity 页面：无 - -## [2026-04-23] ingest | CTP Topic 1 Gruntwork Landing Zone Architecture -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-1-gruntwork-landing-zone-architecture.md -- Status: ✅ 成功摄入 -- Summary: Gruntwork AWS Landing Zone 架构基础培训。核心：参考架构（Reference Architecture）是包含核心账户（Shared/Logs/Security）和工作负载账户（Prod/Stage/Dev）的最佳实践起点；Landing Zone 基于 Gruntwork 由产品团队自行定义具体服务；安全账户使用联邦用户（Federated User）通过 AD 组映射到 IAM 角色；每个 Landing Zone 配置独立 Jenkins 服务器和特性分支 Git 工作流；Terraform AWS 服务目录强调服务应具有业务上下文。 -- Concepts created: Reference-Architecture, Landing-Zone-Architecture, Federated-Access, CI-CD-Pipeline, Terraform-Modules -- Entities created: 无（Gruntwork Entity 已存在） -- Source page: wiki/sources/ctp-topic-1-gruntwork-landing-zone-architecture.md -- Notes: - - 新增 1 个 Source Page - - 更新 wiki/index.md（Sources 章节替换预期条目为实际摘要；Concepts 章节新增 5 个概念） - - 更新 wiki/overview.md（Cloud Transformation 部分新增 CTP Topic 1 段落） - - 冲突检测：与 ctp-topic-35-aws-landing-zone-design-refresher-saas-labs 在 Landing Zone 产品定义粒度上有视角差异（前者强调灵活性，后者强调标准化），已记录于 Source Page Contradictions 节，判定为视角互补而非直接冲突 - - 新建 Concept 页面：5 个（Reference-Architecture / Landing-Zone-Architecture / Federated-Access / CI-CD-Pipeline / Terraform-Modules） - - 新建 Entity 页面：无（Gruntwork Entity 已存在，无需重复创建） - -## [2026-04-14] ingest | CTP Topic 73 AWS Backup Implementation of the Cloud Transformation Programme -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program.md -- Status: ✅ 成功摄入 -- Summary: AWS Backup 在云转型计划中的企业级实施落地。SRE 团队开发 SRE Backup Model，为产品组提供预置的 AWS Backup Plans、Vaults、KMS 密钥策略等模板，支持 DRA 账户内独立备份和恢复；初始备份复制到远程 DR 账户实现即时恢复；AWS Backup Audit Manager 提供合规审计报告和控制评估。 -- Concepts created: [[SRE Model]] -- Source page: wiki/sources/ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program.md -- Notes: - - 新增 1 个 Source Page - - 新增 1 个 Concept（SRE Model） - - index.md 更新：Sources 节新增条目，附中文摘要 - - 冲突检测：与 [[ctp-topic-44-aws-backup-in-micro-focus]] 视角互补而非冲突——前者为 CTP 实施确认，后者为内部评估，AWS Backup 的局限性已在 Contradictions 节记录 - - AWS Backup / AWS Backup Audit Manager / 跨账户备份 已在 ctp-topic-72 摄入，无需重复创建 - -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-28-aws-tag-validation-tool.md -- Status: ✅ 成功摄入 -- Summary: Lewis Brown 主讲，SRE 团队开发的 AWS 标签验证工具。Checkpoint 防火墙通过读取 EC2/安全组/负载均衡器标签值配置网络访问策略，标签缺失或无效时拦截流量；SCPs 只能阻止新资源创建，无法修复存量资源。该工具通过 variables.yaml 定义每个账户合法标签值，自动扫描 EC2/SG/LB/Lambda，比对配置输出 CSV 审计报告。使用 Poetry 管理 Python 环境，存放于 SRE Tools Repository。标签还计划用于成本核算。 -- Entities created: [[Checkpoint]], [[SRE-Team]] -- Concepts created: [[AWS-Tags]], [[AWS-Tagging-Standards]], [[Tag-Validation-Tool]], [[Service-Control-Policies-SCPs]], [[Variables-YAML]] -- Source page: wiki/sources/ctp-topic-28-aws-tag-validation-tool.md -- Notes: - - 新增 1 个 Source Page - - 新增 2 个 Entity（Checkpoint / SRE-Team） - - 新增 5 个 Concept（AWS-Tags / AWS-Tagging-Standards / Tag-Validation-Tool / Service-Control-Policies-SCPs / Variables-YAML） - - overview.md 更新：新增 CTP Topic 28 摘要段落（置于 ctp-topic-17 之后，ctp-topic-47 之前），Key Concepts 节新增 6 个概念标注（AWS-Tagging-Standards / Tag-Validation-Tool / Service-Control-Policies-SCPs / Variables-YAML / Checkpoint-Firewall / SRE-Tools-Repository） - - index.md 更新：Sources 节替换预期条目为实际摘要，Entities 节新增 2 个实体，Concepts 节新增 6 个条目 - - 冲突检测：与 [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] 互补而非冲突——后者聚焦标签收集机制和安全策略上下文，前者聚焦审计发现，共同构成"制定规范 → 强制执行 → 审计发现"的标签治理闭环 - - Lewis Brown 仅出现 1 次，未创建 Entity 页面 - -## [2026-04-14] ingest | CTP Topic 10 AWS Landing Zone (LZ) Data Collection, Tagging Related Security -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md -- Status: ✅ 成功摄入 -- Summary: Steve Jarman 和 Pradeep 主讲 AWS Landing Zone 部署流程、数据收集策略与基于标签的云原生安全架构。核心：①Landing Zone 部署前需了解 BU 资产清单/IP 地址空间/数据敏感性；②DNS/Transit Gateway 等基础服务已通过 SRE 高度自动化；③基于标签的安全控制——用 AWS 标签替代传统 IP 防火墙规则；④SCP 强制执行标签规范——通过"显式拒绝"防止篡改标签绕过审计；⑤Checkpoint 防火墙有序层——按优先级执行地理屏蔽 → BU 隔离 → 产品隔离 → 环境隔离。 -- Concepts created: 无（所有概念均已在 [[ctp-topic-28-aws-tag-validation-tool]] 中创建） -- Source page: wiki/sources/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md -- Notes: - - 新增 1 个 Source Page - - 无新增 Concept（[[AWS_Landing_Zone]] / [[Tagging_Methodology]] / [[SCP_Service_Control_Policy]] / [[OU_Organizational_Unit]] / [[Checkpoint_Firewall_Ordered_Layer]] / [[Transit_Gateway]] / [[SRE_Automation]] 均已在 ctp-topic-28 中创建） - - overview.md 更新：新增 CTP Topic 10 摘要段落（置于 ctp-topic-1 之后），补充标签治理闭环描述 - - index.md 更新：Sources 节新增条目（置顶） - - 冲突检测：无冲突 - - Steve Jarman 仅出现 1 次，Pradeep 仅出现 1 次，均未创建 Entity 页面 - - 与 [[ctp-topic-1-gruntwork-landing-zone-architecture]] 互补——前者为基础架构，后者为安全层扩展 - - 与 [[ctp-topic-28-aws-tag-validation-tool]] 互补——构成"制定规范 → 强制执行 → 审计发现"的标签治理闭环 - -## [2026-04-14] ingest | CTP Topic 25 Labs Landing Zone Overview - ITOM Teams -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-25-labs-landing-zone-overview-itom-teams.md -- Status: ✅ 成功摄入 -- Summary: Labs Landing Zone 基于 Gruntwork 参考架构的多账户策略——核心账户包括 Shared（Jenkins 主节点/加固 AMI/容器仓库）、Logs（CloudTrail/Config 日志）、Security（联邦用户/跨账户访问）、Core（AD 管理 Windows 实例和 IDP/DNS 管理 Swimford.net）、Network（Transit Gateway + JetPult 防火墙/标签驱动的网络策略/Pulse VPN）；Shared Services 提供 45 Arc Site 监控和 Qualys 漏洞扫描；Product Account 通过 Terraform/Terragrunt 模块部署，需与网络团队协调 IP 范围和标签策略；Jenkins 流水线扫描 GitHub Enterprise 仓库变更，触发 Terragrunt plan/apply，并通过 pre-commit 和 Fortify 扫描提升安全。 -- Concepts created: 无（所有概念均已在其他 CTP 页面中创建：[[Landing Zone Architecture]] / [[Terraform]] / [[Terragrunt]] / [[Jenkins]] / [[Transit Gateway]] / [[Federated Access]] / [[Tag-Based Access Control]]） -- Source page: wiki/sources/ctp-topic-25-labs-landing-zone-overview-itom-teams.md -- Notes: - - 新增 1 个 Source Page - - 无新增 Concept/Entity（Gruntwork/Jenkins/JetPult/Pulse VPN/Qualys/45 Arc Site 均仅出现 1 次，不满足 ≥2 次建页条件） - - overview.md 更新：新增 CTP Topic 25 摘要段落（置于 ctp-topic-35 之前），补充 Labs LZ 运维实践描述 - - index.md 更新：Sources 节新增条目（置顶于 CTP Topic 34 之前），移除旧 "source missing" 标记 - - 冲突检测：无冲突 - - 属 [[ctp-topic-1-gruntwork-landing-zone-architecture]]（架构基础）和 [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]]（SaaS vs Labs 职责划分）共同构成完整的 AWS Landing Zone 知识体系 - -## [2026-04-24] ingest | Public Cloud Learning Sessions - Tagging Standards for All Hyperscalers - 20240123 -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-tagging-standards-for-all-hyperscalers-20240123-1.md -- Status: ✅ 成功摄入 -- Summary: OpenText 跨 AWS/Azure/GCP 的统一标签标准，目标将云浪费从 30% 降至 15%，预计年节省 2500 万美元。标准采用 OT_ 前缀标签、GCP 限制性字符集作为最低通用标准，通过 Terraform 默认标签注入和 SCP 强制执行实现合规化。 -- Concepts referenced: [[FinOps]], [[Service-Control-Policies-SCPs]], [[Tag-Based-Security]], [[Terraform-Tagging]], [[Multi-Cloud-Governance]]（均已在其他页面定义，无需新建） -- Entities referenced: [[Tom Bice]]（仅出现 1 次，不满足 ≥2 次建页条件，未创建独立页面） -- Source page: wiki/sources/public-cloud-learning-sessions-tagging-standards-for-all-hyperscalers-20240123-1.md -- Notes: - - 新增 1 个 Source Page - - 无新增 Concept/Entity 页面 - - index.md 更新：移除 "source missing" 标记，添加正式条目 - - 冲突检测：无冲突 - - 属 [[public-cloud-learning-sessions-opentext-tagging-standard-v2]]（v2 扩展 v1，覆盖 K8s 和容器镜像标签）、[[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]]（基于标签的安全控制机制）、[[ctp-topic-28-aws-tag-validation-tool]]（标签合规审计）共同构成完整的标签治理知识体系 - -## [2026-04-25] ingest | Public Cloud Learning Sessions (OpenText) - Product Hub (PHT) Overview and Q&A - 20240806 -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-opentext-product-hub-pht-overview-and-qa-20240806.md -- Status: ✅ 成功摄入 -- Summary: OpenText Product Hub（PhD/PHT）产品层次结构追踪器功能概述——三层层级（业务单元→业务线→产品）、自助服务新建流程、与 Jira/Value Edge/PSMQ/ITLS/OSS 等外部系统集成、Source Repo 和 Artifact Repo 权限管理。 -- Concepts created: [[Product Hub (PhD)]]（已引用） -- Entities created: 无（OpenText 相关 Entity 仅出现 1 次，不满足 ≥2 次建页条件） -- Source page: wiki/sources/public-cloud-learning-sessions-opentext-product-hub-pht-overview-and-qa-20240806.md -- Notes: - - 新增 1 个 Source Page - - 无新增 Concept/Entity 页面 - - index.md 更新：移除 "source missing" 标记，添加正式条目 - - 冲突检测：无冲突 - -## [2026-04-30] ingest | Learning Sessions Identity Governance VSM Replacement - 20231128 -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/02_IAM/learning-sessions-identity-governance-vsm-replacement-20231128-160326-meeting-re.md -- Status: ✅ 成功摄入 -- Summary: 身份治理（Identity Governance）框架与 VSM→Micro Focus IGA 替换计划——身份治理三问：谁当前有访问/谁该访问/如何访问；Micro Focus IGA 通过 AD 组工作流管控权限审批，配合 AWS Identity Center + IAM 提供云资源访问；VSM 将被 IGA 全面替换，保持原架构但改接 Coptum 域，POC 正在进行。 -- Concepts created: [[Identity-Governance]] -- Entities created: [[Micro-Focus-IGA]], [[DXC-VSM]] -- Source page: wiki/sources/learning-sessions-identity-governance-vsm-replacement-20231128-160326-meeting-re.md -- Notes: - - 新增 1 个 Source Page - - 新增 1 个 Concept 页面（wiki/concepts/Identity-Governance.md） - - 新增 2 个 Entity 页面（wiki/entities/Micro-Focus-IGA.md, wiki/entities/DXC-VSM.md） - - index.md 更新：移除 "source missing" 标记，添加正式条目；在 Entities 和 Concepts 节添加新页面 - - overview.md 新增条目，位于 CTP Topic 17（AD 集成）之后 - - 冲突检测：无已知冲突内容 - -## [2026-04-25] ingest | CTP Topic 60 Monitor AWS using Hyperscale Observability with Grafana -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana.md -- Status: ✅ 成功摄入 -- Summary: 使用 Grafana Enterprise + Optic DR 数据源 + Opsbridge 告警 + Terraform IaC 模块实现 AWS 超大规模可观测性监控——推荐迁移至 Enterprise License 释放完整功能；Optic DR（VaticaDB 插件）是 Grafana 从 AWS 拉取数据的关键中间件；Terraform 模块为产品团队自动化创建 Grafana Organizations、用户、文件夹和仪表盘；EC2 Inventory 仪表盘可识别运行/未运行 EC2 实例及标签合规状态。 -- Concepts identified: [[Grafana-Enterprise]], [[Observability（可观测性）]], [[Opsbridge]], [[Optic-DR]], [[Terraform-Module]], [[Resource-Tagging]] -- Entities identified: [[Grafana-Labs]], [[VaticaDB]], [[PagerDuty]], [[Slack-Manager]]（均以 wikilink 形式记录于 Source page，无需独立页面） -- Source page: wiki/sources/ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana.md -- Notes: - - 新增 1 个 Source Page（wiki/sources/ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana.md） - - 无新增 Concept/Entity 页面（已识别概念均作为 wikilink 嵌入 Source page） - - index.md 更新：在 Sources 节顶部添加新条目 - - 冲突检测：与 ctp-topic-42-grafana-observability-dashboard 存在潜在张力（开源版 vs Enterprise License） - -## [2026-04-25] ingest | CTP Topic 70 EKS deployment using IAC -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-70-eks-deployment-using-iac.md -- Status: ✅ 成功摄入 -- Summary: EKS 集群通过 IaC（Terraform + Service Catalog）部署的完整方法论——两种部署路径（Terraform `tera-grant.scl` vs Service Catalog 模块）、EMI 自定义网络解决 VPC CIDR 限制、Cluster Autoscaler 自动扩缩容 Worker Node、CloudWatch Agent + FluentBit + Container Insights + OpenTelemetry + Grafana 完整监控栈。 -- Concepts created: [[Amazon EKS]], [[Cluster Autoscaler]], [[Infrastructure as Code]], [[Kubernetes]]（已有 entity，新增 source 引用） -- Entities updated: [[Kubernetes]]（添加 source 引用） -- Source page: wiki/sources/ctp-topic-70-eks-deployment-using-iac.md -- Notes: - - 新增 1 个 Source Page（wiki/sources/ctp-topic-70-eks-deployment-using-iac.md） - - 新增 3 个 Concept 页面：Amazon EKS、Cluster Autoscaler、Infrastructure as Code - - Kubernetes entity 页面已存在，更新添加新 source 引用 - - index.md 更新：在 Sources 节顶部添加新条目；在 Concepts 节添加 3 个新条目；移除 "source missing" 标记 - - overview.md 更新：添加新条目，位于 EKS Auto Mode 条目之后 - - 冲突检测：与 ctp-topic-59-achieving-reliability-with-amazon-eks 可能存在内容重叠（侧重点不同：Topic 70 侧重部署方法，Topic 59 侧重可靠性实践） - -## [2026-04-27] ingest | Public Cloud Learning Sessions - Observability with OpenTelemetry -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113-.md -- Status: ✅ 成功摄入 -- Summary: Jay Comer（AWS 解决方案架构师）主讲 OpenTelemetry 可观测性全景——三信号模型（Metrics/Logs/Traces）、OTLP 协议 + 11 种语言 SDK + Collector 架构、AWS Distribution for OpenTelemetry（统一代理 + EKS Operator 自动注入）、Fluent Bit → OTel Collector（端口 55681）→ Amazon OpenSearch 端到端管道演示。 -- Concepts created: [[OpenTelemetry]], [[Observability（可观测性）]], [[Three Signals]], [[OTLP（OpenTelemetry Protocol）]], [[Fluent Bit]] -- Entities identified: [[Jay Comer]] -- Source page: wiki/sources/public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113.md -- Notes: - - 新增 1 个 Source Page - - index.md 更新：新增条目（日期 2024-04-02） - - overview.md 更新：新增条目于 Cloud Transformation & DevOps → EKS 知识链路；Key Concepts 新增 5 个条目 - - 新增 Entity 页面：Jay-Comer.md - - 新增 Concept 页面：OpenTelemetry.md - - 冲突检测：与 ctp-topic-54-esm-saas-log-analytics（ELK 日志）、ctp-topic-67（CTP Topic 67 OpenTelemetry）互补，无冲突 - -## [2026-04-25] ingest | CTP Topic 33 An Introduction to GitOps -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-33-an-introduction-to-gitops.md -- Status: ✅ 成功摄入 -- Summary: GitOps 方法论入门——将软件开发原则应用于部署流程；四大原则（声明式配置 + 版本控制 + CD 流程分离 + 自修复协调器）；Pull 模型优于 Push 模型；幂等平台（Kubernetes）是 CD 顺利运行的必要条件；Git 提交日志即合规审计追踪 -- Concepts created: [[GitOps]] -- Entities identified: [[Victor Etkin]] -- Source page: wiki/sources/ctp-topic-33-an-introduction-to-gitops.md -- Notes: - - 新增 1 个 Source Page - - 新增 1 个 Concept 页面：GitOps.md（覆盖四大原则、Pull vs Push 模型、与 IaC 关系） - - index.md 更新：新增条目于 CI_CD_GitOps 分类 - - overview.md 更新：新增条目于 Cloud Transformation & DevOps 章节，GitOps 知识链路 - - Key Entities 中提及的 Victor Etkin 仅出现 1 次，不满足 ≥2 次条件，以 wikilink 形式记录于 Source page - - Key Concepts 中 Kubernetes/Atlantis 已有 wikilink 指向其他 Source page - - 冲突检测：与 ctp-topic-39（Atlantis 不支持 EKS）存在 Atlantis + Kubernetes 实践约束差异，已记录于 Source page Contradictions - -## [2026-04-24] ingest | CTP Topic 56 Automated Infrastructure Testing -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-56-automated-infrastructure-testing.md -- Status: ✅ 成功摄入 -- Summary: Mark Francis 主讲自动化基础设施测试，倡导将 TerraTest（Golang 框架）应用于 Terraform IaC 的 apply → test → destroy 自动化验证循环；核心主张集成测试超越语法检查，TDD 应用于 IaC 领域，测试作为首要开发步骤；价值观："让机器做重复的事，把人脑留给复杂的人类问题" -- Concepts identified: [[Infrastructure Testing]], [[TerraTest]], [[Test-Driven Development (TDD)]], [[IaC Testing Framework]] -- Source page: wiki/sources/ctp-topic-56-automated-infrastructure-testing.md -- Notes: - - index.md 更新：新增条目于 CTP Topic 33 (GitOps) 之后 - - overview.md 更新：新增条目于 Cloud Transformation & DevOps 章节，GitOps 和 CI/CD Pipeline 质量保障层 - - Key Entities 中 Mark Francis 仅出现 1 次，不满足 ≥2 次条件，以 wikilink 形式记录于 Source page - - Key Concepts 中 Kubernetes/Atlantis 已有 wikilink 指向其他 Source page - - 冲突检测：与 ctp-topic-39（Atlantis 不支持 EKS）存在 Atlantis + Kubernetes 实践约束差异，已记录于 Source page Contradictions - -## [2026-04-24] ingest | CTP Topic 71 PCG's guide to RightSizing, why, how when -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/ctp-topic-71-pcgs-guide-to-rightsizing-why-how-when.md -- Status: ✅ 成功摄入 -- Summary: PCG 团队讲解 AWS EC2 RightSizing 系统性方法论——为何要做、何时做、如何执行。RightSizing 通过分析实例实际资源使用情况，将过度配置的实例调整为合适规格，在不影响性能前提下实现成本节省。⚠️ 视频尚未完成 Whisper 转录，完整内容待补充 -- Concepts created: RightSizing, EC2 Cost Optimization -- Source page: wiki/sources/ctp-topic-71-pcgs-guide-to-rightsizing-why-how-when.md -- Notes: - - index.md 更新：将原 expected placeholder 更新为正式条目（2026-04-14） - - overview.md 更新：新增条目于 Cloud Transformation & DevOps 章节 FinOps 知识链路 - - RightSizing/Cloud Cost Optimization 已通过 wikilink 嵌入 Source page - - Key Entities: PCG (Platform Control Group) 已在 Wiki 中存在（ctp-topic-13），无需新建 Entity 页面 - - 冲突检测：未发现内容冲突，Contradictions 暂置空占位 - -## [2026-05-06] ingest | Public Cloud Learning Sessions (OpenText) - Generative AI & Prompt Engineering - 20241112 -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111.md -- Status: ✅ 成功摄入 -- Summary: AWS 生成式 AI 服务与提示工程实践，由 OpenText 技术客户经理 Shikad Holtzman（以色列）主讲——生成式 AI 四大价值路径、企业数据差异化核心洞见、Amazon Bedrock 全托管基础模型服务（RAG/微调/Agents/Guardrails）、Amazon Q 助手（企业版/开发者版）、AWS 专用芯片（Trainium/Inferentia）、提示工程四组件（指令/上下文/用户输入/输出指示器）和基础技巧（One-shot/Few-shot、Chain of Thoughts） -- Concepts linked: [[RAG]], [[Prompt-Engineering]], [[Chain-of-Thought]], [[One-Shot-Prompting]], [[Few-Shot-Prompting]], [[Responsible-AI]], [[Guardrails-for-Amazon-Bedrock]] -- Entities linked: [[Shikad-Holtzman]], [[Amazon-Bedrock]], [[Amazon-SageMaker]], [[Amazon-Q]], [[AWS-Trainium]], [[AWS-Inferentia]], [[AWS]] -- Source page: wiki/sources/public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111.md -- Notes: - - index.md 已更新：将原 expected placeholder 更新为正式条目（2026-04-19），补充中文摘要 - - overview.md 已更新：在 Cloud Transformation & DevOps 章节的 AI/ML 入门条目后新增独立段落，与 AI/ML 入门共同构成生成式 AI 知识链路 - - Key Concepts：RAG/Prompt-Engineering/Chain-of-Thought/Few-Shot-Prompting 频次不足独立建 Concept 页阈值，以 wikilink 形式记录于 Source page - - Key Entities：Shikad Holtzman 仅出现 1 次，以 wikilink 形式记录于 Source page；Amazon Bedrock/Q/SageMaker 在同系列其他来源中提及频次不足独立建 Entity 页阈值 - - 同系列来源关联：已建立与 AI/ML 入门（public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin）和无服务器计算（public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee）的 Connections 关系 - - 冲突检测：与 ctp-topic-64-scaling-out-with-amazon-eks 在扩展方式上的差异已记录于 Source page Contradictions（EDA 事件驱动 vs EKS 容器编排，适用于不同场景可互补） - -## [2026-05-06] ingest | Learning Sessions Cloud Transformation Programme-Deploying RDS via Terraform -- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform.md -- Status: ✅ 成功摄入 -- Summary: Greg（DBRE 团队）讲解通过 Terraform/Terragrunt 在 AWS 部署 RDS——IaC 六大优势（速度/灵活性/一致性/灾难恢复/文档/自动化）；代码即文档；grunt work RDS Service 推荐生产使用（预建 KMS 加密 + CloudWatch 告警），SRE 核心模块功能弱于 grunt work；Terragrunt 保持代码整洁、避免变量重复；Day 2 运维通过 GitHub PR + Atlantis 实现；CloudWatch Dashboard + Alarms 监控告警，注意突发性能实例 CPU credits -- Concepts linked: [[Infrastructure-as-Code]], [[DRY Principle]], [[GitOps]], [[CloudWatch-Alarms]], [[KMS-Encryption]] -- Entities linked: [[Gruntwork]], [[Atlantis]], [[Terraform]], [[Terragrunt]], [[DBRE]], [[CloudWatch]] -- Source page: wiki/sources/learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform.md -## [2026-04-25] ingest | Paid Media Tracking & Measurement Specialist Agent -- Source file: Agent/agency-agents/paid-media/paid-media-tracking-specialist.md -- Status: ✅ 成功摄入 -- Summary: 付费媒体追踪与归因专家 Agent——由 John Williams（@itallstartedwithaidea）设计，负责构建跨平台（GTM、GA4、Google Ads、Meta CAPI、LinkedIn Insight Tag）的事件追踪架构，确保每一次转化都被正确计数，每一分广告投入都可衡量。核心理念：错误追踪比无追踪更糟糕，错误计数的转化会主动误导出价算法向错误方向优化。 -- Concepts linked: [[GoogleTagManager]], [[GoogleAnalytics4]], [[MetaConversionsAPI]], [[ServerSideTagging]], [[ConversionTracking]], [[AttributionModeling]], [[ConsentModeV2]], [[DataLayerArchitecture]] -- Entities linked: [[JohnWilliams]], [[TheAgency]] -- Source page: wiki/sources/paid-media-tracking-specialist.md -- Notes: 该 Agent 为其他所有 Paid Media Agent 提供数据基础设施；与 paid-media-creative-strategist/paid-social-strategist/ppc-strategist/programmatic-buyer/search-query-analyst/auditor 均存在 depends_on 关系（协同关系已记录于 Connections）；index.md 已插入于 paid-media-programmatic-buyer 之后；Concepts 均为工具/框架类概念，当前仅出现 1 次，不足独立建页阈值，以 wikilink 形式记录于 Source page - -## [2026-04-25] ingest | XR Cockpit Interaction Specialist Agent -- Source file: Agent/agency-agents/spatial-computing/xr-cockpit-interaction-specialist.md -- Status: ✅ 成功摄入 -- Summary: XR Cockpit Interaction Specialist Agent——XR 座舱交互专家 Agent，专注于设计和实现沉浸式座舱式交互环境。核心理念：固定视角（fixed-perspective）+ 高存在感交互区（high-presence interaction zones），将真实感与用户舒适度结合。核心设计原则：约束驱动控制机制（constraint-driven control mechanics）通过 3D meshes 和输入约束将控制物理化，消除自由漂浮运动；座舱人体工学对齐自然眼-手-头协调流动；多模态交互集成（手势/语音/注视/物理道具）；固定视角设计降低运动病阈值。典型应用：模拟指挥中心、航天器座舱、XR 载具界面、训练模拟器。核心工具：A-Frame / Three.js 原型开发。 -- Concepts created: [[Constraint-Driven-Control-Mechanics]], [[Cockpit-Ergonomics]], [[Motion-Sickness-Threshold]], [[Spatial-Computing]] -- Entities linked: [[XR-Interface-Architect]], [[XR-Immersive-Developer]], [[Terminal-Integration-Specialist]] -- Source page: wiki/sources/xr-cockpit-interaction-specialist.md -- Notes: 4 个新 Concept 页面已创建；overview.md 新增 xr-cockpit-interaction-specialist 独立段落；index.md 修复 "source missing" 条目；Entity 层面，XR-Interface-Architect / XR-Immersive-Developer / Terminal-Integration-Specialist 在源文档中提及但尚未建立独立 Entity 页面，当前以 wikilink 形式记录于 Sources 页面；与 [[XR-Immersive-Developer]] 在运动自由度上存在设计张力（固定约束 vs 开放沉浸），已记录于 Contradictions 部分 - -## [2026-04-25] ingest | macOS Spatial/Metal Engineer Agent Personality -- Source file: Agent/agency-agents/spatial-computing/macos-spatial-metal-engineer.md -- Status: ✅ 成功摄入 -- Summary: macOS Spatial/Metal Engineer Agent——Apple 平台专用 Metal 渲染与空间计算专家 Agent，专注于 Swift + Metal 高性能 3D 渲染和 visionOS 空间计算体验。核心能力：实例化 Metal 渲染（10k-100k 节点 @ 90fps 立体渲染）；RemoteImmersiveSpace + LayerRenderer 实现 macOS → Vision Pro 帧流；Metal Compute Shader GPU 力导向图布局；注视（Gaze）+ 捏合（Pinch）空间交互。性能约束：GPU 利用率 < 80%、每帧 < 100 draw calls、内存 < 1GB。 -- Concepts linked: [[Instanced Rendering]], [[RemoteImmersiveSpace]], [[Compositor Services]], [[LayerRenderer]], [[Force-Directed Graph Layout]], [[Metal System Trace]], [[Stereoscopic Rendering]], [[GPU-Driven Rendering]], [[Triple Buffering]], [[Frustum Culling & LOD]] -- Entities linked: [[Apple]], [[Vision Pro]], [[Metal]], [[Xcode Instruments]], [[RealityKit]], [[ARKit]] -- Source page: wiki/sources/macos-spatial-metal-engineer.md -- Notes: Entity 层面 Apple/Vision Pro/Metal/Xcode Instruments/RealityKit/ARKit 在源文档中提及但均不足独立建页阈值，通过 Sources 页面的 Key Entities 部分建立链接；与 [[visionos-spatial-engineer]] 存在职责重叠（Vision Pro 开发），已记录于 Contradictions 部分——前者侧重 macOS 渲染侧 + Vision Pro 流式输出，后者倾向 visionOS 原生交互开发，两者可协同；与 [[xr-immersive-developer]] 互补——浏览器端 WebXR vs Apple 原生 Metal 渲染管线，共同构成 XR 产品矩阵 - -## [2026-04-25] ingest | Recruitment Specialist Agent -- Source file: Agent/agency-agents/specialized/recruitment-specialist.md -- Status: ✅ 成功摄入 -- Summary: RecruitmentSpecialist 是一个专注于中国人力资源市场的招聘运营与人才获取专家 Agent，覆盖从人才吸引、入职到留任的全周期招聘引擎。涵盖中国招聘平台运营（BOSS直聘、拉勾、猎聘、智联、前程无忧、脉脉、LinkedIn）、JD 优化、简历筛选、面试流程设计（STAR、结构化面试）、校园招聘、猎头管理、劳动法合规（劳动合同法、PIPL、五险一金、N+1）、雇主品牌建设、入职 SOP、招聘数据分析全链路。 -- Concepts created: [[STAR Framework]], [[Structured Interview]], [[China Labor Law Compliance]], [[Recruitment Funnel Analyzer]] -- Entities created: [[Boss Zhipin]] -- Source page: wiki/sources/recruitment-specialist.md -- Notes: 无已知冲突。Key Entities 中 Lagou/Liepin/Beisen/Moka/Feishu/STAR 等在源文档出现但出现次数不足以触发独立建页，通过 Sources 页面的 Key Entities 部分建立 wikilinks。 - -## [2026-04-25] ingest | Government Digital Presales Consultant -- Source file: Agent/agency-agents/specialized/government-digital-presales-consultant.md -- Status: ✅ 成功摄入 -- Summary: Government Digital Presales Consultant 是面向中国ToG（政府）市场的全生命周期售前专家Agent，涵盖政策解读、等保2.0三级/商用密码评估/信创适配、数字政府/智慧城市/城市大脑方案设计、招投标全流程（POC→标书→述标→交接）。核心原则：业务场景驱动方案、技术价值需翻译为政府语言、等保/密评/信创是强制项非加分项。 -- Concepts created: [[Dengbao-2.0]], [[Miping]], [[Xinchuang]] -- Source page: wiki/sources/government-digital-presales-consultant.md -- Notes: 无已知冲突。Key Entities（Digital China Master Plan、Kunpeng、Phytium、UnionTech UOS、DM Database等）在源文档中属于背景知识，未创建独立Entity页面，通过Source页面Key Entities部分建立wikilinks。Entities页面已添加Dengbao 2.0、Miping、Xinchuang三条概念索引。 - -## [2026-04-25] ingest | Healthcare Marketing Compliance Specialist -- Source file: Agent/agency-agents/specialized/healthcare-marketing-compliance.md -- Status: ✅ 成功摄入 -- Summary: Healthcare Marketing Compliance Specialist——The Agency Specialized 部门的医疗营销合规专家，覆盖中国医疗健康全品类（药品/医疗器械/医美/保健食品/互联网医疗）营销合规。核心方法：广告法/医疗广告管理办法/互联网广告管理办法核心法规体系 + 企业内部三级审查机制（法务初审→合规复审→终审发布）+ 合规风险分级矩阵（Critical/High/Medium/Low）+ 违规应急响应（2小时下架→24小时报告→72小时审计）。关键原则：合规不是"堵营销"，而是"保护品牌"。 -- Concepts created: [[Healthcare-Marketing-Compliance]]（总框架）、[[Medical-Advertisement-Review]]（医疗广告审查制度）、[[Three-Tier-Review-Mechanism]]（三级审查机制）、[[Blue-Hat-Logo]]（蓝帽子标识）、[[Appearance-Anxiety]]（容貌焦虑红线）、[[Patient-Privacy-PIPL]]（患者隐私合规）、[[Compliance-Risk-Matrix]]（合规风险分级矩阵） -- Entities created: [[NMPA]]（国家药品监督管理局）、[[SAMR]]（国家市场监督管理总局）、[[DXY]]（丁香园）、[[Douyin]]（抖音）、[[Xiaohongshu]]（小红书） -- Source page: wiki/sources/healthcare-marketing-compliance.md -- Notes: index.md 中原有"source missing"条目，本次摄入后已更新为完整条目并修正标题。overview.md Specialized 部门新增 Healthcare Marketing Compliance Specialist 条目。Conflict Areas 新增第11条（与通用法律合规 Agent 的职责边界冲突）。Entities 页面中 Haodf/WeDoctor/JD-Health/WeChat 在源文档中出现频次<2，暂未创建独立页面，通过 Source 页面 Key Entities 部分建立 wikilinks。 - -## [2026-04-25] ingest | Sales Data Extraction Agent -- Source file: Agent/agency-agents/specialized/sales-data-extraction-agent.md -- Status: ✅ 成功摄入 -- Summary: Sales Data Extraction Agent——销售数据提取 AI Agent，专门监控 Excel 文件并提取关键销售指标（MTD/YTD/Year End）。核心能力：文件系统监控、灵活列名映射、PostgreSQL 事务持久化、完整审计跟踪。成功指标：100% 自动化处理、<2% 行级失败率、<5 秒单文件处理时间。 -- Concepts created: 无（FilesystemWatcher/FuzzyColumnMapping/MetricExtraction/TransactionalDatabase/AuditTrail 等概念均通过 Source Page 内 wikilinks 形式表达，未单独建 Concept 页面） -- Entities created: 无（PostgreSQL/SalesRepresentative/ExcelWorkbook 在源文档中出现频次<2，暂未创建独立 Entity 页面，通过 Source 页面 Key Entities 建立 wikilinks） -- Source page: wiki/sources/sales-data-extraction-agent.md -- Notes: index.md 中原有 "source missing" 占位条目（2026-04-20）已替换为完整条目；overview.md Specialized 部门新增 Sales Data Extraction Agent 条目；与 DataConsolidationAgent 的关系已记录于 Contradictions 部分（数据提取 vs 数据整合，互补关系）。 - -## [2026-04-25] ingest | Study Abroad Advisor -- Source file: Agent/agency-agents/specialized/study-abroad-advisor.md -- Status: ✅ 成功摄入 -- Summary: Study Abroad Advisor——The Agency Specialized 部门的全链路留学申请规划专家，面向中国学生，覆盖美/英/加/澳/欧/港/新七大目的地，本科/硕士/博士全学位层次。核心理念：数据驱动、零焦虑贩卖；四步工作流（全面诊断→策略制定→材料打磨→提交跟进）；诚信原则（不代写文书、不承诺录取结果、区分确认信息与经验估算）。标准化交付模板：选校报告、多国申请时间线、文书诊断框架、Offer 比较矩阵。 -- Concepts created: [[Holistic-Admissions]]（全面评估录取模式）、[[UCAS-System]]（英国本科统一申请系统）、[[IANG-Visa]]（非本地毕业生留港就业安排）、[[Grandes-Ecoles]]（法国精英大学体系） -- Entities created: [[The-Agency]]（The Agency 多智能体系统组织，147 个 Agent 跨 12 部门） -- Source page: wiki/sources/study-abroad-advisor.md -- Notes: index.md 中原有 "source missing" 占位条目（2026-04-20）已替换为完整条目；overview.md Specialized 部门新增 Study Abroad Advisor 条目置于 lsp-index-engineer 之后；与 corporate-training-designer 同属服务型 Agent 已在 overview.md 建立关联。4 个 Concept 页面（Holistic-Admissions/UCAS-System/IANG-Visa/Grandes-Ecoles）和 1 个 Entity 页面（The-Agency）创建前均已做去重检查，确认均不存在。 - -## [2026-04-26] ingest | Backend Architect with Memory -- Source file: Agent/agency-agents/integrations/mcp-memory/backend-architect-with-memory.md -- Status: ✅ 成功摄入 -- Summary: 具备持久记忆能力的后端架构师 AI Agent 设计规范——专注于可扩展系统设计（微服务/Serverless）、数据库架构（PostgreSQL/索引/CQRS）、API 开发（REST/GraphQL/gRPC）与云基础设施。核心价值：MCP Memory 集成实现跨会话记忆召回，防止重复讨论已做决策；架构决策以标签化快照持久化；交付物完成后主动标记接收方供下游 Agent 查找；QA 失败时自动回滚到上一个良好检查点。 -- Entities created: BackendArchitect（The Agency 工程部门资深后端架构师 Agent，满足 ≥2 次阈值） -- Concepts created: 无（MicroservicesArchitecture/CQRS/EventSourcing/ServerlessArchitecture/DatabaseIndexing/CircuitBreaker/DefenseInDepth 均仅出现 1 次，均不满足 ≥2 次阈值，均以 wikilink 形式记录于 Source page） -- Source page: wiki/sources/backend-architect-with-memory.md -## [2026-04-25] ingest | GitHub Copilot Integration -- Source file: Agent/agency-agents/integrations/github-copilot/README.md -- Status: ✅ 成功摄入 -- Summary: The Agency 与 GitHub Copilot 的开箱即用集成——无需转换，`.md` + YAML frontmatter 格式原生兼容。一键安装 `./scripts/install.sh --tool copilot`，或手动复制到 `~/.github/agents/` 或 `~/.copilot/agents/`。用户可在 Copilot 会话中通过名称激活特定 agent。 -- Concepts created: AgentFileFormat -- Entities created: GitHubCopilot -- Source page: wiki/sources/github-copilot.md -- Notes: 无内容冲突。index.md（Sources + Concepts + Entities）、overview.md（替换 Cursor Integration 段落为 GitHub Copilot Integration）、log.md 均已更新。Concept AgentFileFormat.md 已创建于 wiki/concepts/，Entity GitHubCopilot.md 已创建于 wiki/entities/。 +## [2026-04-26] ingest | Autonomous Optimization Architect Agent Personality +- Source file: Agent/agency-agents/engineering/engineering-autonomous-optimization-architect.md +- Status: ✅ 成功摄入 +- Summary: Autonomous Optimization Architect——AI 系统自我进化的"治理者"，在保证系统不会破产或陷入恶意循环的前提下，持续通过影子测试评估和切换 AI 模型。核心理念："Autonomous routing without a circuit breaker is just an expensive bomb." 核心机制：LLM-as-Judge 评分（数学评分标准替代主观评估）、影子流量测试（5% 异步测试新模型）、语义路由（按 Speed+Cost+Accuracy 综合排名选最优 Provider）、熔断器（失败超阈值自动切断并切换兜底方案）、AI FinOps（追踪每个 Provider 的成本与性能历史）。目标：在 99.99% 稳定性下实现 >40% 成本降低。属 The Agency Engineering 部门。 +- Concepts created: CircuitBreaker, LLMasJudge, ShadowTraffic, SemanticRouting, DarkLaunching, AIFinOps（以上 6 个 Concept 均为本 Agent 首次引入的新概念，本 Agent 为唯一来源，>=2 次出现阈值暂时满足） +- Entities created: OpenAI, Anthropic, GoogleGemini（以上 3 个 Entity 均为知名 LLM Provider，本 Agent 首次在 Wiki 中明确引用其作为 Provider 参与路由竞争的角色） +- Source page: wiki/sources/engineering-autonomous-optimization-architect.md +- Notes: index.md Sources 部分新增 engineering-autonomous-optimization-architect.md 条目（置于最顶部）；冲突检测：与 [[testing-performance-benchmarker]] 在"性能评估方式"上存在方法论冲突——Performance Benchmarker 强调人工驱动的静态评估（可控可复现），本 Agent 强调机器驱动的持续影子测试（真实流量），已在 Source Page Contradictions 部分记录；Entity/Concept 去重：已检查现有 wiki 不存在同名条目（entities/concepts 目录此前为空，仅有 sources），所有 Concept 和 Entity 均为本 Agent 首次引入。overview.md 未更新（该 Source 属 Multi-Agent AI Systems/The Agency Engineering 范畴，现有 overview 覆盖充分，暂不重复）。 + +## [2026-04-26] ingest | Mobile App Builder Agent Personality +- Source file: Agent/agency-agents/engineering/engineering-mobile-app-builder.md +- Status: ✅ 成功摄入 +- Summary: Mobile App Builder — 专注原生 iOS/Android 开发和跨平台框架的移动应用开发 AI Agent。核心理念：平台感知、性能优先、用户体验驱动。核心规范：遵循 Material Design / Human Interface Guidelines；默认离线优先架构；跨平台框架按需选型（SwiftUI/Kotlin/Jetpack Compose/React Native/Flutter）。核心方法：MVVM 模式、性能优化目标（冷启动 < 3s、内存 < 100MB、续航 < 5%/h）、平台特定功能集成（生物识别认证、推送通知、相机/AR 等）。属 The Agency Engineering 部门。 +- Concepts created: 无（Offline-First Architecture/MVVM Pattern/Cross-Platform Mobile Development/Platform-Native UI/Biometric Authentication/Push Notification System 各仅在本文档出现 1 次，未达 ≥2 次独立建页阈值，保留于 Source Page 内嵌引用） +- Entities created: 无（SwiftUI/Jetpack Compose/React Native/Flutter/Swift/Kotlin 各仅出现 1 次，未达 ≥2 次独立建页阈值） +- Source page: wiki/sources/engineering-mobile-app-builder.md +- Notes: index.md Sources 部分新增 engineering-mobile-app-builder.md 条目（置于最顶部）；overview.md Engineering 部分新增 engineering-mobile-app-builder 独立 entry（置于 engineering-software-architect 与 workflow-with-memory 之间）；冲突检测：与 [[unity-architect]] 在"跨平台框架优先级"上存在分工差异——Mobile App Builder 面向通用移动应用（SwiftUI/Compose/React Native/Flutter），Unity Architect 面向游戏引擎内跨平台，属合理分工而非矛盾，已在 Source Page Contradictions 部分记录；Entity/Concept 去重：已检查现有 wiki 不存在同名/近义条目，所有概念和实体均仅在本文档出现 1 次，未达 ≥2 次独立建页阈值，保留于 Source Page 内嵌引用。 + +## [2026-04-26] ingest | Software Architect Agent Personality +- Source file: Agent/agency-agents/engineering/engineering-software-architect.md +- Status: ✅ 成功摄入 +- Summary: SoftwareArchitect——软件架构与系统设计专家 Agent，核心理念"Designs systems that survive the team that built them." 核心规范：权衡优先于最佳实践（命名所放弃的）、领域优先于技术、架构 ADR 记录（Context/Decision/Consequences）、C4 模型四层沟通架构（Context/Container/Component/Code）、架构模式选型矩阵（Modular Monolith/Microservices/Event-Driven/CQRS）、质量属性分析（可扩展性/可靠性/可维护性/可观测性）。核心交付物：ADR 模板、标准架构模式选型矩阵、C4 图沟通规范。属 The Agency Engineering 部门。 +- Concepts created: 无（Bounded Contexts/Trade-off Analysis/Architecture Decision Record/Modular Monolith/Microservices/Event-Driven Architecture/CQRS/C4 Model/Quality Attributes 各仅在本文档出现 1 次，未达 ≥2 次独立建页阈值，保留于 Source Page 内嵌引用） +- Entities created: 无（本文档未明确提及具体人物或公司，均为通用软件工程概念，未达 Entity 建页阈值） +- Source page: wiki/sources/engineering-software-architect.md +- Notes: index.md Sources 部分新增 engineering-software-architect.md 条目（置于最顶部）；overview.md Multi-Agent AI Systems 部分新增 engineering-software-architect 独立 entry（置于 backend-architect-with-memory 与 workflow-with-memory 之间）；冲突检测：与 [[unity-architect]] 在"架构约束与团队规模关系"上存在框架差异——Software Architect 强调架构必须匹配团队能力（Microservices 不适合小团队），Unity Architect 侧重 Unity 平台特定技术架构，已在 Source Page Contradictions 节记录，属平台约束差异而非绝对冲突；Entity/Concept 去重：已检查现有 wiki 不存在同名/近义条目，所有概念（Bounded Contexts/ADR/C4 Model 等）和实体均仅在本文档出现 1 次，未达 ≥2 次独立建页阈值，保留于 Source Page 内嵌引用。 + +## [2026-04-26] ingest | Godot Multiplayer Engineer +- Source file: Agent/agency-agents/game-development/godot/godot-multiplayer-engineer.md +- Status: ✅ 成功摄入 +- Summary: GodotMultiplayerEngineer——Godot 4 多人游戏网络专家 AI Agent，核心理念"权威精确、场景架构意识、延迟诚实、GDScript 精准"。核心规范：`set_multiplayer_authority()` 显式权威设置，服务器权威模型持有所有游戏关键状态；所有 `@rpc("any_peer")` 必须服务器端验证发送者 ID 和输入合理性；`MultiplayerSpawner` 是动态生成网络节点的唯一正确方式，`MultiplayerSynchronizer` 配置 `ON_CHANGE` 模式。核心交付物：NetworkManager Autoload（ENet 服务器/客户端）、Server-Authoritative Player Controller、MultiplayerSynchronizer 配置、MultiplayerSpawner 场景生成、RPC Security Pattern（物品拾取验证）、Matchmaking 集成。高级能力涵盖 WebRTC P2P 多人游戏（STUN/TURN NAT 穿透）、Nakama 游戏服务器集成、Relay Server 架构（二进制协议 + 房间路由）、自定义网络协议设计。属 The Agency Game Dev 部门。 +- Concepts created: 无（MultiplayerAPI/Server-Authoritative-Model/RPC/MultiplayerSynchronizer/MultiplayerSpawner/ENet/WebRTC/Authority-Model/RPC-Security-Pattern 各仅在本文档出现 1 次，未达 ≥2 次独立建页阈值，保留于 Source Page 内嵌引用） +- Entities created: 无（Nakama/Godot-4 各仅出现 1-2 次，未达 ≥2 次独立建页阈值；以上均为工具/引擎/框架，非独立实体） +- Source page: wiki/sources/godot-multiplayer-engineer.md +- Notes: index.md Sources 部分新增 godot-multiplayer-engineer.md 条目（置于最顶部）；overview.md Game Development 部分新增 godot-multiplayer-engineer 独立 entry（置于 godot-shader-developer 之前），已建立与 [[godot-gameplay-scripter]]（多人游戏建立在游戏逻辑脚本基础上）、[[unity-multiplayer-engineer]]（跨引擎多人游戏共识，权威模型一致但 API 不同）的关联；冲突检测：与 [[unity-multiplayer-engineer]] 在"权威模型实现细节"上存在差异——Godot 显式 `set_multiplayer_authority()` + MultiplayerSynchronizer vs Unity 隐式 NetworkTransform/NetworkVariable，已在 overview.md 和 Source Page Contradictions 部分记录；Entity/Concept 去重：已检查现有 wiki 不存在同名/近义条目，所有概念和实体均仅在本文档出现 1 次，未达 ≥2 次独立建页阈值，保留于 Source Page 内嵌引用。 + +## [2026-04-26] ingest | Godot Shader Developer +- Source file: Agent/agency-agents/game-development/godot/godot-shader-developer.md +- Status: ✅ 成功摄入 +- Summary: GodotShaderDeveloper——Godot 4 渲染效果专家 AI Agent，核心理念"创作性、正确性与性能意识三合一"。核心规范：shader_type 强制声明（canvas_item/spatial/particles/sky）；Godot 着色语言非原始 GLSL（必须用 TEXTURE/UV/COLOR/ALBEDO 等内置变量）；渲染器分级适配（Forward+ → Mobile → Compatibility）；uniform hint 强制（hint_range/source_color/hint_normal）；纹理采样计数审计（移动端不透明材质 ≤ 6 次采样）。核心交付物：2D CanvasItem 精灵描边着色器、3D Dissolve 溶解着色器、3D 水面着色器、CompositorEffect 全屏后处理、Shader Performance Audit 清单。属 The Agency Game Dev 部门。 +- Concepts created: 无（CanvasItem Shader/Spatial Shader/VisualShader/CompositorEffect/Forward+ Renderer/Mobile Renderer/Compatibility Renderer 各仅在本文档出现 1 次，未达 ≥2 次独立建页阈值，保留于 Source Page 内嵌引用） +- Entities created: 无（Godot/GLSL 各仅出现 1-2 次，未达 ≥2 次独立建页阈值） +- Source page: wiki/sources/godot-shader-developer.md +- Notes: index.md Sources 部分新增 godot-shader-developer.md 条目（置于最顶部）；overview.md Game Development 部分新增 godot-shader-developer 独立 entry（置于 godot-gameplay-scripter 之后、Conflict Areas 之前），已建立与 [[godot-gameplay-scripter]]（Godot 游戏逻辑）、[[unity-shader-graph-artist]]（跨引擎着色器共识）、[[technical-artist]]（渲染技术+美术桥梁角色）关联；冲突检测：无与其他 Wiki 页面的内容冲突。 +## [2026-04-26] ingest | Godot Gameplay Scripter +- Source file: Agent/agency-agents/game-development/godot/godot-gameplay-scripter.md +- Status: ✅ 成功摄入 +- Summary: GodotGameplayScripter——Godot 4 游戏逻辑脚本专家 AI Agent 人格规范，核心理念"以软件架构师的纪律性构建类型安全、信号驱动、可组合的游戏玩法系统"。核心规范：GDScript 信号 snake_case + 类型化参数，C# 信号 PascalCase + EventHandler；全静态类型化（无 untyped var）；组合优于继承（HealthComponent 节点模式）；Autoload 仅用于全局状态（EventBus/设置/存档）；场景可独立实例化。核心交付物：Typed Signal 声明（GDSCript + C# 双语）、EventBus Autoload、HealthComponent 组件模式、Typed Array 敌人追踪、GDScript/C# 互操作模式。属 The Agency Game Dev 部门 Godot 专精。 +- Concepts created: 无（Signal-Driven-Architecture/Static-Typing-in-GDScript-2.0/Composition-Over-Inheritance/Event-Bus-Autoload/Type-Safe-Signal-Design/GDScript-CSharp-Interoperability 各仅在本文档出现 1 次，未达 ≥2 次独立建页阈值，保留于 Source Page 内嵌引用） +- Entities created: 无（GDScript-2.0/C#/GDExtension/HealthComponent/EventBus 各仅出现 1-2 次，未达独立建页阈值；以上均为工具/语言/模式，非独立实体） +- Source page: wiki/sources/godot-gameplay-scripter.md +- Notes: index.md Sources 部分新增 godot-gameplay-scripter.md 条目（置于 game-designer 之后、narrative-designer 之前）；overview.md Game Development 部分新增 godot-gameplay-scripter 独立 entry（置于 unity-architect 之后、Conflict Areas 之前），已建立与 [[unity-architect]] 的跨引擎共识关联（组合优于继承设计哲学，Unity 使用 ScriptableObject 事件通道，Godot 使用信号总线）；冲突检测：与 [[unity-architect]] 在"全局状态管理"上存在实现路径差异但设计哲学一致——两者均反对全局可变状态，仅在具体机制上不同，已在 overview.md 中记录为"跨引擎共识"；Entity/Concept 去重：已检查现有 wiki 不存在同名/近义条目，所有概念和实体均仅在本文档出现 1 次，未达 ≥2 次独立建页阈值，保留于 Source Page 内嵌引用。 +- Source file: Agent/agency-agents/game-development/blender/blender-addon-engineer.md +- Status: ✅ 成功摄入 +- Summary: BlenderAddonEngineer——Blender 原生工具开发专家 AI Agent 人格规范，核心理念"Pipeline-first, artist-empathetic, automation-obsessed, reliability-minded"。核心规范：数据 API（bpy.data）优先于操作符（bpy.ops）确保 Operator 可靠性；非破坏性验证（dry-run 模式）确保用户知情同意；Pipeline 可靠性三角（命名确定性 + 变换分离检查 + 材质槽顺序验证 + 集合包含/排除显式规则）；批量操作必须精确记录修改内容。核心交付物：PIPELINE_OT_validate_assets（命名/变换/材质槽检查）、Pipeline Export Panel（导出预设 UI）、Naming Audit Report、Validation Report Template。属 The Agency Game Dev 部门 DCC 工具专项。 +- Concepts created: 无（bpy/Asset-Validation/Non-Destructive-Workflow/Export-Presets/Pipeline-Reliability/AddonPreferences/PropertyGroups 各仅出现 1 次，未达 ≥2 次独立建页阈值，保留于 Source Page 内嵌引用） +- Entities created: 无（Blender/BlenderAddonEngineer 各仅出现 1-2 次，未达独立建页阈值；BlenderAddonEngineer 为 Agent 类型非实体，不建 Entity 页） +- Source page: wiki/sources/blender-addon-engineer.md +- Notes: index.md Sources 首位新增 blender-addon-engineer.md 条目（2026-04-26）；overview.md Game Development 部分新增 blender-addon-engineer 独立 entry（置于 Technical Artist 之后、Roblox Systems Scripter 之前）；冲突检测：与 [[UnityArchitect]] 在"编辑器工具数据修改时机"上存在设计哲学差异——Blender Add-on Engineer 坚持非破坏性验证优先（dry-run 模式），Unity Architect 倾向所见即所得直接修改（ScriptableObject 持久化状态），均为各自平台约束最优解，已在 Source Page Contradictions 节详细记录；Entity/Concept 去重：已检查现有 wiki 不存在重复条目，所有概念和实体均仅在本文档出现 1 次，未达 ≥2 次独立建页阈值，保留于 Source Page 内嵌引用。 + +## [2026-04-26] ingest | Roblox Avatar Creator +- Source file: Agent/agency-agents/game-development/roblox-studio/roblox-avatar-creator.md +- Status: ✅ 成功摄入 +- Summary: RobloxAvatarCreator——Roblox UGC 化身 pipeline 专家 AI Agent 人格规范。核心理念：技术规格精准、视觉打磨到位、平台合规。核心规范：UGC 网格三角面数硬限制（配件 ≤4,000、Bundle 部件 ≤10,000）；单 UV 通道且范围严格在 [0,1]；所有 transform 导出前必须应用；纹理 256-1024px PNG，UV island 2px padding；Layered Clothing 三层 cage（OuterMesh + InnerCage + OuterCage）；附件点标准命名（HatAttachment 等）；5 种 body type 全测试。核心交付物：Accessory Export Checklist、AvatarManager.lua（HumanoidDescription 全套换装）、Layered Clothing Cage Setup Guide、Creator Marketplace Submission Package、UGC Shop UI Flow（MarketplaceService）。属 The Agency Game Dev 部门 Roblox Studio 专项，与 [[Roblox Systems Scripter]]（Luau 系统架构）、[[Roblox Experience Designer]]（玩家变现）协同构成完整 Roblox 开发体系。 +- Concepts created: 无（UGC/LayeredClothing/HumanoidDescription/R15Rig/CreatorMarketplace/AttachmentPoint/RthroBodyType 各仅出现 1 次，未达 ≥2 次独立建页阈值，保留于 Source Page 内嵌引用） +- Entities created: 无（Blender/RobloxStudio/R15TestBodies/DataStore 各仅出现 1-2 次，未达独立建页阈值，保留于 Source Page 内嵌引用） +- Source page: wiki/sources/roblox-avatar-creator.md +- Notes: index.md Sources 顶部新增 roblox-avatar-creator.md 条目（2026-04-26）；overview.md Game Development 部分新增 roblox-avatar-creator 独立 entry（紧随 roblox-experience-designer）；冲突检测：与 [[UnityArchitect]] 在角色定制系统实现路径上存在平台差异——Roblox 强制服务端权威（HumanoidDescription + DataStore），Unity 可客户端预测，均为各自平台最优解，已在 Source Page Contradictions 节记录；Entity/Concept 去重：已检查现有 wiki 不存在重复条目，所有概念和实体均仅在本文档出现 1 次，未达 ≥2 次独立建页阈值，保留于 Source Page 内嵌引用。 + +## [2026-04-26] ingest | Roblox Systems Scripter +- Source file: Agent/agency-agents/game-development/roblox-studio/roblox-systems-scripter.md +- Status: ✅ 成功摄入 +- Summary: RobloxSystemsScripter——Roblox 平台 Luau 系统脚本工程师 AI Agent 人格规范。核心理念：服务器是唯一真相来源，客户端只显示状态不拥有状态。核心规范：客户端-服务器信任边界（LocalScript 仅显示，Script 仅逻辑）；RemoteEvent 安全验证（类型检查+冷却检查+距离检查+权限检查）；DataStore 可靠性（pcall + 指数退避重试 + 双保存点 PlayerRemoving + BindToClose）；ModuleScript 架构（所有逻辑在 ModuleScript 返回表，Script/LocalScript 仅 bootstrap）。核心交付物：DataManager.lua（含 retryAsync + deepCopy + 双保存点）、CombatSystem.lua（完整验证链路示例）、GameServer.bootstrap.server.lua（五阶段引导模式）。高级能力：Parallel Luau（task.desynchronize + Actor 模型 + SharedTable）、对象池、数据版本迁移（UpdateAsync 原子升级）。属 The Agency Game Dev 部门 Roblox Studio 专项，与 Roblox Experience Designer 协同构成完整 Roblox 开发体系。 +- Concepts created: 无（Server-Authoritative-Architecture/RemoteEvent-Security/DataStore-Reliability/ModuleScript-Architecture/Parallel-Luau/Object-Pooling/UpdateAsync-Atomic-Pattern 各仅在本文档出现 1 次，未达 ≥2 次独立建页阈值，保留于 Source Page 内嵌引用） +- Entities created: 无（Roblox/Luau/DataStoreService/ReplicatedStorage/ServerStorage 各仅出现 1-2 次，未达独立建页阈值，保留于 Source Page 内嵌引用） +- Source page: wiki/sources/roblox-systems-scripter.md +- Notes: index.md Sources 顶部新增 roblox-systems-scripter.md 条目（2026-04-26）；overview.md Game Development 部分新增 roblox-systems-scripter 独立 entry（紧随 Technical Artist，Roblox Experience Designer 紧接其后）；冲突检测：与 [[UnityArchitect]] 在客户端预测策略上存在平台差异——Roblox Systems Scripter 建议服务器权威不做本地预测（Roblox RemoteEvent 架构天然适合），Unity Architect/UnityMultiplayerEngineer 建议使用服务器回滚式 client prediction 提升响应体验，已在 Source Page Contradictions 节记录，属平台约束差异而非绝对冲突；Entity/Concept 去重：已检查现有 wiki 不存在重复条目，所有概念和实体均仅在本文档出现 1 次，未达 ≥2 次独立建页阈值，保留于 Source Page 内嵌引用。 + +## [2026-04-26] ingest | Roblox Experience Designer +- Source file: Agent/agency-agents/game-development/roblox-studio/roblox-experience-designer.md +- Status: ✅ 成功摄入 +- Summary: RobloxExperienceDesigner——Roblox 平台原生体验设计师 AI Agent 人格规范，专注于 9-17 岁受众的参与度循环设计、变现系统（Game Pass/Developer Product/UGC）与玩家留存。核心方法：DataStore 驱动进度持久化创造沉没成本；每日奖励系统（1-7天循环阶梯）驱动习惯性返回；入职引导三阶段（0-60秒/5分钟/15分钟）；AnalyticsService 追踪 D1/D7 留存指标。核心原则：禁止 pay-to-win、DataStore 安全优先、变现伦理（禁止暗黑模式）。成功指标：D1 留存 >30%、D7 >15%、MAU 月增长 >10%、转化率 >3%、零 Roblox 政策违规。核心交付物：PassManager.lua（Game Pass 集中管理）、DailyRewardSystem.lua（每日奖励）、Onboarding Flow Design Document（含 Drop-off Recovery Points）。属 The Agency Game Dev 部门 Roblox Studio 专项。 +- Concepts created: 无（EngagementLoop/DailyRewardSystem/DataStoreProgression/GamePassMonetization/DeveloperProduct/OnboardingFlow/RobloxAlgorithm/AnalyticsService/SoftCurrencyFunnel/PriceAnchoring 均仅在本文档出现 1 次，未达 ≥2 次独立建页阈值，保留于 Source Page 内嵌引用） +- Entities created: 无（RobloxExperienceDesigner/RobloxPlatform/MarketplaceService/DataStoreService/AnalyticsService/VoiceChatService 各仅出现 1 次，未达独立建页阈值，保留于 Source Page 内嵌引用） +- Source page: wiki/sources/roblox-experience-designer.md +- Notes: index.md Sources 顶部新增 roblox-experience-designer.md 条目（2026-04-26）；overview.md Game Development 部分新增 roblox-experience-designer 独立 entry（Roblox Experience Designer 紧随 Technical Artist）；冲突检测：与 [[UnityArchitect]] 在变现策略上存在受众差异——Roblox 受众（9-17岁）强制伦理变现规范，Unity 平台受众更广可更灵活，已在 Source Page Contradictions 节记录；Entity/Concept 去重：已检查现有 wiki 不存在重复条目，所有概念和实体均仅在本文档出现 1 次，未达 ≥2 次独立建页阈值，保留于 Source Page 内嵌引用。 + +## [2026-04-26] ingest | Unity Architect +- Source file: Agent/agency-agents/game-development/unity/unity-architect.md +- Status: ✅ 成功摄入 +- Summary: UnityArchitect——Unity 游戏架构师 AI Agent 人格规范，专注于数据驱动、ScriptableObject（SO）优先的模块化可扩展架构。核心职责：消除硬引用、单例滥用、God MonoBehaviour 等反模式，通过 SO 事件通道（GameEvent）、RuntimeSet、单一职责组件拆分、Inspector SO 引用连线构建可测试、可设计师扩展的 Unity 系统。核心理念：ScriptableObject-First（所有共享数据存于 SO，绝不跨场景传 MonoBehaviour 字段）；零硬引用（禁用 GameObject.Find/单例，通过 SO 事件通道连线）；单一职责（每个 MonoBehaviour < 150 行）。高级能力：Addressables 资源管理、SO 状态机、Unity DOTS 混合架构、内存 Profiling。核心交付物：FloatVariable SO（含 OnValueChanged）、RuntimeSet、GameEvent 事件通道、PlayerHealthDisplay 示例、Custom PropertyDrawer。成功指标：零 GameObject.Find()；每个 MonoBehaviour < 150 行；Prefab 空场景独立运行。 +- Concepts created: 无（ScriptableObject/RuntimeSet/GameEvent/SingleResponsibility/EventDriven/DataDriven/ScriptableObjectEventChannel/Addressables/UnityDOTS/EditorUtilitySetDirty 均仅在本文档出现 1 次，未达 ≥2 次独立建页阈值，保留于 Source Page 内嵌引用） +- Entities created: 无（UnityArchitect/UnityEditor/UnityDOTS 各仅出现 1 次，未达独立建页阈值，保留于 Source Page 内嵌引用） +- Source page: wiki/sources/unity-architect.md +- Notes: index.md Sources 顶部替换占位条目为正式摘要（2026-04-26，unity-architect.md）；overview.md Game Development 部分新增 unity-architect 独立 entry（Unity Architect 紧随 Unity Shader Graph Artist）；冲突检测：与 [[unity-multiplayer-engineer]] 在 NetworkVariable 传递方式上存在 SO 抽象程度差异——UnityArchitect 侧重 SO 层引用连线，UnityMultiplayerEngineer 侧重 NetworkBehaviour 直接挂载，属架构风格差异而非绝对冲突，已在 Source Page Contradictions 节记录；Entity/Concept 去重：已检查现有 wiki 不存在重复条目，所有概念和实体均仅在本文档出现 1 次，未达 ≥2 次独立建页阈值，保留于 Source Page 内嵌引用；overview.md Game Development 部分完整性：已新增 Unity Architect entry，与 Unity Shader Graph Artist、Unity Editor Tool Developer、Unity Multiplayer Engineer 共同构成 Game Development Unity 专精团队。 +- Source file: Agent/agency-agents/game-development/unity/unity-multiplayer-engineer.md +- Status: ✅ 成功摄入 +- Summary: UnityMultiplayerEngineer——Unity 多人游戏网络编程专家 AI Agent 人格规范。核心职责：使用 Netcode for GameObjects（NGO）、Unity Gaming Services（Relay/Lobby）构建安全、抗作弊、延迟容忍的多人游戏系统。核心理念：服务器权威非协商原则——服务器拥有所有游戏状态真相，客户端仅发送输入；NetworkVariable 用于持久化状态，RPC 用于一次性事件，二者不可混用。核心规范：ServerRpc 必须服务器端验证所有输入；客户端预测必须与服务器状态调和校正；带宽管理——每玩家稳态 < 10KB/s；Relay 替代直连 P2P 保护主机 IP；Lobby 仅存储元数据不存储游戏状态。核心交付物：Server-Authoritative Player Controller（含客户端预测与调和）、Lobby Manager（创建/快速匹配/心跳）、NetworkVariable 设计参考、反作弊验证逻辑。高级能力：回滚网络代码（战斗游戏风格）、专用服务器 Docker 部署、性能剖析与带宽预算。 +- Concepts created: ServerAuthority、ClientPrediction、NetworkVariable、UnityRelay、UnityLobby、AntiCheatArchitecture、BandwidthManagement、LagCompensation +- Entities created: NetcodeForGameObjects、UnityGamingServices、UnityMultiplayerEngineer、UnrealMultiplayerArchitect +- Source page: wiki/sources/unity-multiplayer-engineer.md +- Notes: index.md Sources 顶部新增 unity-multiplayer-engineer.md 条目（2026-04-26）；index.md Entities 新增 4 个实体（NetcodeForGameObjects、UnityGamingServices、UnityMultiplayerEngineer、UnrealMultiplayerArchitect）；index.md Concepts 新增 8 个概念；overview.md 未更新（非概述类技术规范文档）；冲突检测：与 [[UnrealMultiplayerArchitect]] 在客户端预测实现细节上有差异——Unity 侧使用 NetworkVariable + LateUpdate 调和，Unreal 侧使用帧缓冲和回滚机制，已在 Source Page Contradictions 节记录，两者均遵循服务器权威原则，属框架差异而非绝对冲突；Entity/Concept 去重：已检查现有 wiki 不存在重复条目，所有概念和实体均为首次创建。 +- Source file: Agent/agency-agents/game-development/unity/unity-shader-graph-artist.md +- Status: ✅ 成功摄入 +- Summary: UnityShaderGraphArtist——Unity 渲染效果专家 AI Agent 人格规范。核心职责：精通 Shader Graph 可视化材质创作与 HLSL 性能优化，专注于 URP/HDRP 渲染管线的实时视觉效果开发。核心理念：Shader Graph 是艺术家创作首选，HLSL 仅用于性能关键路径。核心规范：Sub-Graph 强制复用重复逻辑；URP/HDRP API 严格区分不可互换；移动端硬约束（每 Fragment Pass 最多 32 纹理采样，不透明 Fragment 最多 60 ALU）；Alpha Clipping 优先于 Alpha Blend；Frame Debugger 强制性能分析后方可发布。核心交付物：Dissolve Shader Graph（含 DissolveCore Sub-Graph）、OutlineRendererFeature（URP 自定义描边通道）、CustomLit.hlsl（URP 兼容 PBR Shader）、Shader Complexity Audit 模板。高级能力：Compute Shader GPU 处理、RenderDoc Shader 调试、自定义深度后处理通道、程序化纹理生成。 +- Concepts created: 无（Shader Graph/Sub-Graph/ScriptableRendererFeature/AlphaClipping/HLSL 均仅出现 1-2 次，未达 ≥2 次独立建页阈值，保留于 Source Page 内嵌引用） +- Entities created: 无（UnityTechnologies/DissolveCore/OutlineRendererFeature/CustomLit.hlsl 各仅出现 1 次，未达独立建页阈值，保留于 Source Page 内嵌引用） +- Source page: wiki/sources/unity-shader-graph-artist.md +- Notes: index.md Sources 顶部新增 unity-shader-graph-artist.md 条目（2026-04-26）；overview.md Game Development 部分新增 unity-shader-graph-artist 独立 entry；冲突检测：与 [[unreal-technical-artist]] 在渲染管线选择上存在平台差异（Unity Shader Graph vs Unreal HLSL），属平台特性差异而非绝对冲突，已在 Source Page Contradictions 节记录；Entity/Concept 去重：所有 Key Concepts/Key Entities 均仅在本 Source 出现 1 次，未达 ≥2 次独立建页阈值，保留于 Source Page 内嵌引用。 + +## [2026-04-26] ingest | Unity Editor Tool Developer +- Source file: Agent/agency-agents/game-development/unity/unity-editor-tool-developer.md +- Status: ✅ 成功摄入 +- Summary: UnityEditorToolDeveloper——Unity 编辑器扩展开发工程师 AI Agent 人格规范。核心职责：通过 EditorWindows、PropertyDrawers、AssetPostprocessors、Build Validators 自动化团队工作流，减少人工错误并提升艺术/设计/工程团队效率。核心理念：最佳工具是隐形的——在问题到达 QA 前自动拦截，在创意人员意识到需求前提前自动化。核心规范：Editor 脚本必须置于 Editor 文件夹或 #if UNITY_EDITOR 保护；EditorWindow 必须通过 [SerializeField]/EditorPrefs 持久化状态；AssetPostprocessor 必须幂等（同一资源重复导入产生相同结果）；PropertyDrawer 必须调用 BeginProperty/EndProperty；构建验证失败必须抛出 BuildFailedException。高级能力：Assembly Definition 架构（编辑器/运行时程序集分离）、CI/CD 集成（-batchmode + GitHub Actions）、Scriptable Build Pipeline、UI Toolkit (UIElements) 编辑器工具。 +- Concepts created: 无（EditorWindow/AssetPostprocessor/PropertyDrawer/BuildValidation 各仅出现 1 次，未达 ≥2 次建页阈值，保留于 Source Page 内嵌引用） +- Entities created: 无（本 Source 无人 Entity） +- Source page: wiki/sources/unity-editor-tool-developer.md +- Notes: index.md Sources 替换占位条目为正式摘要（2026-04-26，unity-editor-tool-developer.md）；overview.md Game Development 部分新增 unity-editor-tool-developer 独立 entry；冲突检测：与 [[unreal-systems-engineer]] 在"构建前验证"模式上互补——Unity 侧通过 IPreprocessBuildWithReport 在打包前验证，Unreal 侧通过 UAssetCheckConfig 在编辑器内实时检查，属互补而非冲突，已在 Source Page Contradictions 节记录；Entity/Concept 去重：EditorWindow/AssetPostprocessor/PropertyDrawer/AssemblyDefinitionFiles/BuildValidation 均仅在本 Source 出现 1 次，未达 ≥2 次独立建页阈值，保留于 Source Page 内嵌引用。 + +## [2026-04-26] ingest | Unreal Systems Engineer +- Source file: Agent/agency-agents/game-development/unreal-engine/unreal-systems-engineer.md +- Status: ✅ 成功摄入 +- Summary: UnrealSystemsEngineer——Unreal Engine 5 系统架构工程师 AI Agent 人格规范。核心职责：构建 AAA 级 UE5 游戏系统的性能与混合架构，涵盖 C++/Blueprint 边界决策、Nanite 几何管线、GAS 网络配置、智能指针内存安全、Unreal Build System 反射宏规范。核心理念：Tick 逻辑必须 C++，Blueprint 是设计师 API 而非运行时引擎；Nanite 单场景 1600 万实例上限需提前规划；所有 UObject 指针必须 UPROPERTY() 声明。关键规范：C++ 承担所有每帧逻辑；Blueprint 适用于：高层游戏流、UI 原型、设计师可扩展层；Nanite 不兼容骨骼网格/复杂 clip/样条网格/程序化网格；TWeakObjectPtr/TSharedPtr 处理非拥有引用；FGameplayTag 替代字符串标识符；GAS 通过 UAbilitySystemComponent 复制。高级能力：Mass Entity（Unreal ECS，处理海量 NPC）、Chaos 破坏系统（Geometry Collection 实时断裂）、Lyra 模块化框架（GameFeatureAction 运行时注入）。成功指标：零 Blueprint Tick 函数（已交付代码）、Nanite 实例预算已规划、无 UPROPERTY() 缺失警告、帧预算 60fps（目标硬件）。 +- Concepts created/updated: [[GAS-Gameplay-Ability-System]]（更新 sources 字段，新增 UnrealSystemsEngineer 补充：Tick 逻辑必须 C++、FGameplayTag 优于字符串、GAMEPLAYATTRIBUTE_REPNOTIFY 宏）、[[Nanite]]（更新 sources 字段，新增 UnrealSystemsEngineer 补充：1600万实例上限、显式切线禁用、r.Nanite.Visualize 兼容检测） +- Entities updated: [[UnrealEngine5]]（Unreal Technical Artist 已有，无需新建） +- Source page: wiki/sources/unreal-systems-engineer.md +- Notes: index.md Sources 替换占位条目为正式摘要（2026-04-26，unreal-systems-engineer.md）；index.md Concepts 无需新增条目（GAS/Nanite 均已存在）；overview.md Game Development 部分新增 unreal-systems-engineer 独立 entry，与 unreal-multiplayer-architect/unreal-technical-artist 共同构成 UE5 专精团队；冲突检测：与 [[UnrealMultiplayerArchitect]] 在 GAS 职责边界存在互补关系——系统工程师负责 C++ 实现和网络复制配置，网络架构师负责 RPC 层安全和服务器权威验证，已在 Source Page Contradictions 节记录；Entity 去重：UnrealEngine5 已在其他来源出现，无需新建；Entity/Concept 去重：Mass Entity/Chaos Physics/Lyra 高级能力各仅在 Advanced Capabilities 部分出现 1 次，未达≥2次独立建页阈值，保留于 Source Page 内嵌引用。 + +## [2026-04-26] ingest | Unreal Multiplayer Architect +- Source file: Agent/agency-agents/game-development/unreal-engine/unreal-multiplayer-architect.md +- Status: ✅ 成功摄入 +- Summary: Unreal Multiplayer Architect——Unreal Engine 5 多人游戏网络架构师 AI Agent 人格规范。核心职责：构建服务器权威的 UE5 多人游戏网络系统，涵盖 Actor 复制、RPC 安全验证、网络预测、GAS 复制及专用服务器配置。核心理念：服务器拥有真相，客户端仅发送请求——所有游戏状态变更必须由服务器执行。关键规范：每个游戏影响型 Server RPC 必须实现 `_Validate()`（缺失即构成作弊漏洞）；`HasAuthority()` 检查必须在每次状态变更前执行；网络复制频率按 Actor 类型精细调整（投射物 100Hz/NPC 20Hz/环境物 2Hz）；GameMode 仅运行于服务器从不复制，GameState 复制到所有客户端，PlayerController 仅复制给拥有者。成功指标：带宽 < 15KB/s/玩家，200ms 延迟下调和事件 < 1次/玩家/30秒，RPC 安全审计零作弊向量。 +- Concepts created/updated: [[Server-Authoritative-Model]]（更新 sources 字段）、[[Actor-Replication]]（更新 sources 字段）、[[RPC-Remote-Procedure-Call]]（更新 sources 字段）、[[Network-Prediction]]（更新 sources 字段）、[[Replication-Graph]]（新建——UE5 空间分区复制优化系统）、[[GAS-Gameplay-Ability-System]]（新建——UE5 技能与属性管理框架，含网络预测） +- Entities updated: [[UnrealMultiplayerArchitect]]（已有，更新来源关联） +- Source page: wiki/sources/unreal-multiplayer-architect.md +- Notes: index.md Sources 新增条目（2026-04-26，unreal-multiplayer-architect.md）；index.md Concepts 新增 GAS-Gameplay-Ability-System 条目；新建 concepts/Replication-Graph.md 和 concepts/GAS-Gameplay-Ability-System.md；overview.md Game Development 部分新增 unreal-multiplayer-architect 独立 entry；冲突检测：无已知冲突（Source Page Contradictions 节为空——本技术领域为独立领域）。 + +## [2026-04-26] ingest | Unreal World Builder Agent Personality +- Source file: Agent/agency-agents/game-development/unreal-engine/unreal-world-builder.md +- Status: ✅ 成功摄入 +- Summary: UnrealWorldBuilder——Unreal Engine 5 开放世界环境架构工程师 AI Agent 人格规范。核心职责：使用 UE5 World Partition、Landscape、PCG、HLOD 系统构建 4km²~64km² 超大规模开放世界。核心理念：用格子大小控制流送预算，用 RVT 消除地形层混合成本。关键规范：World Partition 格子策略（密集城区64m/空旷地形128m/沙漠海洋256m+）；Always Loaded 层存放全局内容，关键游戏内容禁止放格子边界；Landscape 单区域最多4层材质，超过2层必须启用RVT；HLOD 覆盖所有500m+可见区域；PCG 大规模植被使用 Nanite 预烘焙；Foliage Tool 仅用于手工放置主角物件；LWC 在任何轴>2km的世界必须启用。高级能力：LWC 双精度坐标（20km后浮点精度误差）、OFPA 多用户协作、Unreal Insights 性能分析。成功指标：地面疾跑无>16ms流送卡顿、1km²+区域预烘焙、HLOD覆盖500m+区域、Landscape层数永不超4。 +- Concepts created: [[WorldPartition]]（新建）、[[RuntimeVirtualTexturing]]（新建）、[[LargeWorldCoordinates]]（新建） +- Concepts updated: [[PCG]]（追加 unreal-world-builder 来源）、[[LOD]]（追加 unreal-world-builder 来源）、[[Nanite]]（追加 unreal-world-builder 来源） +- Entities updated: [[UnrealEngine5]]（追加 unreal-world-builder 来源） +- Source page: wiki/sources/unreal-world-builder.md +- Notes: index.md Sources 新增条目（紧随 unreal-systems-engineer 之后）；overview.md UnrealSystemsEngineer 条目后新增 unreal-world-builder 独立 entry；冲突检测：未发现与现有 Wiki 内容的冲突；Entity 去重：Epic Games 仅提及1次，未达≥2次阈值；UnrealEngine5 已存在，直接追加来源；HLOD 已在 LOD.md 提及，无需独立建页。 + +## [2026-04-26] ingest | Game Designer Agent Personality +- Source file: Agent/agency-agents/game-development/game-designer.md +- Status: ✅ 成功摄入 +- Summary: Game Designer Agent——游戏系统与机制设计师 AI Agent 人格规范。以"循环、杠杆、玩家动机"为思维框架，将创意愿景转化为可执行、无歧义的游戏设计文档（GDD）。核心理念：从玩家动机出发设计，从功能列表出发设计。五步工作流：概念→设计支柱→纸面原型→GDD撰写→调优迭代。三层核心循环：瞬间体验（0-30秒）→会话目标（5-30分钟）→长期进阶（数小时至数周）。所有数值从假设开始，用 [PLACEHOLDER] 标记直至测试验证。高级能力：行为经济学应用（Cialdini 影响原则/损失厌恶/变率奖励/沉没成本）、跨类型机制移植（机制活检分析）、高级经济设计（供给-需求模型/通胀检测/Monte Carlo 模拟）、系统性涌现设计（系统交互矩阵/最小可行复杂度）。 +- Concepts created: [[Core-Gameplay-Loop]]（核心游戏循环三层模型）、[[Economy-Balance]]（游戏经济平衡设计——供给-需求模型、玩家画像、通胀检测） +- Entities created: 无（本文档未明确提及具体人物或公司，均为通用游戏开发概念，未达 Entity 建页阈值；GameDesigner Agent 本身属于 Agent 类型而非 Entity 类型） +- Source page: wiki/sources/game-designer.md +- Notes: index.md Sources 新增条目（2026-04-26，game-designer.md）；index.md Concepts 新增 2 个条目（Core-Gameplay-Loop/Economy-Balance）；overview.md Game Development 部分新增 game-designer 独立 entry（与 technical-artist/narrative-designer/level-designer 构成完整 Game Dev 设计体系）；冲突检测：无已知冲突（Source Page Contradictions 节为空）；Entity 去重：无 Entity 达标（GameDesigner Agent/Narrative Designer/Level Designer/Game Audio Engineer/Technical Artist 均为 Agent 类型，不建 Entity 页面）。 + +## [2026-04-26] ingest | Unreal Technical Artist +- Source file: Agent/agency-agents/game-development/unreal-engine/unreal-technical-artist.md +- Status: ✅ 成功摄入 +- Summary: Unreal Technical Artist——Unreal Engine 5 视觉系统工程师 AI Agent 人格定义。拥有 Material Editor、Niagara VFX、PCG、Substrate 和 Nanite 全栈专业能力，负责 UE5 项目的美术-引擎视觉管线。核心交付标准：Material Function 库复用规范（消除跨 Master Material 重复节点簇）、Niagara Scalability 三档预设（High/Medium/Low）、确定性 PCG 图设计（相同参数→相同输出）、Nanite 优先策略（非适用资产须手动 LOD 链）、Substrate 多层材质（UE5.3+ 替代 SSS workaround）。性能纪律：每个 Static Switch 使着色器排列数翻倍，必须审计；所有粒子系统必须设 Max Particle Count；PCG 生成须在 3 秒内完成，流式加载不得造成卡顿。 +- Concepts created: [[MaterialFunction]]（UE5 材质系统中可复用的节点逻辑封装单元）、[[NiagaraVFX]]（UE5 新一代粒子和 VFX 系统，支持 GPU/CPU 模拟分离与 Scalability 分级）、[[PCG]]（程序化内容生成框架，通过图节点控制开放世界资产分布）、[[Nanite]]（UE5 虚拟几何体系统，支持自动 LOD 和海量实例化渲染）、[[Substrate]]（UE5.3+ 多层物理材质系统，替代传统 SSS workaround）、[[LOD]]（Level of Detail，根据距离动态切换网格精度）、[[QualitySwitch]]（UE5 材质质量分层节点，支持 Mobile/Console/PC 三档） +- Entities created: [[UnrealEngine5]]（Epic Games 开发的游戏引擎，提供 Material Editor、Niagara、PCG、Nanite 等视觉工具链） +- Source page: wiki/sources/unreal-technical-artist.md +- Notes: index.md Sources 新增条目（2026-04-26，unreal-technical-artist.md）；index.md Entities 新增 UnrealEngine5 条目；index.md Concepts 新增 7 个条目（MaterialFunction/NiagaraVFX/PCG/Nanite/Substrate/LOD/QualitySwitch）；overview.md Game Development 部分新增 unreal-technical-artist 独立 entry，与 Technical Artist 基类形成继承关系；index.md 中 LOD-Pipeline 重复条目已清理；冲突检测：无已知冲突（Source Page Contradictions 节为空）。 + +- Source file: Agent/agency-agents/game-development/narrative-designer.md +- Status: ✅ 成功摄入 +- Summary: Narrative Designer Agent——游戏叙事设计师 AI Agent 人格规范。核心职责：将叙事设计为一套选择-后果-世界一致性的系统，与游戏机制深度整合。关键规范：对话必须通过"真实人物说话"测试；选择必须类型不同且有 2 beats 内后果；Lore 三层可选深度（Surface/Engaged/Deep）；环境叙事通过道具无声讲述故事；叙事-玩法整合矩阵确保故事节点连接游戏机制；玩家叙事代理权与机械代理权必须匹配。 +- Concepts created: [[Branching-Narrative]]（分支叙事设计——选择树结构、收敛策略、后果可见性）、[[Character-Voice-Pillars]]（角色声音柱五维度体系）、[[Choice-Architecture]]（选择架构——有意义选择、Fake Choice 刻意使用、延迟后果、后果可见性映射）、[[Dialogue-Writing-Standards]]（对话写作标准——无"as you know"、三遍编辑法）、[[Lore-Architecture]]（Lore 三层可选深度架构 + 世界圣经）、[[Narrative-Gameplay-Integration]]（叙事-玩法整合矩阵）、[[Narrative-Debt-Tracking]]（叙事债务追踪——伏笔承诺管理）；existing: [[Environmental-Storytelling]]（更新：新增 Narrative Designer 为来源，新增 Lore Architecture 连接） +- Entities created: 无（本文档未明确提及具体人物或公司，均为通用游戏开发概念，未达 Entity 建页阈值） +- Source page: wiki/sources/narrative-designer.md +- Notes: index.md Sources 新增条目（game-development 类，置于 Game Audio Engineer 后）；index.md Concepts 新增 7 个条目（Branching-Narrative/Character-Voice-Pillars/Choice-Architecture/Dialogue-Writing-Standards/Lore-Architecture/Narrative-Debt-Tracking/Narrative-Gameplay-Integration）；overview.md Game Development 部分新增 narrative-designer 独立 entry；冲突检测：与 [[Level Designer Agent]] 在环境叙事执行边界存在职责分工争议——叙事设计师定义叙事内容架构，关卡设计师执行物理空间设计，已在 Source Page Contradictions 节记录；Entity 去重：无 Entity 达标（Ink/Yarn/Twine 为工具术语，不建页）。 + +## [2026-04-26] ingest | Level Designer Agent Personality +- Source file: Agent/agency-agents/game-development/level-designer.md +- Status: ✅ 成功摄入 +- Summary: Level Designer Agent——游戏关卡设计师 AI Agent 人格规范。核心职责：通过空间架构引导、挑战和沉浸玩家。关键规范：关键路径必须视觉可读（除非刻意设计迷路）；每个战斗遭遇必须包含读图时间、多种战术选项和退守位置；难度先从空间出发再考虑数值缩放；灰盒纪律（设计决策在灰盒阶段锁定，禁止在未测试布局上美术包装）。六阶段工作流：意图定义→纸面布局→灰盒搭建→遭遇战调优→美术交接→打磨验收。高级能力：空间心理学（prospect-refuge/figure-ground/Lynch 城市设计）、程序化关卡生成、速通设计、多人/竞技空间设计。 +- Concepts created: [[Flow-And-Readability]]（关卡流与可读性）、[[Encounter-Design]]（遭遇战设计）、[[Environmental-Storytelling]]（环境叙事）、[[Blockout-Discipline]]（灰盒纪律）、[[Pacing-Architecture]]（节奏架构）、[[Spatial-Psychology]]（空间心理学）、[[Procedural-Level-Design]]（程序化关卡设计）、[[Speedrun-Design]]（速通设计） +- Entities created: 无（本文档未明确提及具体人物或公司，均为通用游戏开发概念，未达 Entity 建页阈值） +- Source page: wiki/sources/level-designer.md +- Notes: index.md Sources 替换"expected: source missing"为正式条目（2026-04-26）；index.md Concepts 新增 8 个 Concept 条目（Blockout-Discipline/Environmental-Storytelling/Encounter-Design/Flow-And-Readability/Pacing-Architecture/Procedural-Level-Design/Spatial-Psychology/Speedrun-Design）；冲突检测：无已知冲突（Source Page Contradictions 节为空）；overview.md：属于 Game Development 分支，与现有 game-designer、technical-artist、game-audio-engineer 等同属，无冲突，无需更新 overview；Entity 去重：无 Entity 达标（Technical Artist 文档中提及但未在本文档重复出现）。 + +## [2026-04-26] ingest | Game Audio Engineer +- Source file: Agent/agency-agents/game-development/game-audio-engineer.md +- Status: ✅ 成功摄入 +- Summary: Game Audio Engineer Agent——游戏交互式音频工程师 AI Agent 人格规范，设计自适应音乐系统、空间音频架构和音频中间件集成方案。核心规范：所有游戏音频必须通过 FMOD/Wwise 中间件事件系统触发，自适应音乐通过 tension parameter（0–1）驱动层切换（tempo-synced），空间音频通过 raycast 驱动 occlusion 参数（800Hz 低通截止，每帧最多 4 个 raycast），语音预算 PC 64/Console 48/Mobile 24，FMOD DSP 每帧 ≤1.5ms，Reverb Zone 分四类（Outdoor/Indoor/Cave/Metal Room）。 +- Concepts created: [[AdaptiveMusic]]（由游戏状态参数驱动的动态音乐系统，通过中间件参数 API 实现实时层切换与混音）、[[SpatialAudio]]（基于 3D 空间化的音效定位与衰减系统，含 occlusion raycast 驱动的参数和 reverb zone 匹配规范） +- Entities created: [[FMOD]]（Firelight Technologies 开发的游戏音频中间件，事件驱动架构，跨引擎支持）；其他实体（Wwise/Unity/Unreal/Godot/Dolby Atmos/DTS:X）各仅出现 1 次，未达 Entity 建页阈值（≥ 2 次） +- Source page: wiki/sources/game-audio-engineer.md +- Notes: index.md Sources 替换"expected: source missing"为正式条目（2026-04-26）；index.md Concepts 新增 2 个条目（AdaptiveMusic/SpatialAudio）；index.md Entities 新增 FMOD 条目；overview.md 新增"Game Development"独立 section（置于 Specialized 部门与 Conflict Areas 之间）；冲突检测：无已知冲突（Source Page Contradictions 节为空）；Entity 去重：FMOD 出现 2 次（FMOD Event System 集成 + C# AudioManager 示例），达到建页阈值；其他中间件/引擎各 1 次，未达阈值。 + +## [2026-04-26] ingest | AI Citation Strategist +- Source file: Agent/agency-agents/marketing/marketing-ai-citation-strategist.md +- Status: ✅ 成功摄入 +- Summary: AI Citation Strategist Agent——专注于 AI 推荐引擎优化（AEO/GEO）的营销 Agent。审计品牌在 ChatGPT、Claude、Gemini、Perplexity 四大 AI 平台上的引用可见性，识别竞品被引用的原因，生成优先级 Fix Pack 改善内容信号。核心方法：多平台 Citation Audit Scorecard → Lost Prompt Analysis → 竞品内容结构映射 → Schema markup + 实体信号优化 → Fix Pack 优先级实施。关键指标：30 天内引用率提升 20%+、Lost Prompts 恢复率 40%+、3+ 平台被引用。核心理念：AI 引用与传统 SEO 是不同策略，必须作为独立策略对待。 +- Concepts created: [[Answer Engine Optimization (AEO)]]（AI 问答引擎优化，使品牌内容被 AI 引用）、[[Generative Engine Optimization (GEO)]]（生成式 AI 引擎可见性优化，信号工程提升引用概率）、[[Citation Rate]]（AI 引用率，衡量品牌在 AI 推荐引擎中可见性的核心指标）、[[Fix Pack]]（AI 引用审计后的优先级修复包，含具体修改方案和预期改善幅度）、[[Lost Prompt Analysis]]（识别品牌缺席但竞品胜出的查询场景，分析失败原因）、[[Entity Optimization]]（强化品牌实体信号，使 AI 引擎清晰识别和信任品牌实体） +- Entities created: 无（ChatGPT/Claude/Gemini/Perplexity 均为知名 AI 产品平台，业界通用概念，无需独立 Entity 页面；相关 Platform-Specific Patterns 作为 Concept 内嵌，未达 Entity 建页阈值） +- Source page: wiki/sources/marketing-ai-citation-strategist.md +- Notes: index.md 新增 Sources 条目（2026-04-26）；index.md Concepts 新增 6 个 Concept 条目（Answer-Engine-Optimization/Generative-Engine-Optimization/Citation-Rate/Fix-Pack/Lost-Prompt-Analysis/Entity-Optimization）；overview.md 新增 AI Citation Strategist 独立 entry，置于 nexus-spatial-discovery 之前；冲突检测：与 [[Marketing SEO Specialist]] 存在核心策略冲突——传统 SEO 成功不能自动转化为 AI 可见性，AEO 与 SEO 必须作为不同策略对待，已在 Source Page Contradictions 节记录；overview.md Conflict Areas 新增第 20 条冲突点（SEO vs AEO 策略体系差异）；Entity 去重：ChatGPT/Claude/Gemini/Perplexity 四平台均为业界通用 AI 产品概念，无需独立 Entity 页面；Platform-Specific Patterns 作为 Concept 内嵌概念，未达 Entity 建页阈值（出现频次 < 2，且为核心功能描述而非独立实体）。 + +## [2026-04-26] ingest | Marketing Growth Hacker +- Source file: Agent/agency-agents/marketing/marketing-growth-hacker.md +- Status: ✅ 成功摄入 +- Summary: 增长黑客 Agent——通过数据驱动的实验和非常规营销策略，实现快速、可规模化的用户获取与留存。核心方法：增长漏斗优化（Awareness→Acquisition→Activation→Retention→Revenue→Referral）+ A/B/多变量实验体系（每月10+实验，30%胜出率）+ 病毒系数工程（K-factor > 1.0）+ 北极星指标体系（North Star Metric）+ LTV:CAC 经济学（LTV:CAC ≥ 3:1）。关键指标：月环比自然增长 20%+、K-factor > 1.0、CAC 回本周期 < 6个月、首周激活率 60%+、Day 7 留存 40%。核心理念：找到那个还没被人涉足的流量渠道，然后把它规模化。 +- Concepts created: [[GrowthFunnelOptimization]]（增长漏斗优化：AARRR 六阶段全链路转化率提升）、[[ViralLoop]]（病毒裂变机制：K-factor = 邀请率 × 接受率，K > 1.0 实现指数级自然增长）、[[NorthStarMetric]]（北极星指标：产品核心价值的单一衡量指标，驱动增长优先级）、[[KFactor]]（病毒系数：K > 1.0 意味着指数级自然增长，K = 邀请率 × 接受率）、[[CACandLTV]]（单位经济学：客户获取成本与生命周期价值，LTV:CAC ≥ 3:1 为健康门槛）、[[ProductLedGrowth]]（产品导向增长：通过产品体验驱动获取与留存，而非依赖营销渠道） +- Entities created: 无（Growth Hacker Agent/The Agency 均为 Agent 角色/组织概念，不满足 Entity 实体定义，无需独立 Entity 页面） +- Source page: wiki/sources/marketing-growth-hacker.md +- Notes: index.md 新增条目（Sources 首位，2026-04-26）；index.md Concepts 首位新增 6 个 Concept 条目；overview.md 新增 "Data-Driven Growth & Experimentation" 段落，置于 Content Strategy & Production 与 Professional Social Media 之间，阐述 Growth Hacker 与 Content Creator/Social Media Strategist/TikTok Strategist 的协同关系及策略差异；冲突检测：与 [[marketing-tiktok-strategist]] 存在渠道优先级冲突——TikTok Strategist 以平台内容为核心预设 TikTok 为最重要渠道，Growth Hacker 以实验数据为核心不预设平台偏好，已在 Source Page Contradictions 节记录；Entity/Concept 去重：Growth Hacker Agent（Agent 角色定义，非具体实体，不建页）、The Agency（组织概念，不建页）；本次 6 个概念均已抽象为独立 Concept 页面（GrowthFunnelOptimization/ViralLoop/NorthStarMetric/KFactor/CACandLTV/ProductLedGrowth），满足可复用、可抽象原则。 + +## [2026-04-26] ingest | Marketing Xiaohongshu Specialist +- Source file: Agent/agency-agents/marketing/marketing-xiaohongshu-specialist.md +- Status: ✅ 成功摄入 +- Summary: 小红书（中国生活方式种草平台）品牌营销专家 Agent——将品牌打造为小红书顶流，通过生活方式品牌定位 + 趋势驱动内容策略 + 微内容优化 + 社区互动 + 数据迭代五阶段工作流实现增长。核心公式：70%有机生活内容 + 20%趋势参与 + 10%品牌直接推广。关键指标：互动率5%+、收藏率8%+、分享率2%+、每月1-2条爆款（100k+浏览）。核心原则：社区优先互动（发帖后2小时内回复）、审美一致性、真实叙事、算法趋势驾驭（24小时内识别并参与趋势）。 +- Concepts created: [[ContentMixStrategy]]（70/20/10内容配比策略）、[[TrendRiding]]（趋势驾驭方法论）、[[MicroInfluencerPartnership]]（微影响者合作策略） +- Entities created: [[XiaohongshuPlatform]]（小红书平台 Entity 页面） +- Source page: wiki/sources/marketing-xiaohongshu-specialist.md +- Notes: index.md 新增条目（Sources 首位，2026-04-26）；冲突检测：与 [[marketing-tiktok-strategist]] 存在内容时长偏好冲突——小红书最优视频15-60秒 vs TikTok最优60-90秒，已在 Source Page Contradictions 节记录；Entity/Concept 去重：B站（已存在 Entity）/GenZMillennials（通用术语，不新建）/KOLKOC（通用术语，不新建）；其他概念（MicroContentOptimization/CommunityFirstEngagement/UGCCampaign）本次以内嵌 wikilink 保留于 Source Page，未达独立建 Concept 阈值。 + +## [2026-04-26] ingest | Marketing Bilibili Content Strategist +- Source file: Agent/agency-agents/marketing/marketing-bilibili-content-strategist.md +- Status: ✅ 成功摄入 +- Summary: B站（Bilibili）平台内容策略与 UP主增长专家 Agent——专注于弹幕文化精通、B站算法优化、社区建设和品牌内容原生化。核心理念：社区第一、质量优先、B站用户最讨厌硬广。核心方法：四阶段工作流（平台洞察→内容架构→发布激活→增长优化）；弹幕互动设计模板；三连率（Coin+Favorite+Like）驱动的内容包装体系（目标>5%）；恰饭内容原生化策略；内容分区（知识区/科技区/生活区等）独立赛道逻辑。关键指标：三连率>5%、弹幕密度>30条/分钟、每月至少一条视频进入"每周必看"或"热门推荐"。 +- Concepts created: 无新 Concept（B站推荐算法/三连率/弹幕互动设计/恰饭内容/内容分区 均未达可独立抽象建页阈值，以内嵌 wikilink 保留于 Source Page） +- Entities created: 无（B站/UP主/花火平台/BML/三连 均为平台概念或通用营销术语，无需独立 Entity 页面） +- Source page: wiki/sources/marketing-bilibili-content-strategist.md +- Notes: index.md 新增条目（Sources 首位，2026-04-26）；overview.md 新增独立 entry，置于 Douyin Strategist 与 TikTok Strategist 之间，补充与 Douyin Strategist/Kuaishou Strategist/China Market Localization Strategist/Video Optimization Specialist 的协同关系；冲突检测：与 [[marketing-douyin-strategist]] 存在策略差异冲突——抖音以算法推荐驱动流量爆发（中心化分发），B站 以社区文化和弹幕互动为核心（订阅关系），两者不可套用同一策略，已在 Source Page Contradictions 节记录。 + +## [2026-04-26] ingest | Marketing Content Creator +- Source file: Agent/agency-agents/marketing/marketing-content-creator.md +- Status: ✅ 成功摄入 +- Summary: 多平台内容创作专家 Agent——专注于跨平台品牌内容策略制定、叙事构建和受众互动优化。核心能力：内容策略框架（编辑日历+内容支柱+受众优先规划）、多格式创作（图文/视频/播客/信息图/社媒）、品牌叙事、SEO 内容优化（目标40%有机流量增长）、视频制作全链路（目标70%完播率）、绩效分析（目标5:1 ROI）。核心理念：在每个受众所在的平台上，创作有吸引力的故事。 +- Concepts created: 无新 Concept（Content Strategy/Brand Storytelling/SEO Content/Video Production/Copywriting 等在本次源文档中为核心能力描述，未达可独立抽象建页阈值，均以内嵌 wikilink 保留于 Source Page） +- Entities created: 无（YouTube/TikTok/Instagram/Podcast 均为平台类型，TikTok 已在其他 Agent 中提及，本次作为内嵌引用不新建 Entity） +- Source page: wiki/sources/marketing-content-creator.md +- Notes: index.md 新增条目（Sources 首位，2026-04-26）；overview.md 新增 "Content Strategy & Production" 段落，置于 TikTok E-commerce Operations 与 Professional Social Media 之间，阐述与 Social Media Strategist/Twitter Engager/LinkedIn Content Creator/TikTok Strategist/Video Optimization Specialist/Growth Hacker 的协同关系；冲突检测：无已知冲突——Content Creator 与其他营销 Agent 构成"内容生产→平台分发"的互补关系，无竞争性冲突；Entity/Concept 去重：各平台（YouTube/TikTok/Instagram/Podcast）均无独立 Entity 页面，本次作为内嵌引用，不新建；Thought Leadership/Content Strategy/Brand Storytelling 等均作为方法论描述保留于 Source Page，不独立建 Concept 页。 + +- Source file: Agent/agency-agents/marketing/marketing-twitter-engager.md +- Status: ✅ 成功摄入 +- Summary: Twitter 实时互动与思想领袖建立专家 Agent——通过真实对话参与、领袖思想内容创作和社区驱动增长构建品牌权威。核心理念：Twitter 成功来自真实参与而非广播。核心方法：内容配比策略（教育25%/个人故事20%/行业评论20%/社区互动15%/推广10%/娱乐10%）；四阶段工作流（实时监控→思想领袖建立→社区建设→效果优化）；Twitter Spaces（200+ 实时听众）；危机管理协议（<30 分钟响应）。关键指标：互动率≥2.5%、回复率80%（2小时内）、教育 thread≥100 转推。 +- Concepts created: 无新 Concept（Thread-Mastery、Community-Building、Crisis-Management、Twitter-Spaces 等在本次源文档中为方法论描述，未达可独立抽象建页阈值，均以内嵌 wikilink 保留于 Source Page；[[Thought-Leadership]] 已存在，本次直接引用） +- Entities created: 无（Twitter 作为平台无需 Entity 页面；Brand Authority 为抽象概念而非具体实体） +- Source page: wiki/sources/marketing-twitter-engager.md +- Notes: index.md 新增条目（Sources 首位，2026-04-26）；overview.md 在 marketing-social-media-strategist 条目后新增独立 entry，补充与 Social Media Strategist/Growth Hacker/LinkedIn Content Creator 的协同关系；冲突检测：无已知冲突——与 Wiki 中其他营销 Agent 构成互补而非竞争关系；Entity/Concept 去重：Thought-Leadership 已存在 Entity 页面，本次直接 wikilink 引用；其余概念本次均以内嵌方式保留于 Source Page。 + + +- Source file: Agent/agency-agents/marketing/marketing-livestream-commerce-coach.md +- Status: ✅ 成功摄入 +- Summary: 直播带货全链路运营教练 Agent——覆盖主播孵化（五阶段话术框架+三阶段主播进阶）、流量运营（自然流量放大+千川付费投放+三阶段流量演进模型）、产品排品策略、数据复盘体系，覆盖抖音/快手/淘宝直播/微信视频号四大平台。核心公式「流量×转化率×客单价=GMV」，算法优先级「停留时长>互动率>点击率>购买转化率」。 +- Concepts created: [[Five-Phase-Script-Framework]]（五阶段话术框架——留人钩子→产品介绍→信任建立→紧迫成交→追单挽留）、[[Host-Incubation-System]]（主播孵化体系——素人→能播4h→能控节奏→能拉自然流量三阶段进阶）、[[Organic-Traffic-Amplification]]（自然流量放大——通过停留时长和互动率触发平台推荐算法，核心指标：停留>60s、互动率>5%） +- Source page: wiki/sources/marketing-livestream-commerce-coach.md +- Notes: index.md 新增条目（Sources 首位，2026-04-26）；index.md Concepts 首位新增三个 Concept 条目；overview.md 在 marketing-kuaishou-strategist 条目后插入完整 entry，阐述与 Douyin/Kuaishou 两大策略 Agent 的协同关系；冲突检测：无已知冲突——五阶段话术框架与快手 3-2-1 公式属互补框架（不同场景配比），停留时长核心指标与 Douyin Strategist 一致，成熟期自然流量>50% 与 Private Domain Operator 公域→私域转化模型一致；Entity 去重：Douyin/Kuaishou/OceanEngine 均已存在 Entity 页面，本次以内嵌 wikilink 引用，不新建；Taobao/Channels 仅提及1次，不满足≥2次门槛，不新建 Entity。 + +- Source file: Agent/agency-agents/marketing/marketing-tiktok-strategist.md +- Status: ✅ 成功摄入 +- Summary: TikTok 病毒式内容创作与品牌增长策略专家 Agent——深度掌握 TikTok 推荐算法机制、病毒内容公式和社区建设策略。核心理念：TikTok 的核心不是"制作好看的视频"，而是"驾驭算法和文化浪潮，将品牌转化为病毒级现象"。核心方法：3秒黄金钩子法则（每条视频前3秒必须捕获注意力）；40/30/20/10 内容配比（教育40%/娱乐30%/激励20%/促销10%）；互动速度优化（发布后第一小时内最大化点赞、评论、分享）；四级创作者分层（Nano/Micro/Mid-tier/Macro）。绩效指标：互动率 8%+（行业均值5.96%）、品牌内容完播率 70%+、品牌 hashtag 挑战 1M+ 浏览、创作者合作 ROI 4:1。交付物涵盖病毒脚本结构、跨平台适配策略（Reels/Shorts）、TikTok Ads 全漏斗架构（In-feed/Spark Ads/TopView）。 +- Concepts created: 无新 Concept（ForYouPageAlgorithm、ViralContentFormula、ContentPillarStrategy、CreatorEconomy、EngagementVelocity 等在 Source Page 内嵌定义，未达独立建页阈值） +- Entities created: 无（TikTok 作为平台在 index 中已存在或待确认；Instagram Reels/YouTube Shorts 各仅提及 1 次，不满足≥2次门槛，本次均以内嵌 wikilink 保留于 Source Page） +- Source page: wiki/sources/marketing-tiktok-strategist.md +- Notes: index.md 新增条目（置于 Sources 首位，2026-04-26）；overview.md 在 Douyin Strategist 条目后插入独立 Marketing TikTok Strategist 完整条目，补充算法权重差异（完播率 vs 分享率/互动率）、受众文化差异的详细对比；冲突检测：与 [[MarketingLinkedInContentCreator]] 存在内容风格冲突（短视频娱乐 vs 长文专业），与 [[MarketingWeChatOfficialAccount]] 存在公域 vs 私域策略差异，已在 Contradictions 中记录；Entity/Concept 去重：Instagram Reels/YouTube Shorts/UGCCampaign 等各仅提及 1 次，本次不单独建页。 + +## [2026-04-26] ingest | Marketing SEO Specialist +- Source file: Agent/agency-agents/marketing/marketing-seo-specialist.md +- Status: ✅ 成功摄入 +- Summary: Google 搜索生态 SEO 专家 Agent——通过技术 SEO、关键词集群策略、内容优化、链接权威建设和搜索分析实现可持续有机流量增长。核心理念：可持续有机增长来自技术卓越、高质量内容和权威链接档案三者的交叉点；排名是价值的自然结果。五阶段工作流：发现→关键词策略→cannibalization 检测→技术执行→权威建设→测量迭代。强制 cannibalization 审查（Pillar+Satellite 集群架构）、Core Web Vitals 基准（LCP<2.5s，INP<200ms，CLS<0.1）。白帽 SEO 是唯一合规方式。高级能力：国际化 SEO、程序化 SEO、算法恢复、AI 搜索优化。 +- Concepts created: 无新 Concept（TopicCluster/ContentCannibalization/CoreWebVitals/E-E-A-T/SchemaMarkup/SearchIntent/InternalLinking/LinkAuthority/SERPFeature/ProgrammaticSEO/AISearchOptimization 等在本次源文档中为框架性提及，未达独立建页阈值，均以内嵌 wikilink 保留于 Source Page） +- Entities created: 无（ScreamingFrog/Sitebulb/GoogleSearchConsole/LookerStudio 等在本次源文档中为工具列举，不满足独立 Entity 建页条件，均以内嵌 wikilink 保留于 Source Page） +- Source page: wiki/sources/marketing-seo-specialist.md +- Notes: index.md 新增条目（置于 Sources 首位）；overview.md 新增 Marketing SEO Specialist 条目（置于 App Store Optimizer 条目末尾，补充与 baidu-seo-specialist 的市场差异化说明）；冲突检测：与 [[marketing-baidu-seo-specialist]] 存在算法体系不可通用的根本差异——两者目标搜索引擎不同（Google vs 百度），已在 Contradictions 中记录；Entity/Concept 去重：ScreamingFrog/Sitebulb 等工具性提及、CoreWebVitals 等框架性概念，本次均以内嵌 wikilink 保留于 Source Page，不单独建页。 + +- Source file: Agent/agency-agents/marketing/marketing-china-market-localization-strategist.md +- Status: ✅ 成功摄入 +- Summary: 中国市场全栈本地化增长策略师 Agent——将实时趋势信号转化为可执行选品/内容/渠道 GTM 策略。核心理念：本地化不是翻译，是文化再工程。核心方法：7+ 中国平台热榜实时监控（见微知著/交叉验证/反直觉/MECE 四模型）；双轨分析（内容轨 + 评论轨）；六阶段 GTM 门控（P0 信号验证 → P5 成熟运营）；平台原生策略（绝不跨平台复制）。绩效指标：趋势信号在主流平台峰值前 ≥ 72 小时识别，每条建议附带 P0-P5 优先级。 +- Concepts created: [[Trend-To-Action]]（趋势行动框架——信号采集→深度分析→策略设计→GTM执行→测量迭代的完整闭环，双轨分析驱动）；[[Dual-Track-Analysis]]（双轨分析——内容轨+评论轨同时运行）；[[Phased-GTM-Gate]]（六阶段 GTM 门控 P0-P5）；[[Real-Time-Trend-Intelligence]]（实时趋势情报——四信号检测模型）；[[China-Consumer-Psychology]]（中国消费心理——面子/从众/性价比/国潮）；[[Seasonal-Consumption-Cycle]]（季节性消费周期——618/双十一/春节等关键节点） +- Entities created: 无（Douyin/WeChat/Bilibili/Xiaohongshu/Weibo/Zhihu/Kuaishou 均已存在 Entity 页面，本次以内嵌 wikilink 引用，不新建） +- Source page: wiki/sources/marketing-china-market-localization-strategist.md +- Notes: index.md 新增条目；overview.md 在 Douyin Strategist 后插入统领性 China Market Localization Strategist 条目，作为中国全平台营销矩阵的战略上层；更新 [[Cross-Platform-Strategy]] 概念，新增中国市场平台矩阵（微博/抖音/小红书/知乎/B站/微信/快手）；冲突检测：与 [[marketing-douyin-strategist]] 可能存在视角差异（抖音作为独立增长引擎 vs 作为 GTM 漏斗放大环节），已在 Contradictions 中记录；Entity 去重：Douyin/WeChat/Bilibili 等平台已存在 Entity 页面，本次以内嵌 wikilink 引用。 + +## [2026-04-26] ingest | App Store Optimizer +- Source file: Agent/agency-agents/marketing/marketing-app-store-optimizer.md +- Status: ✅ 成功摄入 +- Summary: App Store 优化（ASO）全栈专家 Agent——专注于应用商店搜索可见性优化、视觉资产转化率提升和可持续用户增长。核心理念：数据驱动 + 转化优先 + A/B 测试系统性优化。绩效目标：有机下载月增长 30%+、关键词前 10 排名 20+ 个、转化率提升 25%+、评分 4.5 星+。四阶段工作流：市场研究分析 → 策略开发 → 实施测试 → 优化规模化。 +- Concepts created: 无新 Concept（App-Store-Optimization-ASO、Conversion-Rate-Optimization、A-B-Testing、Keyword-Research 等在其他 Source Page 中已作为 wikilink 使用，未达独立建页阈值；本次均以内嵌 wikilink 保留于 Source Page） +- Entities created: 无（App Store、iOS、Android 等作为 Agent 运营平台提及，不满足≥2次独立 Entity 门槛，均以 wikilink 保留于 Source Page） +- Source page: wiki/sources/marketing-app-store-optimizer.md +- Notes: index.md 原占位条目（2026-04-22 expected）已替换为完整摘要；overview.md 新增 App Store Optimizer 条目（置于微信运营之后）；冲突检测：与 [[Marketing-SEO-Specialist]] 存在方法论差异但非冲突——ASO 与 SEO 分别服务 App Store 和 Web 两个不同发现渠道，实为互补关系，已在 Contradictions 中明确记录；Entity/Concept 去重：App Store/iOS/Android/Review-Management 等未达到≥2次独立 Entity 门槛，本次不单独建页。 + +## [2026-04-26] ingest | Marketing WeChat Official Account Manager +- Source file: Agent/agency-agents/marketing/marketing-wechat-official-account.md +- Status: ✅ 成功摄入 +- Summary: 微信公众号全栈运营专家 Agent——将公众号打造为高互动、强忠诚的社群中心。核心理念：公众号不是广播频道而是关系建设工具。核心方法：60/30/10 内容规则（60% 价值内容 + 30% 社群互动 + 10% 推广内容）；五阶段运营工作流（订阅者分析→内容策略→内容创作→自动化运营→数据分析）；微信原生功能整合（自动回复/关键词响应/菜单架构/小程序）。绩效目标：打开率 30%+（行业均值 2 倍）、菜单点击率 20%+、转化率 2-5%。 +- Concepts created: [[Content-60-30-10-Rule]]（内容比例法则——60% 价值内容 + 30% 社群互动 + 10% 推广内容） +- Entities created: [[WeChat]]（微信——中国最大私域社交平台，公众号是其核心商业通讯渠道） +- Source page: wiki/sources/marketing-wechat-official-account.md +- Notes: 与 [[marketing-weibo-strategist]] 存在互补关系——微博公域引爆→公众号私域沉淀；与 [[marketing-private-domain-operator]] 形成漏斗下游——公众号订阅者→企业微信私域运营。已在 [[marketing-weibo-strategist]] 的 Connections 中记录公众号为 complements 关系。 +## [2026-04-26] ingest | LinkedIn Content Creator +- Source file: Agent/agency-agents/marketing/marketing-linkedin-content-creator.md +- Status: ✅ 成功摄入 +- Summary: LinkedIn 专业内容创作者 Agent——专注于思想领导力内容、个人品牌建设和高互动专业内容生成，帮助用户将专业技能转化为可见的专业影响力。核心方法：七阶段完整工作流（受众分析→钩子工程→帖子构建→格式优化→轮播/文章制作→主页优化→互动策略）；基于算法的内容结构设计（保存率/早期velocity/停留时间三大信号）；按受众类型（创始人/求职者/开发者/B2B营销）定制化内容策略。核心理念：每个帖子必须有可辩护的观点；中性内容产生中性结果。 +- Concepts created: 无新 Concept（Thought-Leadership/Content-Pillar 已在 Wiki 中存在，本次更新其 Source 引用；Hook-Engineering/LinkedIn-Algorithm/Personal-Brand 等在其他 Source Page 中作为 wikilink 使用，未达独立建页阈值） +- Source page: wiki/sources/marketing-linkedin-content-creator.md +- Notes: index.md 原占位条目（2026-04-21 expected）已替换为完整摘要；冲突检测：与 [[Marketing-Social-Media-Strategist]] 为宽窄互补关系（非冲突——前者提供 LinkedIn 平台的具体执行方法论，后者提供跨平台战略框架）；overview.md 无需修订（已有大量营销内容，暂不需要修订综合摘要）；Entity/Concept 去重：Thought-Leadership/Content-Pillar 已存在，LinkedIn-Campaign-Manager 已存在，均无需重复创建，仅更新 sources 字段。 + +## [2026-04-26] ingest | Marketing Baidu SEO Specialist +- Source file: Agent/agency-agents/marketing/marketing-baidu-seo-specialist.md +- Status: ✅ 成功摄入 +- Summary: 百度搜索生态优化与中国市场 SEO 专家 Agent——专注于中文搜索引擎排名、百度生态整合（百科/知道/贴吧/文库/经验矩阵）、ICP 合规、中文关键词研究与移动优先索引。核心理念：ICP 备案是不可妥协的法定前提（"without ICP备案, nothing else matters"）；百度与 Google SEO 根本不同（需从零学习百度算法体系）。四阶段工作流：合规基础 → 关键词研究 → 站内技术优化 → 站外权威建设。五大算法应对：飓风（原创）/ 细雨（反堆砌）/ 惊雷（反点击操纵）/ 蓝天（新闻质量）/ 清风（反标题党）。与 Douyin/Kuaishou 属互补关系——百度捕获搜索意图用户（高意向），短视频平台创造需求引流。 +- Concepts created: [[Baidu-SEO]]（百度搜索引擎优化，与 Google SEO 有根本差异）、[[ICP-Filing]]（ICP 备案，中国网站合法运营的法定前提）、[[Baidu-Ecosystem-Integration]]（百度生态矩阵整合策略） +- Entities created: [[Baidu]]（百度，中国最大搜索引擎，五大生态产品矩阵） +- Source page: wiki/sources/marketing-baidu-seo-specialist.md +- Notes: index.md 原占位条目（2026-04-21 expected）已替换为完整摘要；overview.md 新增百度 SEO 条目，置于 Carousel Growth Engine 之前；Entity 去重检查：Baidu 未在 Wiki 中存在同名页面，新建 Baidu.md；Concept 去重检查：Baidu-SEO、ICP-Filing、Baidu-Ecosystem-Integration 均未在 Wiki 中存在同名页面；冲突检测：① 与 [[Marketing-Douyin-Strategist]] 和 [[Marketing-Kuaishou-Strategist]]：搜索意图（百度）vs 算法推送（短视频）互补而非竞争；② 与 Google SEO 最佳实践：百度有独立算法体系、ICP 备案要求、生态平台偏好、内容审查——Google 经验不可迁移已在 Contradictions 中记录。 + +## [2026-04-26] ingest | Marketing Private Domain Operator +- Source file: Agent/agency-agents/marketing/marketing-private-domain-operator.md +- Status: ✅ 成功摄入 +- Summary: 企业微信（WeCom）私域运营专家 Agent——专注于 SCRM 系统配置、分层社群 SOP 自动化、用户生命周期管理与全漏斗转化优化。核心理念：私域的本质是将信任建立为资产，通过系统化运营实现用户从首次接触到终身价值的全链路管理。五大核心模块：WeCom 生态搭建（渠道码/标签/SCRM 集成/合规存档）→ 分层社群运营（获客群/福利群/VIP 群/超 级用户群）→ 小程序电商联动 → 用户生命周期自动化 → 全漏斗转化。关键红线：社群内容 70%+ 价值/30% 促销、新客 7 天首购转化应超 20%、流失预警触发人工介入。 +- Concepts created: [[私域运营]]（私域运营全链路核心概念）、[[SCRM]]（社交客户关系管理工具与方法） +- Entities created: [[WeCom]]（企业微信，私域运营核心载体） +- Source page: wiki/sources/marketing-private-domain-operator.md +- Notes: index.md 原占位条目（2026-04-21 expected）已替换为完整摘要；冲突检测：无冲突——该 Agent 与公域运营 Agent（Douyin Strategist、Kuaishou Strategist 等）属互补关系，私域是公域流量的承接终点，无内容矛盾；Entity 去重检查：WeCom 未在 Wiki 中存在同名页面，新建 WeCom.md；Concept 去重检查：SCRM 和私域运营未在 Wiki 中存在同名页面，新建对应 Concept 页；overview.md 本次未更新（已有大量营销内容，暂不需要修订综合摘要）。 + +## [2026-04-26] ingest | Marketing Social Media Strategist +- Source file: Agent/agency-agents/marketing/marketing-social-media-strategist.md +- Status: ✅ 成功摄入 +- Summary: 跨平台社交媒体战略专家 Agent——专注于 LinkedIn、Twitter 等专业社交平台的企业级品牌建设和社群运营。核心能力：LinkedIn 全栈运营（公司页面/个人品牌/专栏文章/新闻通讯/LinkedIn Ads）；Twitter 实时协同（与 Twitter Engager Agent 协作保持一致声音）；B2B 社交销售策略与销售管道开发；员工倡导计划设计与品牌大使激活；跨平台内容瀑布流（LinkedIn 首发 → Twitter 适配 → 其他平台分发）。成功指标：LinkedIn 互动率 3%+（公司页面）/5%+（个人品牌）、每月受众覆盖增长 20%、50%+ 内容达到平台基准、社交广告 ROI 3 倍+。 +- Concepts created: [[Cross-Platform-Strategy]]（跨平台统一消息策略，根据各平台特性调整内容形式）、[[B2B-Social-Selling]]（B2B 社交销售策略与管道开发）、[[Employee-Advocacy]]（员工倡导计划设计与品牌大使激活）；[[Thought-Leadership]] 已在 Wiki 中存在，本次更新其 Source 引用 +- Entities created: 无（LinkedIn、Twitter 等作为 Agent 运营工具提及，不满足≥2次独立 Entity 门槛，均以 wikilink 保留于 Source Page） +- Source page: wiki/sources/marketing-social-media-strategist.md +- Notes: index.md 原占位条目（2026-04-21 expected）已替换为完整摘要；overview.md 新增 "Professional Social Media (LinkedIn & Twitter)" 区域（置于 Douyin Short-Video & Livestream Commerce 之前）；冲突检测：与 [[Marketing-Douyin-Strategist]] 和 [[Marketing-TikTok-Strategist]] 的平台差异已体现——后者专注短视频/直播电商，前者专注专业社交平台有机运营，策略目标和受众定位不同，无实质冲突。与 [[Paid-Media-Paid-Social-Strategist]] 互补关系已在 overview 中明确记录。 + +## [2026-04-26] ingest | Marketing Kuaishou Strategist +- Source file: Agent/agency-agents/marketing/marketing-kuaishou-strategist.md +- Status: ✅ 成功摄入 +- Summary: 快手平台下沉市场营销策略师 Agent——专注于低线城市短视频营销、直播带货运营与老铁经济社区信任构建。核心理念：真实性高于一切。核心方法：均衡分发算法（日常一致性优先于病毒爆发）+ 老铁关系构建（信任先于销售）+ 直播带货3-2-1公式（3痛点→2演示→1报价）+ 私域运营（粉丝团+微信私域）。核心禁忌：绝不将抖音内容直接复用到快手。 +- Concepts created: [[老铁经济]]（快手特有兄弟文化）、[[均衡分发算法]]（快手核心推荐机制）、[[下沉市场]]（低线城市用户群）、[[直播带货]]（快手核心商业模式）、[[3-2-1产品介绍公式]]（快手直播话术框架） +- Entities created: [[Kuaishou]]（快手平台 Entity，与抖音构成中国短视频双平台） +- Source page: wiki/sources/marketing-kuaishou-strategist.md +- Notes: index.md 原占位条目（2026-04-21 expected）已替换为完整摘要；overview.md Douyin Short-Video & Livestream Commerce 区域新增完整条目（置于 Instagram Curator 之后）；冲突检测：与 [[Marketing-Douyin-Strategist]] 的平台差异已于 Source Page Contradictions 节详细记录，overview.md Conflict Areas 第3条已有记录，无新冲突；Entity 层面：Kuaishou（快手）作为平台核心实体首次创建（≥5次出现），Douyin（抖音）Entity 由 Douyin Strategist Source Page 引用管理。 + +## [2026-04-26] ingest | Marketing Video Optimization Specialist +- Source file: Agent/agency-agents/marketing/marketing-video-optimization-specialist.md +- Status: ✅ 成功摄入 +- Summary: YouTube 视频增长与留存优化专家 Agent——专注于 YouTube 算法优化（CTR+留存率双驱动）、策略性章节划分、高转化率缩略图设计和跨平台内容分发。核心理念：前30秒（The Hook）决定视频生死，留存率图谱驱动视频结构优化，以频道会话视角而非单视频维度优化。成功指标：8%+ 平均 CTR、50%+ 第3分钟留存率、20%+ 平均观看时长提升。完整交付模板涵盖包装策略→视频结构→SEO 元数据的全链路。 +- Concepts created: [[Video-Hook]]（视频开场钩子，30秒框架，与 [[Golden-3-Second-Hook]] 的3秒抖音框架对应但时间尺度不同） +- Entities created: [[YouTube]]（YouTube 平台 Entity，算法机制与关键指标定义） +- Source page: wiki/sources/marketing-video-optimization-specialist.md +- Notes: overview.md Doubin Short-Video & Livestream Commerce 区域新增完整条目（置于 Douyin Strategist 与 Book Co-Author 之间）；index.md 已添加新条目；冲突检测：与 [[Golden-3-Second-Hook]] 存在"时间尺度差异"——前者30秒长格式框架，后者3秒短格式框架，非冲突而是互补，已在 [[Video-Hook]] Concept 中明确两者关系。 + +## [2026-04-26] ingest | Marketing Instagram Curator +- Source file: Agent/agency-agents/marketing/marketing-instagram-curator.md +- Status: ✅ 成功摄入 +- Summary: Instagram 营销专家 Agent 个性定义——通过视觉品牌开发、多格式内容策略、社区培养与社交电商将品牌打造成 Instagram 主力账号。核心四阶段工作流（品牌美学开发 → 多格式内容策略 → 社区建设与电商 → 绩效优化）；1/3 内容法则（品牌/教育/社区内容各占1/3）；绩效目标：互动率 3.5%+、Story 完成率 80%+、购物转化 2.5%+、UGC 月产 200+ 条。核心理念：将粉丝转化为品牌拥护者、将互动转化为可衡量的商业增长。 +- Concepts created: 无（Key Concepts 均仅出现1次，不满足≥2次独立创建阈值，以 wikilink 形式保留于 Source Page Key Concepts 节） +- Entities created: 无（Key Entities 均仅出现1次，不满足≥2次独立创建阈值，以 wikilink 形式保留于 Source Page Key Entities 节） +- Source page: wiki/sources/marketing-instagram-curator.md +- Notes: index.md 原占位条目（2026-04-21 expected）已替换为完整摘要；冲突检测：与 [[Marketing-TikTok-Strategist]] 在"平台特性差异"上的潜在张力已记录——Instagram 侧重视觉一致性与社区粘性，TikTok 侧重算法流量获取与趋势跟随，内容节奏与运营策略有本质差异。 + +## [2026-04-26] ingest | Marketing Short-Video Editing Coach +- Source file: Agent/agency-agents/marketing/marketing-short-video-editing-coach.md +- Status: ✅ 成功摄入 +- Summary: 短视频剪辑技术教练 Agent——覆盖完整后期制作流水线：剪辑软件选择决策树（CapCut Pro 主推高效日更/Pr 商业项目/DaVinci Resolve 调色行业标准/Final Cut Pro Mac首选）；镜头语言体系（景别/运镜/转场）；色彩调色二元体系（初级校正恢复真实 + 次级调色风格化）；音频工程三步骤（降噪→人声增强→BGM混音）；动态图形与VFX；字幕设计与多平台导出优化；AI辅助剪辑（自动字幕/智能抠像/文字成片/数字人配音）。核心理念：剪辑核心不是软件熟练度，而是叙事能力和节奏感；每一帧都必须有其存在的理由。 +- Concepts created: [[Color-Grading]]（色彩调色——二元体系：初级校正+次级调色）；[[Speed-Ramping]]（速度曲线变速——短视频最常用的动态视觉手法）；[[Beat-Sync]]（BGM节拍同步——音画合一冲击力）；[[Proxy-Editing]]（代理编辑——高分辨率工作流必备技术）；[[Template-Based-Production]]（模板化批量生产——效率4倍提升）；[[AI-Assisted-Editing]]（AI辅助剪辑——承担60%重复工作，保留40%人工创意） +- Entities created: [[CapCut-Pro]]（剪映专业版——AI功能业界领先，最适合个人创作者和MCN批量生产）；[[Adobe-Premiere-Pro]]（行业标准——广告/影视后期首选，与AE/AU/PS无缝集成）；[[DaVinci-Resolve]]（调色行业标准——免费版已极强，Fairlight音频+Fusion VFX）；[[Final-Cut-Pro]]（Mac首选——磁力时间线+M系列芯片极致优化，一次买断无订阅） +- Source page: wiki/sources/marketing-short-video-editing-coach.md +- Notes: index.md 原占位条目（2026-04-21 expected）已替换为完整摘要；overview.md Doubin Short-Video & Livestream Commerce 区域新增完整条目（置于 Kuaishou Strategist 之后）；冲突检测：与 [[Marketing-Douyin-Strategist]] 的时长策略差异（后者强调7-15秒完播率优先，本 Coach 建议1-3分钟叙事）已在 Source Page Contradictions 节详细记录——解决方向为两者互补（3秒快节奏开篇钩子 + 后续1-3分钟完整叙事）；与 [[Marketing-Video-Optimization-Specialist]] 的时间尺度差异（3-30秒 vs 3分钟+）已在 Contradictions 节记录——均为正确但适用于不同平台；Entity 层面：CapCut/Adobe Premiere/DaVinci Resolve/Final Cut Pro 作为核心工具实体首次创建（4个软件均满足≥5次出现阈值）；Concepts 层面：6个核心概念（Color Grading/Speed Ramping/Beat Sync/Proxy Editing/Template-Based Production/AI-Assisted Editing）均满足可抽象/可复用/非具体实例的创建条件。 +- Source file: Agent/agency-agents/marketing/marketing-china-ecommerce-operator.md +- Status: ✅ 成功摄入 +- Summary: The Agency 营销部门的中国电商多平台运营专家 Agent——跨淘宝/天猫/拼多多/京东/抖音店铺全渠道运营，核心方法：多平台差异化策略 + 直播带货运营 + T-60大战役框架（618/双11/双12）+ 广告ROAS优化（直通车≥3:1）+ 私域运营（微信CRM/会员体系/社群电商）。核心理念：每个平台算法、受众和规则不同，永远不能复制策略；利润保护优先于GMV；大促准备须提前45-60天。 +- Concepts created: 无（Key Concepts 均仅出现1次，不满足≥2次独立创建阈值，以 wikilink 形式保留于 Source Page Key Concepts 节） +- Entities created: 无（Key Entities 均仅出现1次，不满足≥2次独立创建阈值，以 wikilink 形式保留于 Source Page Key Entities 节） +- Source page: wiki/sources/marketing-china-ecommerce-operator.md +- Notes: index.md 原占位条目（2026-04-21 expected）已替换为完整摘要；overview.md Douyin Short-Video & Livestream Commerce 区域新增完整条目；冲突检测：与 [[Marketing-Douyin-Strategist]] 在"抖音平台视角"上的潜在张力已记录于 Source Page Contradictions 节，建议分工：前者负责抖音店铺整体运营（含广告/直播/数据分析），后者负责内容策略（短视频/达人合作），互补而非竞争。 + +## [2026-05-06] ingest | Marketing Reddit Community Builder +- Source file: Agent/agency-agents/marketing/marketing-reddit-community-builder.md +- Status: ✅ 成功摄入 +- Summary: AI Agent 角色定义——以 Reddit 文化专家身份，通过真实价值贡献和长期关系培养，在 Reddit 上建立品牌影响力。核心四阶段执行框架（社区研究 → 内容策略 → 社区建设 → 战略价值），核心规则 90/10 价值法则（90% 价值内容 + 10% 推广）。成功关键：成为社区有价值成员，而非推销品牌。 +- Concepts created: [[90-10-Rule]]（90%价值内容+10%推广比例法则）、[[Community-First-Engagement]]（关系优先策略）、[[Subreddit-Research]]（社区研究流程）、[[AMA-Coordination]]（Ask Me Anything 协调）、[[Reputation-Management]]（声誉管理）、[[Reddit-Advertising-Integration]]（Reddit广告整合） +- Source page: wiki/sources/marketing-reddit-community-builder.md +- Notes: index.md 原占位条目（2026-04-21 expected）已替换为完整摘要；冲突检测：与 [[Marketing-Short-Video-Editing-Coach]] 在"推广节奏"上的潜在张力已记录——Reddit 以月/年为周期积累型信任，短视频以周为周期爆发型传播；Entity 层面 Reddit/Subreddit 等均<2次提及，暂不创建独立 Entity 页面。 + +## [2026-05-05] ingest | Nexus Spatial: Full Agency Discovery Exercise +- Source file: Agent/agency-agents/examples/nexus-spatial-discovery.md +- Status: ✅ 成功摄入 +- Summary: 8个 The Agency 专业 Agent 并行协作，完成 AI 空间指挥中心产品 Nexus Spatial 的完整规划（10分钟 wall-clock time）。涵盖：市场验证（AI 编排 $13.5B + 空间计算 $170-220B 交叉空白）、技术架构（8服务 Rust 编排引擎）、品牌策略（定义 [[SpatialAIOps]] 新品类）、GTM 计划（3阶段渐进：2D→WebXR→VisionOS）、UX 研究（调试为杀手级用例）、空间界面架构（命令剧院 + 7态节点系统）、项目执行（35周，5团队）。跨 Agent 独立共识：2D-first / WebXR 优先 / 调试 killer use case。 +- Concepts created: [[SpatialAIOps]]（空间AI运营新品类）、[[Command-Theater-Interface]]（命令剧院界面范式）、[[Debugging-Visualization]]（调试可视化杀手级用例）、[[Semantic-Zoom]]（4级语义缩放导航）、[[Growth-Loop]]（增长飞轮） +- Entities created: [[Nexus-Spatial]]（AI Agent 沉浸式3D命令中心产品）、[[CrewAI]]（竞争产品；CLI-first，可视化能力有限） +- Source page: wiki/sources/nexus-spatial-discovery.md +- Notes: index.md 原占位条目（2026-04-21 expected）已替换为完整摘要；overview.md 已追加 nexus-spatial-discovery 综合摘要条目；与 [[Multi-Agent-System-Reliability]] 在协调机制设计上的张力已记录于 Source Page Contradictions 节——Nexus Spatial 采用 Yjs CRDT 去中心化协作（面向人类协作者），Multi-Agent-System-Reliability 侧重自主 Agent 间显式协调（面向任务协调），场景不同但技术选择有潜在关联待研究。 + +## [2026-05-05] ingest | Book Co-Author +- Source file: Agent/agency-agents/marketing/marketing-book-co-author.md +- Status: ✅ 成功摄入 +- Summary: AI 代笔专家 Agent——将创始人/专家/运营者的语音笔记和碎片想法转化为结构化第一人称书籍章节。核心五阶段工作流：Pressure-Test Brief → Define Chapter Intent → Draft in First-Person Voice → Strategic Revision Pass → Deliver Revision Package。版本化管理 + 编辑 Gap 可视化。核心理念：作者必须保持可见、禁止空洞套话、书籍必须强化品类定位而非仅解释想法。 +- Concepts created: 无新概念页（Ghostwriting/Narrative Architecture/First-Person Voice 等核心概念由 [[Thought-Leadership]] 覆盖） +- Source page: wiki/sources/marketing-book-co-author.md +- Notes: index.md 已在 Sources 节首位插入条目；overview.md 已插入「Douyin Short-Video」section 末尾；与 [[design-visual-storyteller]] 的潜在张力已记录于 Source Page Contradictions 节（视觉叙事 vs 文字叙事，互补而非竞争）；与 [[workflow-book-chapter]] 关系已说明（通用工作流 vs 专用 Agent）；与 [[marketing-zhihu-strategist]] 互补（短内容建立信誉 vs 长内容巩固权威）。 + +## [2026-05-05] ingest | Examples - Agency Multi-Agent Collaboration Showcase +- Source file: Agent/agency-agents/examples/README.md +- Status: ✅ 成功摄入 +- Summary: agency-agents 示例目录——展示多个专业 Agent 如何协作完成真实任务的案例文档。核心价值：8 个专业 Agent 并行运行，产出连贯且相互引用的完整计划，无需协调开销；具体案例 Nexus-Spatial-Discovery 涵盖市场验证、技术架构、品牌策略、GTM 计划等 8 个领域。 +- Concepts created: 无（Multi-Agent-Collaboration 和 Nexus-Spatial-Discovery 均依赖实际 Source Page 内容，不在本文档范围内创建独立 Concept） +- Entities created: 无（8 个参与 Agent 均已在 wiki 中有独立 Source Page；Nexus-Spatial-Discovery 已在 index.md 占位待实际案例文档摄入后完善） +- Source page: wiki/sources/readme.md +- Notes: index.md 原有 12 个过期 OpenCode Integration readme.md 占位条目，清理并替换为新条目；冲突检测：与 Multi-Agent-System-Reliability 在"是否需要显式协调机制"上的潜在冲突已记录于 Source Page Contradictions 节。 + +- Source file: Agent/agency-agents/support/support-infrastructure-maintainer.md +- Status: ✅ 成功摄入 +- Summary: Infrastructure Maintainer——The Agency Support 部门的基础设施维护专家 Agent，核心理念"Keeps the lights on, the servers humming, and the alerts quiet"，通过 Prometheus 监控/Terraform IaC/自动化灾备/安全合规实现运维自动化，确保 99.9%+ 服务可用性，降低 70%+ 人工运维任务，年度成本效率提升 20%+。与 Support Responder 和 Analytics Reporter 构成依赖链。 +- Concepts created: 无（Key Concepts 均为单来源特定概念/工具，不满足可独立复用阈值，均以 wikilink 形式记录于 Source Page Key Concepts 节） +- Entities created: 无（Terraform/Prometheus/AWS-RDS/HashiCorp 等 Key Entities 均已在其他来源中存在，无需重复创建，均以 wikilink 形式记录于 Source Page Key Entities 节） +- Source page: wiki/sources/support-infrastructure-maintainer.md +- Notes: index.md 原占位条目（2026-04-21 source missing）已替换为完整摘要；overview.md Support 部门新增 support-infrastructure-maintainer 段落，位于 support-analytics-reporter 之后、Paid Media 部门之前；冲突检测：与 support-legal-compliance-checker 在"变更速度 vs 合规验证"上的张力已记录于 Source Page Contradictions 节，建议合规验证作为 CI/CD 流水线 Gate，不阻断常规变更但强制阻断高风险变更。 + +## [2026-05-05] ingest | Support Responder Agent Personality +- Source file: Agent/agency-agents/support/support-support-responder.md +- Status: ✅ 成功摄入 +- Summary: Support Responder——The Agency Support 部门的客户支持专员 Agent，核心理念"客户满意度优先于内部效率指标"，通过多渠道（邮件/聊天/电话/社交媒体/应用内消息）提供全渠道支持，实现 85% 首次联系解决率和 2 小时首次响应 SLA。三级分层支持体系（Tier1 General/Tier2 Technical/Tier3 Specialists）通过明确升级标准和路由机制确保问题高效分流。配套 SupportAnalytics Python 框架（数据分析/趋势识别/改进建议/主动外展列表）和 KnowledgeBaseManager 知识库系统（文章创建/模板生成/交互式故障排除/内容优化）。成功指标：客户满意度 4.5+/5、首次联系解决率 80%+、SLA 合规率 95%+、知识库贡献减少相似工单 25%+。 +- Concepts created: 无（Omnichannel-Support/First-Contact-Resolution/Support-Tier-System 等 Key Concepts 均为单来源特定概念，不满足可独立复用阈值，均以 wikilink 形式记录于 Source Page Key Concepts 节） +- Entities created: 无（Support-Responder-Agent/Support-Analytics-Dashboard/Knowledge-Base-Manager 等 Key Entities 均为单来源工具/交付物名称，不满足 ≥2 次出现阈值，均以 wikilink 形式记录于 Source Page Key Entities 节） +- Source page: wiki/sources/support-support-responder.md +- Notes: index.md 原占位条目（2026-04-21 source missing）已替换为完整摘要；overview.md Support 部门新增 support-support-responder 完整条目（含 Agent 间协作关系：Support Responder 产生工单数据→ Analytics Reporter 分析洞察；合规问题升级至 Legal Compliance Checker）；冲突检测：与 support-legal-compliance-checker 在"问题解决优先 vs 合规优先"上的张力已记录于 Source Page Contradictions 节，建议分工：常规问题以 Support Responder 为主，涉及合规风险的问题升级至 Legal Compliance Checker。 + +## [2026-05-05] ingest | Analytics Reporter Agent Personality +- Source file: Agent/agency-agents/support/support-analytics-reporter.md +- Status: ✅ 成功摄入 +- Summary: Analytics Reporter——The Agency Support 部门的数据分析与商业智能专家 Agent，核心理念"用数据讲故事，用统计说话"，核心使命将原始数据转化为可操作业务洞察。四步工作流：数据发现验证 → 分析框架开发 → 洞察生成可视化 → 业务影响测量。技术栈覆盖 SQL（CTE 复杂业务指标）、Python（pandas/scikit-learn RFM 客户分层）、统计分析（p-value 显著性检验、回归、预测）。交付物模板：Executive Dashboard、Customer Segmentation Analysis（RFM 分层）、Marketing Attribution Dashboard（多触点归因 + ROI）。核心原则：数据质量优先（p < 0.05）、业务影响聚焦、可重现性保证。成功指标：分析准确率 95%+、建议实施率 70%+、满意度 4.5+/5。 +- Concepts created: [[RFM-Analysis]]（客户价值三维分层分析）、[[Marketing-Attribution]]（多触点营销归因模型） +- Entities created: 无（Key Entities 均为单来源工具/交付物名称，不满足 ≥2 次出现阈值） +- Source page: wiki/sources/support-analytics-reporter.md +- Notes: index.md 原占位条目（2026-04-21 source missing）已替换为完整摘要；overview.md Support 部门新增 support-analytics-reporter 完整条目（含 Agent 间协作关系：数据→洞察→传递完整链路）；冲突检测无发现（Source Page Contradictions 节标记为暂无冲突）；与 testing-test-results-analyzer 共享统计分析方法论但前者侧重 BI 业务分析，后者侧重 QA 测试数据。 + +## [2026-05-05] ingest | Support Legal Compliance Checker Agent Personality +- Source file: Agent/agency-agents/support/support-legal-compliance-checker.md +- Status: ✅ 成功摄入 +- Summary: Legal Compliance Checker——The Agency Support 部门的法律合规专家 Agent，核心理念"合规优先"，负责确保企业运营符合多司法管辖区法规（GDPR/CCPA/HIPAA/PCI-DSS/SOX/FERPA）。四阶段工作流：监管格局评估 → 风险评估与差距分析 → 政策制定与实施 → 培训与文化建设。提供 Python PrivacyPolicyGenerator（多辖区隐私政策生成）和 ContractReviewSystem（关键词扫描风险评估，≥10分高风险需法律审查）。目标合规评分 98%+，数据泄露 72 小时内通报监管机构。 +- Concepts created: 无（Key Concepts 均为单来源特定方法论，不满足可独立复用阈值） +- Entities created: 无（Key Entities 均为单一框架名称，不满足 ≥2 次创建阈值） +- Source page: wiki/sources/support-legal-compliance-checker.md +- Notes: index.md 原占位条目（2026-04-21 source missing）已替换为完整摘要；overview.md 新增 Support 部门段落（含 Legal Compliance Checker 完整条目）位于 Testing 部门和 Paid Media 部门之间；与 testing-reality-checker 在质量标准严格度上的张力已记录于 Source Page Contradictions 节（合规达标 = 合规 vs Reality Checker 要求压倒性视觉证明）。 + +## [2026-05-05] ingest | Accessibility Auditor Agent Personality +- Source file: Agent/agency-agents/testing/testing-accessibility-auditor.md +- Status: ✅ 成功摄入 +- Summary: AccessibilityAuditor——The Agency Testing 部门的无障碍审计专家 Agent，核心理念"If it's not tested with a screen reader, it's not accessible"，通过 WCAG 2.2 AA 标准 POUR 四原则评估和自动化+手动双重测试（axe-core/Lighthouse + VoiceOver/NVDA/JAWS + 键盘导航）发现约 70% 自动化工具无法检测的无障碍问题。强调语义化 HTML 优于 ARIA，自定义组件默认有罪需逐个审查。 +- Concepts created: 无（Key Concepts 均为单来源特定概念/工具，未达独立复用阈值） +- Entities created: 无（Key Entities 均为单来源工具，未达 ≥2 次创建阈值） +- Source page: wiki/sources/testing-accessibility-auditor.md +- Notes: index.md 原占位条目（2026-04-21 source missing）已替换为完整摘要；overview.md Testing 部门已新增 testing-accessibility-auditor 段落；无 Entity/Concept 页面创建需求（均不满足 ≥2 次出现阈值）；与 testing-tool-evaluator 在自动化工具充分性上的潜在冲突已记录于 Source Page Contradictions 节。 + +## [2026-05-05] ingest | Tool Evaluator Agent Personality +- Source file: Agent/agency-agents/testing/testing-tool-evaluator.md +- Status: ✅ 成功摄入 +- Summary: Tool Evaluator——The Agency Testing 部门的技术评估与战略工具采纳专家，专注于 ROI 导向的工具分析、竞争对比和战略技术采纳建议。核心理念：量化一切可量化的，成本-功能-风险三维权衡。核心能力：7维加权评分体系（功能25%/可用性20%/性能15%/安全15%/集成10%/支持8%/成本7%）、4阶段工作流（需求收集→全面测试→财务风险分析→实施规划）、TCO/ROI 量化计算框架。Python 框架：pandas + numpy + requests + dataclass 评分模型。成功指标：90%+ 推荐准确性，85%+ 6个月采用率，20%+ 成本优化，25%+ ROI。 +- Concepts created: TotalCostOfOwnership, ReturnOnInvestment, ServiceLevelAgreement, UserAcceptanceTesting, ChangeManagement, WeightedScoringModel +- Entities created: 无（Tool Evaluator Agent 为单来源，不满足 ≥2 次创建阈值） +- Source page: wiki/sources/testing-tool-evaluator.md +- Notes: 无内容冲突。index.md 原占位条目已替换为完整摘要；overview.md Testing 部门已有 testing-evidence-collector / testing-test-results-analyzer / testing-performance-benchmarker / testing-reality-checker / testing-workflow-optimizer / testing-api-tester 覆盖，testing-tool-evaluator 补充了战略评估维度，与 testing-reality-checker 互补（量化评分 vs 现实核查）。与 testing-evidence-collector / testing-test-results-analyzer / testing-performance-benchmarker 的协同关系已在 Source Page Connections 节记录。 + +## [2026-05-05] ingest | Test Results Analyzer Agent Personality +- Source file: Agent/agency-agents/testing/testing-test-results-analyzer.md +- Status: ✅ 成功摄入 +- Summary: Test Results Analyzer——The Agency Testing 部门的测试结果分析与质量情报专家 Agent，通过统计分析方法、机器学习预测模型和可视化报告将原始测试数据转化为战略决策依据。核心理念：数据驱动的质量决策，所有结论必须通过统计方法验证。核心能力：测试覆盖率分析、失败模式统计分类、基于 RandomForest 的缺陷易发性预测、发布就绪多维度评估、质量投资 ROI 分析。Python 框架：pandas + numpy + scipy.stats + sklearn RandomForestClassifier + matplotlib/seaborn。成功指标：质量风险预测准确率 95%+、24 小时内报告交付、干系人满意度 4.5/5。 +- Concepts created: 无（Key Concepts 均为单来源特定方法论，不满足可独立复用阈值） +- Entities created: 无（Key Entities 均为单来源技术栈，不满足 ≥2 次创建阈值） +- Source page: wiki/sources/testing-test-results-analyzer.md +- Notes: 无内容冲突。index.md 已添加条目；overview.md Testing 部门新增 testing-test-results-analyzer 段落。与 testing-performance-benchmarker 的协同关系已在 Source Page 和 overview.md 中记录（Performance Benchmarker 提供性能维度数据，Test Results Analyzer 提供整体质量情报视图）。 + +## [2026-05-05] ingest | Testing Evidence Collector Agent Personality +- Source file: Agent/agency-agents/testing/testing-evidence-collector.md +- Status: ✅ 成功摄入 +- Summary: EvidenceQA——The Agency Testing 部门的截图驱动型 QA Agent，核心理念"截图不会撒谎"，以 Playwright 自动化截图作为唯一可靠的质量评估依据。强制默认发现 3-5+ 问题，"零问题"报告为红色警报。质量评级默认 FAILED，不接受无视觉证据支撑的声称。提供标准化 QA 报告模板（Reality Check Results / Visual Evidence Analysis / Interactive Testing Results / Issues Found / Honest Quality Assessment）。 +- Concepts created: 无（Key Concepts 均为单来源特定方法论，不满足可独立复用阈值） +- Entities created: 无（Key Entities 均为单来源 Agent，不满足 ≥2 次创建阈值） +- Source page: wiki/sources/testing-evidence-collector.md +- Notes: 无内容冲突。index.md 已添加条目；overview.md Testing 部门已有相关 Testing Agent 覆盖，无需额外修订。与声称"零问题"报告的冲突已在 Source Page Contradictions 节记录。与 testing-reality-checker / testing-test-results-analyzer / testing-performance-benchmarker 的协同关系已在 Source Page Connections 节记录。 + +## [2026-05-05] ingest | Performance Benchmarker Agent Personality +- Source file: Agent/agency-agents/testing/testing-performance-benchmarker.md +- Status: ✅ 成功摄入 +- Summary: Performance Benchmarker——The Agency Testing 部门的性能测试与优化专家 Agent，通过系统性性能测试确保系统以 95% 置信度满足 SLA 要求。核心理念：量化一切可量化的，用数据证明优化价值。核心能力：负载/压力/耐力/可扩展性测试，Core Web Vitals 优化（LCP < 2.5s / FID < 100ms / CLS < 0.1），k6 性能测试框架，统计置信区间分析，容量规划与成本-性能权衡。成功指标：95% 系统持续满足性能 SLA，Core Web Vitals 达到"良好"评级（90th percentile），关键用户体验指标改善 25%，支持 10x 当前负载。 +- Concepts created: 无（所有 Key Concepts 均为单来源特定概念，不满足独立复用阈值） +- Entities created: 无（所有 Key Entities 均为单来源 Agent，不满足 ≥2 次创建阈值） +- Source page: wiki/sources/testing-performance-benchmarker.md +- Notes: 无内容冲突。index.md 原占位条目已替换为完整摘要；overview.md Testing 部门已新增 testing-performance-benchmarker 段落。与 testing-reality-checker 的互补张力（指标量化 vs 用户感受）已在 Source Page Contradictions 节记录。 + +## [2026-05-05] ingest | Testing Reality Checker Agent Personality +- Source file: Agent/agency-agents/testing/testing-reality-checker.md +- Status: ✅ 成功摄入 +- Summary: Testing Reality Checker——The Agency Testing 部门的最后一道防线 Agent，通过自动化截图证据截断"幻想型认证"，要求压倒性视觉证明才授予生产就绪状态。默认"NEEDS WORK"，强制三步验证流程（Reality Check 命令 → QA 交叉验证 → 端到端截图分析）。C+/B- 评级属正常；第一次实现通常需要 2-3 轮修订。 +- Concepts created: 无（所有 Key Concepts 均为单来源特定概念，不满足独立复用阈值） +- Entities created: 无（所有 Key Entities 均为单来源 Agent，不满足 ≥2 次创建阈值） +- Source page: wiki/sources/testing-reality-checker.md +- Notes: 无内容冲突。index.md 原占位条目已替换为完整摘要；overview.md Testing 部门已新增 testing-reality-checker 段落。与 testing-workflow-optimizer 的潜在张力（效率 vs 真实性）和与 testing-api-tester 的互补关系（截图 vs 接口）已在 Source Page Contradictions 节记录。 + +## [2026-05-05] ingest | Workflow Optimizer Agent Personality +- Source file: Agent/agency-agents/testing/testing-workflow-optimizer.md +- Status: ✅ 成功摄入 +- Summary: Workflow Optimizer——The Agency Testing 部门的流程优化与工作流自动化专家 Agent，基于系统思维方法论分析、优化和自动化跨业务功能的工作流。核心理念：找到瓶颈，修复流程，其余自动化。四阶段工作流（现状分析→优化设计→实施规划→自动化执行），融合 Lean/Six Sigma/Kaizen/统计过程控制/变更管理/人本设计六大方法论体系。核心交付物：WorkflowOptimizer Python 框架。成功指标：40% 周期时间改善、60% 常规任务自动化率、75% 流程错误减少、90% 优化流程 6 个月内成功采纳、30% 员工满意度提升。 +- Concepts created: [[Lean]], [[Six-Sigma]], [[Kaizen]], [[Value-Stream-Mapping]], [[Statistical-Process-Control]], [[Human-Centered-Design]], [[Design-Thinking]]（共 7 个，其中 Change-Management 已存在） +- Entities created: 无（The Agency 已在 entities/ 中存在；各工具仅出现 1 次，不满足 ≥2 次创建阈值） +- Source page: wiki/sources/testing-workflow-optimizer.md +- Notes: 无内容冲突。index.md 原占位条目已替换为完整摘要；overview.md Testing 部门已新增 testing-workflow-optimizer 段落；7 个新 Concept 页面已创建并添加到 index.md。与 specialized-workflow-architect（设计与执行的分层关系）和 product-behavioral-nudge-engine（自动化 vs 人机交互互补张力）已在 Source Page Contradictions 节记录。 + +## [2026-05-05] ingest | API Tester Agent Personality +- Source file: Agent/agency-agents/testing/testing-api-tester.md +- Status: ✅ 成功摄入 +- Summary: API Tester Agent——The Agency Testing 部门的 API 测试专家智能体人格定义，涵盖功能、性能、安全三大维度的全面 API 质量保障方法论与自动化实现框架。核心理念"Breaks your API before your users do"，通过 Playwright/REST Assured/k6 框架实现 95%+ API 端点覆盖率，CI/CD 流水线集成，性能 SLA（95p < 200ms、10x 负载、< 0.1% 错误率），OWASP API Security Top 10 安全验证。 +- Concepts created: 无（API Testing、Performance Testing、Security Testing、Contract Testing、CI/CD Integration、OWASP API Security Top 10 等概念均已在本文档出现，未达独立创建阈值） +- Entities created: 无（Playwright、REST Assured、k6、perf_hooks 等工具均仅在本文档出现，未达创建阈值） +- Source page: wiki/sources/testing-api-tester.md +- Notes: 无内容冲突。index.md 和 overview.md 已更新。新增 Testing 部门 section 到 overview.md。 +- Source file: Agent/agency-agents/integrations/opencode/README.md +- Status: ✅ 成功摄入 +- Summary: OpenCode Integration——The Agency Agent roster 与 OpenCode 编辑器的子 Agent 集成方案，通过 `./scripts/install.sh --tool opencode` 安装，将 .md 格式 Agent 转换为 OpenCode 的 `.opencode/agents/` 格式。核心机制：`mode: subagent` 使 Agent 仅在 `@agent-name` 触发时出现，不在 Tab 循环中占位；命名颜色自动映射为十六进制颜色代码。支持项目级和全局级两种安装范围。与 [[readme|Cursor Integration]]（.mdc）、[[github-copilot|GitHub Copilot Integration]]、[[windsurf-integration|Windsurf Integration]] 同属 The Agency 多 IDE 集成生态。 +- Concepts created: 无（Subagent、OpenCode 仅在本文档出现1次，未达创建阈值） +- Entities updated: 无（[[The Agency]] 已在其他来源中覆盖，无需新建 OpenCode entity） +- Source page: wiki/sources/readme.md +- Notes: 无内容冲突。index.md 和 overview.md 已更新。 + +## [2026-05-04] ingest | Kimi Code CLI Integration +- Source file: Agent/agency-agents/integrations/kimi/README.md +- Status: ✅ 成功摄入 +- Summary: Kimi Code CLI Integration——将 Agency agents 项目转换为 Kimi Code CLI 可用的 agent specification，通过 `convert.sh` 和 `install.sh` 脚本生成 `agent.yaml` + `system.md` 目录结构，安装到 `~/.config/kimi/agents/`。使用 `--agent-file` 标志激活，支持 `extend: default` 继承 Kimi 内置工具集。与 [[readme|Cursor Integration]] 和 [[github-copilot|GitHub Copilot Integration]] 同属 The Agency 多 IDE/CLI 集成生态。 +- Concepts created: 无（YAML配置文件、Agent规范、SystemPrompt 均仅在本文档出现1次，未达创建阈值） +- Entities created: 无（Kimi Code CLI、Moonshot AI 均仅在本文档出现1次，未达创建阈值） +- Source page: wiki/sources/kimi.md +- Notes: 无内容冲突。index.md 和 overview.md 已更新。 + +## [2026-05-04] ingest | Antigravity Integration +- Source file: Agent/agency-agents/integrations/antigravity/README.md +- Status: ✅ 成功摄入 +- Summary: Antigravity Integration——The Agency Agent roster 与 Antigravity/Gemini 的集成方案，通过 `./scripts/install.sh --tool antigravity` 将全部 Agent roster 转换为 Antigravity SKILL.md 文件，复制到 `~/.gemini/antigravity/skills/`。所有 skill slug 统一使用 `agency-` 前缀避免命名冲突。用户可通过自然语言激活对应 agent。与 [[Cursor Integration]]（.mdc 规则）、[[Windsurf Integration]]（.windsurfrules）、[[GitHub Copilot Integration]]（原生兼容）共同构成 The Agency 的完整多平台集成生态。 +- Concepts updated: 无需更新（SKILL.md Format、Antigravity Skills、Skill Prefix Convention 等概念已在其他来源中覆盖） +- Entities created: 无（Antigravity/Gemini、Agency Agents 均已在其他来源中出现，无需新建） +- Source page: wiki/sources/antigravity-integration.md +- Notes: 无内容冲突。index.md 和 overview.md 已更新。与 [[Cursor Integration]] 在"多 IDE 集成覆盖"定位上存在功能重叠，已在 Contradictions 节标注区分（前者 GUI 编辑器生态，后者 Gemini 生态）。 + +## [2026-05-03] ingest | Windsurf Integration +- Source file: Agent/agency-agents/integrations/windsurf/README.md +- Status: ✅ 成功摄入 +- Summary: Windsurf Integration——The Agency Agent roster 与 Windsurf 编辑器的集成方案，通过 `.windsurfrules` 文件将 Agent roster 聚合为单一规则文件，install.sh 从项目根目录安装，项目级生效。在 prompt 中按名称引用 Agent 即可激活。与 [[Cursor Integration]]（.mdc）和 [[Aider Integration]]（CONVENTIONS.md）同为项目级 IDE 集成，共同构成 The Agency 的多 IDE 覆盖体系。 +- Concepts updated: [[Agent-Activation-Pattern]]（补充 Windsurf 应用场景）、[[Project-Scoped-Tools]]（替代 Project-Scoped-Integration，与 integrations-readme.md 保持一致） +- Entities created: [[Windsurf]]（Windsurf.md，Codeium 开发的 AI 代码编辑器，跨 3 个 source 页面出现） +- Source page: wiki/sources/windsurf-integration.md +- Notes: 无内容冲突。index.md 和 overview.md 已更新。slug 避免与同名 readme.md 冲突（已有多条同名占位条目），采用 windsurf-integration.md。 + +## [2026-04-26] ingest | Gemini CLI Integration +- Source file: Agent/agency-agents/integrations/gemini-cli/README.md +- Status: ✅ 成功摄入 +- Summary: Gemini CLI Integration——将 61 个 Agency Agents 打包为 Gemini CLI 扩展插件，安装到 `~/.gemini/extensions/agency-agents/`，安装后可在 Gemini CLI 中通过自然语言按名称激活 Agent skill（如 `frontend-developer`）。 +- Entities created: 无（Agency Agents 已在其他来源中出现，无需新建；Agent Skill 和 Extension 机制未达到 ≥2 次出现阈值） +- Concepts created: 无 +- Source page: wiki/sources/gemini-cli.md +- Notes: 无内容冲突。 + +## [2026-05-03] ingest | Cursor Integration +- Source file: Agent/agency-agents/integrations/cursor/README.md +- Status: ✅ 成功摄入 +- Summary: Cursor Integration——将 Agency roster 中的 agent 转换为 Cursor `.mdc` 规则文件，安装到项目根目录的 `.cursor/rules/` 下，**项目级别生效**。支持 `@agent-slug` 引用特定 agent，或通过 `alwaysApply: true` 设为常驻规则。与 Aider Integration 形成 IDE 集成互补。 +- Entities created: 无（Agency Agents 和 Cursor 未达到 ≥2 次出现阈值） +- Concepts created: 无（Cursor.mdc Rules/Agency Roster/Project-Scoped Rules 仅出现 1 次，不满足 ≥2 次阈值，均以 wikilink 形式记录于 Source page） +- Source page: wiki/sources/readme.md +- Notes: 无内容冲突。overview.md 已新增 Cursor Integration 段落于 The Agency 贡献指南段落后。与 [[Aider Integration]] 存在功能重叠（两个工具都将 Agency agents 集成到不同 IDE），已在 Source page Contradictions 节记录。 + +## [2026-05-03] ingest | OpenClaw Integration +- Source file: Agent/agency-agents/integrations/openclaw/README.md +- Status: ✅ 成功摄入 +- Summary: The Agency Agent 与 OpenClaw 多智能体框架的集成方案——通过 convert.sh 将 Agent 转换为 OpenClaw workspace（含 SOUL.md/AGENTS.md/IDENTITY.md），install.sh 复制到 ~/.openclaw/agency-agents/，openclaw gateway restart 使 Agent 通过 agentId 可用。slug 采用 openclaw-integration.md 以避免与同名 Aider Integration 的 readme.md 冲突。 +- Entities created: 无（OpenClaw/The-Agency/OpenClaw-Gateway 在 overview.md 已出现多次，不满足新建阈值） +- Concepts created: 无（OpenClaw-Workspace/Workspace-Based-Agent/Agent-Conversion 仅在源页面内出现 1 次，不满足 ≥2 次阈值，均以 wikilink 形式记录于 Source page） +- Source page: wiki/sources/openclaw-integration.md +- Notes: 无内容冲突。overview.md 已有 OpenClaw 相关内容，无需修订。integrations-readme.md 已有 OpenClaw wikilink，无需重复创建 Entity 页面。 + +## [2026-05-02] ingest | MCP Memory Integration +- Source file: Agent/agency-agents/integrations/mcp-memory/README.md +- Status: ✅ 成功摄入 +- Summary: MCP Memory Integration——通过在 Agent 提示词中加入标准化的 Memory Integration 段落，为 The Agency 中任意 Agent 添加跨会话持久记忆能力。MCP Memory Server 提供 remember/recall/rollback/search 四个核心工具。Rollback 是杀手级功能：QA 失败或架构决策出错时恢复到已知良好状态，无需手动 undo。无代码修改，仅需在 prompt 中加入标准化指令段。 +- Entities created: 无（The-Agency 已存在于 entities/，Backend-Architect/Startup-MVP-Workflow 仅出现 1 次，均不满足 ≥2 次阈值） +- Concepts created: 无（Cross-Session-Memory/Handoff-Continuity/Rollback/Memory-Integration-Pattern/MCP-Memory-Tools/Checkpoint 均仅出现 1 次，均不满足 ≥2 次阈值，均以 wikilink 形式记录于 Source page） +- Source page: wiki/sources/mcp-memory-integration.md +- Notes: 无内容冲突。index.md 和 overview.md 已更新（新增 MCP Memory Integration 段落于 The Agency 段落后）。 + +## [2026-05-02] ingest | Claude Code Integration +- Source file: Agent/agency-agents/integrations/claude-code/README.md +- Status: ✅ 成功摄入 +- Summary: The Agency Agent 资产与 Claude Code 的原生集成方案。The Agency 从一开始就为 Claude Code 构建，无需任何格式转换，Agent 天然使用 `.md` + YAML frontmatter 格式。通过 install.sh 或手动复制将 Agent 部署到 `~/.claude/agents/`，在 Claude Code 会话中通过名称引用即可激活对应 Agent。 +- Entities created: 无（Claude Code/The Agency 均仅出现 1 次，不满足 ≥2 次阈值，以 wikilink 形式记录于 Source page） +- Concepts created: 无（Agent-Activation-Pattern 仅出现 1 次，不满足 ≥2 次阈值） +- Source page: wiki/sources/claude-code-integration.md +- Notes: 无内容冲突。slug 冲突解决：原 Aider Integration 已占用 `readme.md`，Claude Code README 同名，故采用 `claude-code-integration.md`。overview.md 无需修订（内容属配置说明，集成概述由 integrations-readme.md 覆盖）。 + +## [2026-05-02] ingest | Aider Integration +- Source file: Agent/agency-agents/integrations/aider/README.md +- Status: ✅ 成功摄入 +- Summary: Aider 编辑器集成 The Agency Agent 资产的安装与使用指南。核心机制：通过 install.sh 将 Agent 配置转换为 Aider 可读的 CONVENTIONS.md 文件，Aider 自动读取并激活 Agent 角色。 +- Entities created: 无（Aider 仅出现 2 次，未达到 ≥2 次阈值，以 wikilink 形式记录于 Source page） +- Concepts created: 无（CONVENTIONS.md/Project-Scoped-Integration 仅出现 1 次，不满足 ≥2 次阈值） +- Source page: wiki/sources/readme.md +- Notes: 无内容冲突。index.md 占位条目已替换为完整条目。overview.md 无需修订（The Agency 集成生态已有 integrations-readme.md 覆盖）。integrations-readme.md 已有 Aider wikilink，无需重复创建 Entity 页面。 + +## [2026-05-02] ingest | The Agency Integrations README +- Status: ✅ 成功摄入 +- Summary: The Agency 多智能体编码系统与 11 种主流 Agentic Coding 工具的集成指南。覆盖 Claude Code（原生）、GitHub Copilot（原生）、Antigravity、Gemini CLI（需 convert）、OpenCode（项目级）、OpenClaw（需 convert）、Cursor（项目级）、Aider（项目级）、Windsurf（项目级）、Kimi Code（需 convert）、Qwen Code（需 convert）。统一通过 install.sh 和 convert.sh 脚本实现跨平台部署。 +- Entities created: 无（各工具实体均仅出现 1 次，不满足 ≥2 次创建阈值） +- Concepts created: 无（Project-Scoped-Tools/Global-Scoped-Tools 仅出现 1 次） +- Source page: wiki/sources/integrations-readme.md +- Notes: 无内容冲突。index.md 和 log.md 已更新，overview.md 无需修订（已含 The Agency 段落）。 + +## [2026-05-02] ingest | Academic Geographer +- Source file: Agent/agency-agents/academic/academic-geographer.md +- Status: ✅ 成功摄入 +- Summary: Academic Geographer——AI Agent 中的地理学家角色，专注于物理与人文地理的系统性建模，为虚拟世界构建地理连贯性。核心理念："Geography is destiny — where you are determines who you become"。通过严格地理连贯性规则（河流不分叉、气候成系统、地理非装饰）、五步工作流（板块构造→气候→水文→生物群落→人类定居）、交付物模板驱动 Agent 行为。理论基础涵盖 Koppen 气候分类、Christaller 中心地理论、Mackinder 心脏地带理论、雨影效应等。 +- Entities created: [[Jared-Diamond]], [[Acemoglu]], [[Mackinder]] +- Concepts created: [[Geographic-Coherence]], [[Environmental-Determinism]], [[Mackinder-Heartland-Theory]] +- Source page: wiki/sources/academic-geographer.md +- Notes: 与 [[academic-historian]]（历时性时间维度）、[[academic-anthropologist]]（共时性文化系统）、[[academic-narratologist]]（叙事维度）共同构成"人文社科 AI 研究者矩阵"，已在 overview.md 添加独立段落。Entity/Concept 页面已创建。无已知内容冲突。 + +## [2026-05-02] ingest | Academic Narratologist +- Source file: Agent/agency-agents/academic/academic-narratologist.md +- Status: ✅ 成功摄入 +- Summary: Narratologist Agent——以叙事理论框架驱动故事结构分析的学术型 AI Agent。将俄罗斯形式主义、法国结构主义、认知叙事学等学术传统注入 Agent，使其能像专业叙事理论家一样分析故事结构、角色弧光、主题表达，并提供有命名框架依据的叙事建议。核心理念："每个故事都是一个论证"；核心原则：大多数叙事问题存在于讲述层面（sjuzhet）而非故事层面（fabula），诊断应优先于处方；每个建议必须引用至少一个命名理论框架。 +- Concepts created: [[Fabula-Sjuzhet]], [[Propp-Morphology]], [[Character-Arc]], [[Narrative-Debt]] +- Source page: wiki/sources/academic-narratologist.md +- Notes: 与 [[academic-anthropologist]]（共时性文化系统）、[[academic-historian]]（历时性时间分析）、[[academic-geographer]]（空间维度）共同构成"人文社科 AI 研究者矩阵"，已在 overview.md 添加独立段落。Entity 方面，Academic Anthropologist 条目曾标注 academic-narratologist 为 source missing，现已补全。该文档为 Agent 角色设定，无外部内容冲突。 + +- Source file: Agent/agency-agents/academic/academic-anthropologist.md +- Status: ✅ 成功摄入 +- Summary: Academic Anthropologist——基于文化人类学理论构建文化自洽社会的 AI Agent 设计框架。将田野调查方法论注入 Agent，使其能设计有社会学意义的亲属制度、交换系统、仪式信仰和权力结构。核心理念：每个文化元素必须有社会功能，先问"这个实践解决了什么问题"而非"这个仪式看起来酷不酷"。理论基础：结构人类学（列维-斯特劳斯）、象征人类学（格尔茨"厚描"）、实践理论（布迪厄）、仪式分析（特纳/范热内普）、经济人类学（莫斯/波拉尼）。关键原则：避免文化拼贴（culture salad）、不跳过亲属制度设计、无乌托邦（每个文化都有内部张力）。 +- Concepts created: [[Thick-Description]], [[Liminality]], [[Gift-Economy]], [[Cultural-Coherence]], [[Rites-of-Passage]] +- Entities identified (not yet created): [[Claude-Lévi-Strauss.md]], [[Clifford-Geertz.md]], [[Pierre-Bourdieu.md]], [[Victor-Turner.md]], [[Arnold-van-Gennep.md]], [[Marcel-Mauss.md]], [[Mary-Douglas.md]], [[Émile-Durkheim.md]], [[Bronislaw-Malinowski.md]], [[Karl-Polanyi.md]], [[Marvin-Harris.md]] +- Source page: wiki/sources/academic-anthropologist.md +- Notes: 与 [[academic-historian]]（历时性视角）、[[academic-geographer]]（空间维度）、[[academic-narratologist]]（叙事维度）共同构成"人文社科 AI 研究者矩阵"。Entity/Concept 页面已识别但未实际创建，可作为后续补充。无已知内容冲突。 + +## [2026-04-26] ingest | Academic Psychologist +- Source file: Agent/agency-agents/academic/academic-psychologist.md +- Status: ✅ 成功摄入 +- Summary: Academic Psychologist——The Agency 学术部门的临床与研究心理学家人格智能体，为角色塑造提供心理学可信度支撑。基于 Big Five、依恋理论、Vaillant 防御机制层级、Karpman 戏剧三角、CBT 认知扭曲、社会心理学经典实验等多种理论与实证框架，对角色进行多维度心理画像。核心原则：拒绝将角色病理化，区分流行心理学与循证心理学，承认文化情境与创伤响应的多样性。 +- Concepts created: [[Big-Five-Personality]], [[Attachment-Theory]], [[Defense-Mechanisms]], [[Cognitive-Distortions]], [[Karpman-Drama-Triangle]], [[Transactional-Analysis]], [[Trauma-Informed-Analysis]] +- Source page: wiki/sources/academic-psychologist.md + +## [2026-04-25] ingest | Historian Agent Personality +- Source file: Agent/agency-agents/academic/academic-historian.md +- Status: ✅ 成功摄入 +- Summary: Historian Agent——AI Agent 角色设定，扮演具有跨时代研究能力的历史学家，为创意项目提供历史真实性验证、时代背景丰富化和历史迷思纠正。核心理念：物质条件决定论（先理解经济基础再谈政治军事）、主动挑战欧洲中心主义、每条论断必须标注置信度和来源类型。方法论：Annales 学派、长时段分析（longue durée）、微观史、比较史、反事实推理、史料批判。五步工作流：定位时空坐标→核查物质基础→叠加社会结构→评估论断→标注置信度。典型交付物：Period Authenticity Report、Historical Coherence Check。 +- Concepts created: [[Annales-School]], [[Longue-Duree]] +- Source page: wiki/sources/academic-historian.md +- Notes: 与 [[academic-geographer]]（空间维度）、[[academic-anthropologist]]（共时性文化系统）、[[academic-narratologist]]（叙事维度）共同构成"人文社科 AI 研究者矩阵"。无已知内容冲突——主要纠正通俗历史迷思而非与已有 Wiki 内容矛盾。 +- Notes: index.md 中原有 "source missing" 占位条目（2026-04-20）已替换为完整条目。Academic 部门未在 overview.md 单独设节，相关心理框架已融入 Wiki 的 Agent 心理学知识体系。7 个 Concept 页面已创建并添加到 index.md。所有 Key Entities（Erikson/Piaget/Bowlby/Aaron Beck/Karpman/Vaillant/Milgram/Zimbardo/Herman/van der Kolk/Porges/Eysenck/Lazarus）均仅出现 1 次，不足 Entity 建页阈值（≥2 次），以 wikilink 形式记录于 Source page。与 [[multi-agent-system-reliability]] 在"确定性 vs 概率性"上的张力已记录于 Contradictions 部分。 + +## [2026-04-26] ingest | Behavioral Nudge Engine +- Source file: Agent/agency-agents/product/product-behavioral-nudge-engine.md +- Status: ✅ 成功摄入 +- Summary: Behavioral Nudge Engine——基于行为心理学原理的智能用户推动引擎，通过个性化交互节奏和激励策略最大化软件用户完成任务的可能性。核心四阶段工作流：偏好发现→任务拆解→精准推送→即时庆祝。支持 SMS/Email/应用内横幅等多渠道触达，利用默认偏差、微任务冲刺（5分钟）和游戏化机制持续驱动用户行为。有效降低认知负荷、提升任务完成率、减少平台流失。 +- Entities created: [[BehavioralNudgeEngine.md]] +- Concepts created: [[Behavioral-Psychology.md]], [[Cognitive-Load-Reduction.md]], [[Default-Bias.md]], [[Gamification.md]], [[Momentum-Nudge.md]], [[Pomodoro-Technique.md]] +- Source page: wiki/sources/product-behavioral-nudge-engine.md +- Notes: index.md Sources 节更新原 expected 条目为正式标题；Entities 新增 Behavioral Nudge Engine 条目；Concepts 新增 5 个行为心理学相关概念页面；无已知内容冲突。 + +## [2026-04-26] ingest | Product Sprint Prioritizer Agent +- Source file: Agent/agency-agents/product/product-sprint-prioritizer.md +- Status: ✅ 成功摄入 +- Summary: Product Sprint Prioritizer——The Agency 产品部门的冲刺规划与优先级排序专家 Agent，专注于敏捷冲刺规划、特性优先级排序和资源分配，通过数据驱动的优先级框架（RICE/MoSCoW/Kano/Value vs. Effort）最大化团队交付价值。核心方法：6 冲刺滚动平均团队速率预测（偏差 < 15%）；冲刺前五步准备（Backlog Refinement → 依赖分析 → 容量评估 → 风险识别 → 干系人审查）；技术债务与新功能 ROI 平衡建模；风险评分（概率 × 影响矩阵）定期重新评估。成功指标：承诺故事点交付率 90%+、干系人满意度 4.5/5、时间线偏差 ±10%、技术债务占比 < 20%。 +- Entities created: 无（TheAgency 已存在；ProductManagerAgent 仅在连接关系中出现，通过 Source Page Key Entities 保留） +- Concepts created: [[SprintPlanning.md]]（Sprint Planning 在 7 个页面中被提及，满足独立创建条件） +- Source page: wiki/sources/product-sprint-prioritizer.md +- Notes: index.md Sources 节新增条目置于最前；overview.md Product 部门新增 [[product-sprint-prioritizer]] 条目置于 [[product-manager]] 之后；与 [[product-feedback-synthesizer]] 存在潜在张力（短期迭代优先级 vs 长期用户价值路线图），已在双方 Source Page Contradictions 节记录，建议分工：Sprint Planning 层面优先 Sprint Prioritizer，产品路线图层面优先 Feedback Synthesizer。 + +## [2026-04-26] ingest | Product Trend Researcher Agent +- Source file: Agent/agency-agents/product/product-trend-researcher.md +- Status: ✅ 成功摄入 +- Summary: Product Trend Researcher——The Agency Product 部门的专家级市场情报分析师，专注于新兴趋势识别、竞争分析和机会评估。核心方法：七步趋势识别流程（信号收集→模式识别→上下文分析→影响评估→验证→预测→可操作性）；50+ 数据源实时聚合，统计验证弱信号检测，提前 3-6 个月识别主流采纳前趋势；TAM/SAM/SOM 三层市场量化；竞争情报框架（直接/间接/新兴/技术/替代）。成功指标：80%+ 准确率 6 个月趋势预测、90% 洞察转化战略决策、48h 紧急响应、15+ 验证来源。 +- Entities created: 无（TheAgency 已存在；ProductManagerAgent/AgentsOrchestrator 仅出现 1-2 次，通过 Source Page Key Entities 保留） +- Concepts created: 无（TrendLifecycleMapping/AdoptionCurveAnalysis/TAM-SAM-SOM/CompetitiveIntelligence/WeakSignalDetection/TechnologyScouting/SocialListening 均为标准领域抽象，各仅出现 1 次，待后续批次独立创建；已在 Source Page Key Concepts 节以 [[wikilink]] 格式标注） +- Source page: wiki/sources/product-trend-researcher.md +- Notes: index.md Sources 节新增条目置于最前；overview.md Product 部门新增 [[product-trend-researcher]] 条目置于 [[product-manager]] 之前；与 [[Agents-Orchestrator]] 存在潜在张力（Trend Researcher 需要时间积累弱信号 vs Orchestrator 要求阶段质量门强制推进），已记录于 Source Page Contradictions 节。 +- Source file: Agent/agency-agents/product/product-manager.md +- Status: ✅ 成功摄入 +- Summary: Product Manager Agent (Alex)——The Agency 产品部门的核心战略 Agent，10+ 年 B2B SaaS/消费者应用/平台业务经验，Outcome-Driven 产品管理方法论。核心交付物：PRD/Opportunity Assessment/Now-Next-Later 路线图/GTM Brief/Sprint Health Snapshot。六阶段工作流：Discovery → Framing → Definition → Delivery → Launch → Measurement。关键原则：功能即假设、发布即实验；路线图是赌注清单而非承诺；经常说不保护团队焦点。 +- Entities created: 无（Alex/PM persona 仅出现 1 次；B2B SaaS/Consumer Apps/Platform Businesses 属宽泛业务分类，无需单独创建 Entity） +- Concepts created: 无（RICE/NorthStarMetric/PRD/GTMBrief/SprintHealth 均属具体执行模板，不满足"可抽象、可复用"条件；已在 Source Page Key Concepts 节以 [[wikilink]] 格式标注，待后续独立创建） +- Source page: wiki/sources/product-manager.md +- Notes: 与 [[product-feedback-synthesizer]] 互补（反馈收集 vs 产品决策）；与 [[Senior Project Manager Agent]] 属产品-项目协作层级（PM 偏战略，Senior PM 偏执行任务分解），无冲突 + +- Source file: Agent/agency-agents/product/product-feedback-synthesizer.md +- Status: ✅ 成功摄入 +- Summary: Product Feedback Synthesizer——The Agency Product 部门的用户反馈综合分析专家 Agent，专精于从多渠道（调查/访谈/工单/评论/社交媒体）收集、分析和综合用户反馈，将海量用户声音蒸馏为可量化的产品决策依据。核心能力：NLP 情感分析与满意度建模（RICE/MoSCoW/Kano 优先级框架）、用户旅程映射、流失预测与早期预警系统。核心理念：定性反馈 → 定量优先级 → 数据驱动路线图。成功指标：24h 内处理关键问题、90%+ 主题准确率、85% 综合反馈产生可衡量决策、NPS 提升 10+ 分。 +- Concepts created: 无（NPS/RICE/MoSCoW/Kano/SentimentAnalysis/UserJourneyMapping/ChurnPrediction/VoC/FeedbackLoop 各仅在本文出现 1 次，待后续批次独立创建；已在 Source Page Key Concepts 节以 [[wikilink]] 格式标注） +- Entities created: 无（The Agency 仅在本文出现 1 次，通过 Source Page Key Entities 保留） +- Source page: wiki/sources/product-feedback-synthesizer.md +- Notes: index.md 中原有 "source missing" 占位条目（2026-04-20）已替换为完整条目；overview.md 新增 "### The Agency — Product 部门" 章节并添加 product-feedback-synthesizer 条目置于 Finance 部门之前；与 [[product-sprint-prioritizer]] 存在优先级框架差异（价值优先 vs 资源约束），已记录于 Source Page Contradictions 节。 + +## [2026-04-25] ingest | Specialized Developer Advocate +- Source file: Agent/agency-agents/specialized/specialized-developer-advocate.md +- Status: ✅ 成功摄入 +- Summary: Developer Advocate Agent——The Agency Specialized 部门的开发者关系工程师，通过 DX 工程审计（Time-to-First-Success）、技术内容创作、社区运营（GitHub/Discord/Slack 响应）、产品反馈闭环（Voice of Developer 报告）推动平台采用。核心理念：Authentic 技术参与（"You don't do marketing — you do developer success"）；DX 改善复合效应优于内容发布；AstroTurf 永久性摧毁开发者信任。成功指标：首次成功 ≤15min、GitHub 响应 ≤24h、教程完成率 ≥50%、开发者 NPS ≥8/10。 +- Concepts created: 无（DeveloperExperienceEngineering/TechnicalContentCreation/CommunityBuilding/ProductFeedbackLoop/DeveloperOnboardingAudit 等均在源文档仅出现 1 次，待后续批次独立创建；已在 Source Page Key Concepts 节以 [[wikilink]] 格式标注） +- Entities created: 无（GitHub/StackOverflow/Discord/KubeCon/OpenTelemetry/The Agency 等各仅出现 1 次，通过 Source Page Key Entities 保留） +- Source page: wiki/sources/specialized-developer-advocate.md +- Notes: index.md 中原有 "source missing" 占位条目（2026-04-20）已替换为完整条目；overview.md Specialized 部门新增 Developer Advocate 条目置于 report-distribution-agent 之后；无重大内容冲突，仅与 [[specialized-workflow-architect]] 存在设计哲学层面的潜在张力（DX 质量优先 vs 快速交付），已记录于 Source Page Contradictions 节。 + +## [2026-04-25] ingest | Automation Governance Architect +- Source file: Agent/agency-agents/specialized/automation-governance-architect.md +- Status: ✅ 成功摄入 +- Summary: Automation Governance Architect——企业自动化治理架构师，负责在实施前评估业务自动化的价值、风险和可维护性。基于 n8n 编排标准 + 四维决策框架（时间节省、数据关键性、外部依赖风险、可扩展性），通过 APPROVE/APPROVE AS PILOT/PARTIAL AUTOMATION ONLY/DEFER/REJECT 五种裁决防止低价值或高风险自动化进入生产，同时推动高价值自动化的标准化落地。核心原则：技术可行不等于值得自动化；简单健壮优于精巧脆弱；每个推荐必须包含降级方案和责任人；无文档和测试证据不得标记为完成。 +- Concepts created: AutomationGovernance, DecisionFramework, N8nWorkflowStandard, ReliabilityBaseline, IntegrationGovernance, ReAuditTriggers +- Entities created: 无（n8n 仅出现 1 次，不满足"出现 ≥2 次"条件，通过 Source Page Key Entities 保留） +- Source page: wiki/sources/automation-governance-architect.md +- Notes: index.md 中原有 "source missing" 占位条目（2026-04-20）已替换为完整条目；overview.md compliance-auditor 条目中已引用 [[automation-governance-architect]]，无需额外修订；无重大内容冲突，仅与 [[specialized-workflow-architect]] 存在设计哲学层面的潜在张力（治理优先 vs 快速交付），已记录于 Source Page Contradictions 节。 + +## [2026-04-25] ingest | Report Distribution Agent +- Source file: Agent/agency-agents/specialized/report-distribution-agent.md +- Status: ✅ 成功摄入 +- Summary: Report Distribution Agent——The Agency Specialized 部门的销售报告自动分发 Agent，基于区域路由参数将合并报告精准送达对应业务员和管理层，支撑工作日 8:00 AM 定时日报和周一 7:00 AM 周报分发，99%+ 定时送达率。核心能力：区域路由（业务员仅收到其区域数据）、公司级汇总报告（管理员/经理）、HTML 邮件格式化、SMTP 传输、分发日志审计（sent/failed 状态 + 时间戳）、失败重试 + 容错继续分发。属销售数据管道的分发层，上游对接 Data Consolidation Agent。 +- Concepts created: 无（Territory Routing/SMTP Transport/Audit Trail/Scheduled Distribution 各仅在本文出现 1 次，暂不单独建 Concept 页面；已在 Source Page Key Concepts 节以 [[wikilink]] 格式标注） +- Entities created: 无（STGCRM/Data Consolidation Agent 各仅出现 1 次，通过 Source Page Key Entities 保留） +- Source page: wiki/sources/report-distribution-agent.md +- Notes: index.md 中原有 "source missing" 占位条目（2026-04-20）已替换为完整条目；overview.md Specialized 部门新增 Report Distribution Agent 条目置于 data-consolidation-agent 之后；无内容冲突（与 [[specialized-document-generator]]（文档生成）和 [[data-consolidation-agent]]（数据整合）均为互补关系，无矛盾）。 +- Source file: Agent/agency-agents/specialized/data-consolidation-agent.md +- Status: ✅ 成功摄入 +- Summary: Data Consolidation Agent——The Agency Specialized 部门的销售数据整合专家 Agent，将分散的销售提取数据聚合为实时仪表盘。核心能力：并行多维度查询（地区/代表/管道/时间维度）、实时达成率计算（revenue/quota * 100，处理除零）、MTD/YTD/Year End 多时间视图、< 1 秒加载 + 60 秒自动刷新、零数据不一致保证。 +- Concepts created: 无（Dashboard Report/Territory Report/Sales Attainment/Pipeline Snapshot/Metric Aggregation 均通过 Source Page 内 [[wikilink]] 形式表达，未单独建 Concept 页面） +- Entities created: 无（Sales Data Extraction Agent/Report Distribution Agent/Sales Pipeline Analyst/Sales Coach Agent 各仅出现 1 次，通过 Source Page Key Entities 保留） +- Source page: wiki/sources/data-consolidation-agent.md +- Notes: index.md 消除原 "source missing" 占位条目，替换为完整条目；overview.md 新增 Data Consolidation Agent 条目（置于 Specialized 部门末尾，与现有 Sales Pipeline Analyst/Sales Coach Agent 链接建立关系）；无内容冲突（与 Sales Pipeline Analyst 共享数据源但职责互补，与 Report Distribution Agent 构成顺序管道）。 +- Source file: Agent/agency-agents/specialized/supply-chain-strategist.md +- Status: ✅ 成功摄入 +- Summary: Supply Chain Strategist——The Agency Specialized 部门的中国制造业供应链全链路专家 Agent，帮助企业建立高效、有韧性、可持续的供应链体系。核心：供应商 ABC 分级管理 + Kraljic 矩阵采购策略 + TCO 全成本分析 + 库存优化模型（EOQ/ROP/安全库存/VMI/JIT）+ 供应链数字化成熟度 L1-L5 五级评估 + RBA/SA8000/CMRT 合规体系。典型成就：紧固件品类年采购成本降低 12%（节省 ¥870,000）。 +- Concepts created: 无（Kraljic Matrix/TCO/EOQ/RBA/SA8000 等均在源文档仅出现 1 次，待后续批次独立创建；已在 Source Page Key Concepts 节以 [[wikilink]] 格式标注） +- Entities created: 无（1688/Canton Fair/SGS/TUV 等各渠道平台在源文档均仅出现 1 次，待后续批次独立创建；已在 Source Page Key Entities 节以 [[wikilink]] 格式标注） +- Source page: wiki/sources/supply-chain-strategist.md +- Notes: index.md 新增 Supply Chain Strategist Agent 条目，同时替换原有 "source missing" 占位条目（2026-04-20 supply-chain-strategist）为完整条目；overview.md Specialized 部门新增 Supply Chain Strategist 条目置于 zk-steward 之后；无内容冲突检测（与 [[specialized-french-consulting-market]] 为 Specialized 部门内的不同垂直领域，无直接矛盾）。 + +## [2026-04-25] ingest | ZK Steward Agent +- Source file: Agent/agency-agents/specialized/zk-steward.md +- Status: ✅ 成功摄入 +- Summary: ZK Steward——AI 时代 Luhmann Zettelkasten 知识库管家，以 Niklas Luhmann 的卡片盒方法论为默认视角，融合多领域专家心智模型（Feynman/Karpathy/Munger/Ogilvy 等），通过原子笔记+ Luhmann 四原则验证门+领域专家切换实现有机知识网络增长。 +- Concepts created: [[Zettelkasten]]（卡片盒知识管理法）、[[Luhmann-四原则]]（原子性/连接性/有机增长/持续对话验证门）、[[Domain-Thinking]]（领域专家三维切换机制）、[[Gegenrede]]（德语反诘，跨学科反问机制）、[[Link-Proposer]]（链接提议器三步流程）、[[Daily-Log]]（Intent/Changes/Open loops 每日日志） +- Entities created: [[Niklas-Luhmann]]（德国社会学家，Zettelkasten 发明者）、[[zk-steward-companion]]（GitHub 配套技能库） +- Source page: wiki/sources/zk-steward.md +- Notes: index.md 中原有 "source missing" 占位条目（2026-04-20）已替换为完整条目；overview.md Specialized 部门新增 ZK Steward 条目置于 specialized-korean-business-navigator 之后；entities/ 和 concepts/ 目录已创建并填充 2 个 Entity + 6 个 Concept 页面；无内容冲突检测（与 [[Second-Brain]] 为互补关系，详见 Contradictions 部分）。 + +## [2026-04-25] ingest | Korean Business Navigator +- Source file: Agent/agency-agents/specialized/specialized-korean-business-navigator.md +- Status: ✅ 成功摄入 +- Summary: Korean Business Navigator——The Agency Specialized 部门的韩国商业文化导航 Agent，帮助外国专业人员解码韩国商业隐性规则。核心洞察：品의流程耗时 6-16 周，永远不要在第一次会议要求时间线；韩国"yes"≠同意，沉默=内部讨论进行中；成交发生在会议室外的走廊。六阶段品의时间线（소개→미팅→내부검토→품의서→결재→계약）、Nunchi 解码表（含"검토해보겠습니다"=婉拒等5+信号）、KakaoTalk 分阶段消息模板、韩国企业职级体系、Proof Project 策略。 +- Concepts created: [[품의]]（韩国共识审批流程，含六阶段时间线及品의서/결재라인规范）、[[Nunchi]]（韩国文化"读心术"，含6+常用商业解码表） +- Entities created: [[KakaoTalk]]（韩国主流即时通讯平台，商务沟通核心渠道；群聊必须韩语、9AM-7PM KST商务时间、24h只读不回会被注意） +- Source page: wiki/sources/specialized-korean-business-navigator.md +- Notes: index.md 中原有 "source missing" 占位条目（2026-04-20）已移除并替换为完整条目；overview.md Specialized 部门新增 Korean Business Navigator 条目置于 specialized-french-consulting-market 之后；index.md 新增 Entities 条目（KakaoTalk）和 Concepts 条目（품의、Nunchi）；无内容冲突（与 Cultural Intelligence Strategist 为互补关系，已在 overview.md 建立链接）。 + +## [2026-04-25] ingest | French Consulting Market Navigator +- Source file: Agent/agency-agents/specialized/specialized-french-consulting-market.md +- Status: ✅ 成功摄入 +- Summary: French Consulting Market Navigator——The Agency Specialized 部门的法国 IT 咨询市场（ESN/SI）生态导航 Agent，帮助独立顾问最大化 TJM 税后净收入。核心洞察：ESN Margin 25-40% 不透明；Portage Salarial vs Micro-Entrepreneur 税后收益差距 338€/天（社保保护价格）；付款延迟结构性 60-90 天；Malt 公开定价即为市场锚点。五大平台对比 + 三层 ESN 分层定价 + TJM 阶梯锚定谈判四步法。 +- Concepts created: [[Portage-Salarial]]（Portage Salarial 机制完整解析：管理费5-10%、雇主/雇员社保合计~67%、700€/天→208€/天净）、[[ESN]]（Entreprise de Services Numériques 三级分类及 Margin 架构详解） +- Entities created: 无（平台 Malt/collective.work/Comet/Crème/Free-Work 及 ESN Cloudity/Accenture 仅出现1次，通过 Source Page Key Entities 保留） +- Source page: wiki/sources/specialized-french-consulting-market.md +- Notes: index.md 中原有 "source missing" 占位条目（2026-04-20）已替换为完整条目；overview.md Specialized 部门新增 specialized-french-consulting-market 条目置于 study-abroad-advisor 之后；Portage-Salarial 和 ESN 均已存在于 wiki/concepts/，无需重复创建，仅补充了本次来源的 sources 字段 + +## [2026-04-25] ingest | Blockchain Security Auditor +- Source file: Agent/agency-agents/specialized/blockchain-security-auditor.md +- Status: ✅ 成功摄入 +- Summary: Blockchain Security Auditor——The Agency Specialized 部门的智能合约安全审计 Agent，专职发现 DeFi 协议与区块链应用中的漏洞。自动化静态分析（Slither/Mythril/Echidna）+ 人工逐行审查 + 属性化模糊测试 + 经济博弈建模五步工作流。每个发现必须包含可复现 PoC；自动化工具只能捕获约 30% 的真实漏洞；OpenZeppelin 误用本身是漏洞类型。 +- Concepts created: [[Reentrancy]]（重入攻击，含单函数/跨函数/只读/ERC-777钩子四种模式及完整防御机制）、[[Oracle-Manipulation]]（预言机操纵，含AMM/TWAP/Chainlink三类模式及修复方案） +- Entities created: [[The-DAO-2016]]（2016年360万ETH重入攻击）、[[Euler-Finance]]（2023年1.97亿美元donate-to-reserves攻击）、[[Nomad-Bridge]]（2022年1.9亿美元未初始化代理漏洞）、[[Curve-Finance]]（2023年7000万美元Vyper编译器bug） +- Source page: wiki/sources/blockchain-security-auditor.md +- Notes: overview.md 同步更新；index.md 消除了原 source missing 标记并补全了摘要 + +## [2026-04-25] ingest | Agents Orchestrator +- Source file: Agent/agency-agents/specialized/agents-orchestrator.md +- Status: ✅ 成功摄入 +- Summary: Agents Orchestrator——AI 多智能体开发流水线编排器，自主管理从规格到交付的完整开发流程。四阶段流水线（PM→ArchitectUX→[Dev↔QA循环]→最终集成），基于截图证据的质量门控，最大3次重试上限。 +- Concepts created: 无（Dev-QA-Loop、Quality-Gate 等概念均通过 Source Page 内 wikilinks 形式表达，未单独建 Concept 页面） +- Entities created: 无（ArchitectUX、EvidenceQA、TestingRealityChecker、ProjectManagerSenior 等在现有 wiki 中已作为 wikilinks 使用，无需新建 Entity 页面） +- Source page: wiki/sources/agents-orchestrator.md +- Notes: index.md 中原有 "source missing" 占位条目（2026-04-20）已替换为完整条目；overview.md Specialized 部门新增 Agents-Orchestrator 条目置于 identity-graph-operator 之后；与 specialized-workflow-architect 的职责关系已记录于 Contradictions 部分（设计层 vs 执行层，不存在功能重叠）。 + +## [2026-04-25] ingest | MCP Builder Agent +- Source file: Agent/agency-agents/specialized/specialized-mcp-builder.md +- Status: ✅ 成功摄入 +- Summary: MCP Builder Agent——AI Agent 的 MCP（Model Context Protocol）服务器开发专家，设计、构建、测试和部署 MCP 服务器，为 AI Agent 提供自定义工具（Tools）、资源（Resources）和提示词模板（Prompts）能力。核心理念：工具命名即 UX，正确选用率目标 >90%；技术栈 TypeScript+Zod 或 Python+Pydantic；核心原则：无状态设计、结构化错误返回、环境变量密钥、边界验证、真实 Agent 测试。 +- Concepts created: 无（Key Concepts 中 10 个术语均为 Source Page 内可解释的协议/框架级概念，通过 wikilinks 形式表达，不具备跨页面复用价值，未单独建 Concept 页面） +- Entities created: 无（MCP SDK/FastMCP/Zod/Pydantic 仅出现 1 次，不满足 ≥2 次条件，通过 Key Entities 链接保留在 Source Page） +- Source page: wiki/sources/specialized-mcp-builder.md +- Notes: index.md 中原有 "source missing" 占位条目（2026-04-20）已替换为完整条目；overview.md Specialized 部门新增 MCP Builder Agent 条目置于 visionos-spatial-engineer 之后；无冲突内容检测。 + +## [2026-04-25] ingest | Compliance Auditor Agent +- Source file: Agent/agency-agents/specialized/compliance-auditor.md +- Status: ✅ 成功摄入 +- Summary: Compliance Auditor Agent——The Agency Specialized 部门的技术合规审计专家，专注 SOC 2、ISO 27001、HIPAA、PCI-DSS 认证审计全流程。五步工作流：Scoping → Gap Assessment → Remediation Support → Audit Support → Continuous Compliance。核心原则：不跟随的政策比没政策更危险、证据必须证明整个审计周期持续有效、技术控制优于管理控制、自动化证据收集从第一天建立。 +- Concepts created: 无（Key Concepts 中 6 个术语均为 Source Page 内可解释的术语，不具备跨页面复用价值，未单独建 Concept 页面） +- Entities created: 无（SOC-2/ISO-27001/HIPAA/PCI-DSS 均为框架级标准，在多个来源中出现但以 wikilinks 形式表达，未单独建 Entity 页面） +- Source page: wiki/sources/compliance-auditor.md +- Notes: index.md 中原有 "source missing" 占位条目（2026-04-20）已移除并替换为完整条目；overview.md Specialized 部门新增 Compliance Auditor 条目置于 healthcare-marketing-compliance 之后；与 [[specialized-model-qa]] 在证据定义上的差异已记录于 Contradictions 部分。 + +## [2026-04-25] ingest | Specialized Salesforce Architect +- Source file: Agent/agency-agents/specialized/specialized-salesforce-architect.md +- Status: ✅ 成功摄入 +- Summary: Salesforce 企业级解决方案架构师 Agent — 多云架构设计（Sales/Service/Marketing/Commerce/Data Cloud/Agentforce）、企业集成模式（REST/Platform Events/CDC/MuleSoft）、数据模型设计与治理、Governor Limit 预算规划、CI/CD 部署策略（Salesforce DX/DevOps Center）。核心原则：Governor limits 不可协商、Bulkification 强制要求、Declarative-first、Trigger 只委托不分发、集成模式必须处理失败场景。 +- Concepts created: 无（技术术语通过 Source Page Key Concepts + wikilinks 表达，未单独建页面） +- Source page: wiki/sources/specialized-salesforce-architect.md +- Notes: 无冲突内容检测；MuleSoft、Shield Platform Encryption、DevOps Center 作为 Key Entities 链接保留在 Source Page；Platform Events vs CDC 对比表已提取为 Key Claims + +## [2026-04-25] ingest | Model QA Specialist +- Source file: Agent/agency-agents/specialized/specialized-model-qa.md +- Status: ✅ 成功摄入 +- Summary: Model QA Specialist——The Agency Specialized 部门的 ML/统计模型端到端独立审计专家 Agent，核心方法：10 大审计领域覆盖模型全生命周期（文档治理→数据重建→标签分析→分段评估→特征分析→模型复制→校准测试→性能监控→可解释性→业务影响），配套完整 Python 工具集（PSI 监控、Hosmer-Lemeshow 校准检验、SHAP 可解释性分析、PDP 偏依赖图、KS/AUC/Gini 判别指标）。核心原则：独立性、可复现性、证据链完整。成功指标：审计发现 95%+ 被确认有效、零部署后失败。 +- Concepts created: [[SHAP]]（特征归因可解释性框架）、[[Calibration-Testing]]（概率校准验证方法）、[[Discrimination-Metrics]]（判别能力指标体系 AUC/Gini/KS）、[[Partial-Dependence-Plots]]（偏依赖图）、[[Population-Stability-Index]]（群体稳定性指数）、[[Hosmer-Lemeshow-Test]]（校准拟合优度检验） +- Entities created: （The Agency Specialized 部门在多个来源中多次出现，本次检查 entities/ 目录已存在，未新建） +- Source page: wiki/sources/specialized-model-qa.md +- Notes: index.md 中原有 "source missing" 条目，本次摄入后已更新为完整条目。overview.md Specialized 部门新增 Model QA Specialist 条目置于 cultural-intelligence-strategist 之后。与 [[multi-agent-system-reliability]] 存在潜在张力（对抗辩论 vs 统计检验），已在 Contradictions 中记录。6 个 Concept 页面创建前已做去重检查，确认均不存在。与 specialized-workflow-architect（Reality Checker 验证）构成质量保障互补，已在 overview.md 建立链接关系。 + + +- Source file: Agent/agency-agents/specialized/corporate-training-designer.md +- Status: ✅ 成功摄入 +- Summary: Corporate Training Designer——The Agency Specialized 部门的企业培训体系架构师 Agent，核心方法：ADDIE 教学设计模型（分析→设计→开发→实施→评估）、Kirkpatrick 四级评估（反应→学习→行为→业务结果）、Bloom 认知六层次、Kolb 体验式学习圈、OMO 混合学习（线上认知→线下实践→社群持续）。核心价值观：优秀培训的衡量标准不是"教了什么"，而是"学员回去做了什么"。覆盖培训需求分析、课程体系设计、内容开发、内训师培养（TTT）、新员工培训、领导力发展（HIPO）、合规培训等全链路能力。 +- Concepts created: [[ADDIE-Model]]（ADDIE 教学设计模型）、[[Kirkpatrick-四级评估]]（培训效果四级评估框架）、[[Bloom-认知分类]]（认知六层次分类）、[[Kolb-体验式学习圈]]（体验式学习循环） +- Entities created: [[The-Agency]]（The Agency 多智能体系统组织，147 个 Agent 跨 12 部门） +- Source page: wiki/sources/corporate-training-designer.md +- Notes: index.md 中原有早期条目，本次为完整摄入。overview.md Specialized 部门新增 Corporate Training Designer 条目，并置于 Cultural Intelligence Strategist 之前（按摄取顺序）。4 个 Concept 页面创建前已做去重检查，确认均不存在。Corporate Training Designer 与 specialized-workflow-architect、cultural-intelligence-strategist 形成系统性设计能力互补，在 overview.md 中已建立链接关系。Corporate Training Designer 与其他 Agent 无明显内容冲突。 + +- Source file: Agent/agency-agents/specialized/specialized-cultural-intelligence-strategist.md +- Status: ✅ 成功摄入 +- Summary: Cultural Intelligence Strategist——The Agency Specialized 部门的文化包容性专家 Agent，核心职责：检测软件开发中的"隐性排斥"（Invisible Exclusion），包括 Western 默认命名结构、颜色语义冲突（红色=中国金融上涨）、性别二元假设、RTL 阅读方向等。通过四阶段工作流（盲点审计→自主研究→结构修正→解释原理）提供架构级文化智能解决方案。核心价值：将国际化从"亡羊补牢"提升为"架构前提条件"，拒绝表演性多元化，追求结构性包容。 +- Concepts created: [[Invisible-Exclusion]]（隐性排斥模式定义）、[[Architectural-Empathy]]（结构性同理心哲学）、[[Global-First-Architecture]]（国际化架构前提原则） +- Entities created: [[The-Agency]]（The Agency 多智能体系统组织，147 个 Agent 跨 12 部门） +- Source page: wiki/sources/specialized-cultural-intelligence-strategist.md +- Notes: index.md 中原有 "source missing" 条目，本次摄入后已更新为完整条目。overview.md Specialized 部门新增 Cultural Intelligence Strategist 条目。Concept 页面创建前已做去重检查，确认 Invisible-Exclusion、Architectural-Empathy、Global-First-Architecture 三个概念此前均不存在。与 [[InclusiveVisualsSpecialist]]（Design 部门包容性视觉专家）和 [[design-brand-guardian]]（品牌守护）存在跨部门协同与张力关系，已在 overview.md 和 source page Contradictions 中记录。 + +## [2026-04-25] ingest | Workflow Architect Agent Personality +- Source file: Agent/agency-agents/specialized/specialized-workflow-architect.md +- Status: ✅ 成功摄入 +- Summary: Workflow Architect——The Agency Specialized 部门的工作流设计专家 Agent，负责在代码编写前穷举建模系统所有路径。核心交付物：四视角工作流注册表（按工作流/按组件/按用户旅程/按状态）+ 工作流树规范格式（覆盖快乐路径+七类失败分支）+ 交接合同（Handoff Contract）+ 清理清单（Cleanup Inventory）。关键原则：不只为快乐路径设计，每个系统边界定义显式交接合同，Reality Checker 验证是 Draft 升为 Approved 的前置条件。Agent 协作协议：Reality Checker 验证→Backend Architect 实现→API Tester 生成测试用例→DevOps Automator 验证清理顺序。与 [[Designing-for-Agentic-AI]] 存在潜在冲突（确定性要求 vs LLM 概率性），已在 Contradictions 中记录。 +- Concepts created: [[Workflow-Registry]]（四视角工作流注册表）、[[Observable-States]]（四维度可观察状态）、[[Handoff-Contract]]（系统边界交接合同）、[[Workflow-Tree-Spec]]（结构化工作流树规范格式） +- Entities created: （Backend Architect/Reality Checker/API Tester/DevOps Automator/Security Engineer 在当前 sources 中出现次数均 < 2，暂不创建 Entity 页面） +- Source page: wiki/sources/specialized-workflow-architect.md +- Notes: index.md 中原有 "source missing" 条目，本次摄入后已更新为完整条目并修正日期。overview.md Specialized 部门新增 Workflow Architect 条目。Concept 页面创建前已做去重检查，Workflow-Engineering（已存在，定义侧重 AI 执行流程 vs 本文档侧重工作流规范格式）保留原页面，新增页面侧重建模规范维度。 + +## [2026-04-25] ingest | LSP/Index Engineer Agent Personality +- Source file: Agent/agency-agents/specialized/lsp-index-engineer.md +- Status: ✅ 成功摄入 +- Summary: LSP/Index Engineer——The Agency Specialized 部门的代码智能系统架构师 Agent，通过 graphd LSP 聚合器将 TypeScript/PHP/Go/Rust/Python 等多语言 LSP 客户端统一编排为语义图谱。核心交付物：多语言 LSP 并发编排 + 统一图谱模式（节点：文件/符号，边：contains/imports/calls/refs）+ nav.index.jsonl 语义索引 + WebSocket 实时增量推送 + 原子性图谱更新保证。性能北极星：/graph <100ms、/nav <60ms、WebSocket <50ms、100k+ 符号无性能降级。TypeScript 和 PHP 为默认生产就绪要求。 +- Concepts created: [[LSP-317-Specification]]（LSP 3.17 协议规范）、[[Semantic-Index-Infrastructure]]（语义索引基础设施）、[[Incremental-Graph-Update]]（增量图谱更新）、[[Performance-Contracts]]（性能契约） +- Entities created: [[The-Agency]]（The Agency 多智能体系统组织）、[[TypeScript-Language-Server]]（TypeScript 语言服务器）、[[Intelephense]]（PHP Intelephense LSP）、[[LSIF]]（Language Server Index Format） +- Source page: wiki/sources/lsp-index-engineer.md +- Notes: index.md 中原有 "source missing" 条目，本次摄入后已更新为完整条目。overview.md Specialized 部门新增 LSP/Index Engineer 条目，并同步更新 Conflict Areas（#12 LSP 图谱确定性 vs Workflow 穷举概率性）。4 个 Concept 页面创建前已做去重检查，确认 LSP-317-Specification、Semantic-Index-Infrastructure、Incremental-Graph-Update、Performance-Contracts 均不存在。与 [[specialized-workflow-architect]] 存在张力（确定性约束 vs LLM 概率性上限），已在 Contradictions 中记录。4 个 Entity 页面中 The-Agency 已在 overview.md 中被多次引用，新增 Entity 页面属首次正式创建。与 [[multi-agent-system-reliability]] 共享"架构约束优于提示词约束"思想，已在 overview.md 中建立链接。 + +## [2026-04-25] ingest | Agentic Identity & Trust Architect（补充摄入） +- Source file: Agent/agency-agents/specialized/agentic-identity-trust.md +- Status: ✅ 补充摄入（source page 已存在，本次补充 Concept 页面） +- Summary: Agentic Identity & Trust Architect——自主 Agent 身份认证与信任验证基础设施专家 Agent，解决多 Agent 环境中的身份伪造、授权冒用、审计日志篡改等安全威胁。核心方法：密码学身份体系（Ed25519）、零信任验证模型、惩罚型信任评分（初始1.0，证据链损坏扣0.5，结果失败率×0.4扣分，凭证超90天扣0.1）、append-only 哈希链式证据记录、多跳委托链验证（任意链节断裂则全链失效）、Fail-Closed 授权（无法验证时默认拒绝）、对等验证协议（Peer Verifier）。高级能力：算法敏捷性（后量子迁移预留抽象层）、NIST 后量子标准评估（ML-DSA/ML-KEM/SLH-DSA）、跨框架身份联邦（A2A/MCP/REST/SDK）。 +- Concepts created: [[Zero-Trust]]（永不信任，必须验证）、[[Evidence-Chain]]（哈希链式仅追加证据记录）、[[Trust-Scoring]]（基于可验证结果的惩罚型信任评分）、[[Delegation-Chain]]（多跳委托链验证）、[[Fail-Closed]]（失败默认拒绝授权）、[[Peer-Verification]]（对等验证协议）、[[Algorithm-Agility]]（密码学算法可升级性） +- Source page: wiki/sources/agentic-identity-trust.md +- Notes: 与 [[Identity Graph Operator]] 互补——前者处理 Agent 身份证明（密码学确定性），后者处理实体身份匹配（概率性），共同构成完整身份层。与 [[Designing-for-Agentic-AI]] 存在潜在冲突（零信任要求确定性 vs LLM 概率性），已在 Contradictions 中记录。本文件在 index.md中原标记为"source missing"，本次已补全为完整 source page。 +- Source file: Agent/agency-agents/specialized/specialized-document-generator.md +- Status: ✅ 成功摄入 +- Summary: Document Generator——The Agency Specialized 部门的程序化文档生成专家 Agent，通过代码方式（Python/Node.js）生成 PDF、PPTX、DOCX、XLSX 等专业文档。核心工具栈：PDF（reportlab/weasyprint/fpdf2）、PPTX（python-pptx/pptxgenjs）、XLSX（openpyxl/xlsxwriter/exceljs）、DOCX（python-docx/docx）。核心原则：样式系统优先、品牌一致性、数据驱动、无障碍设计、模板可复用。 +- Concepts created: 无（文档生成工具库不宜抽象为 Concept） +- Source page: wiki/sources/specialized-document-generator.md +- Notes: index 中已存在同名条目（来源缺失），本次摄入后标记为已解决。与 [[report-distribution-agent]]（文档分发）和 [[agents-orchestrator]]（工作流编排）存在潜在协同关系，建议后续摄入时补充连接。 + +- Source file: Agent/agency-agents/specialized/identity-graph-operator.md +- Status: ✅ 成功摄入 +- Summary: Identity Graph Operator——多智能体系统共享身份图谱运营专家 Agent，解决多 Agent 系统的身份孤岛问题（重复记录/冲突操作/级联错误）。核心方法：规范化（昵称扩展/E.164 电话/邮箱小写）→ 阻塞（blocking key 筛选候选）→ 评分（字段级加权）→ 聚类。merge/split 通过乐观锁执行，按置信度分级（>0.95 直接合并、0.6-0.95 提案审查、<0.6 创建新实体）。保留完整事件历史。 +- Concepts created: [[Identity-Resolution]]（身份解析四步流程框架）、[[Evidence-based-Merge-Proposal]]（证据驱动合并提案协议）、[[Blocking]]（阻塞分块技术）、[[Fuzzy-Matching]]（模糊匹配技术）、[[Confidence-Score]]（置信度评分与阈值决策） +- Source page: wiki/sources/identity-graph-operator.md +- Notes: 与 [[Designing-for-Agentic-AI]] 存在潜在冲突：确定性要求与 LLM 概率性行为如何协调，当前观点认为通过将核心逻辑从 LLM 推理分离来解决。index 中已存在同名 [[identity-graph-operator]] 条目（来源缺失），本次摄入后应标记为已解决。 + +## [2026-04-25] ingest | Accounts Payable Agent Personality +- Source file: Agent/agency-agents/specialized/accounts-payable-agent.md +- Status: ✅ 成功摄入 +- Summary: AccountsPayable Agent——The Agency 财务部门的自主支付运营专员 Agent，处理供应商付款、承包商发票和周期性账单，覆盖 ACH/Wire/Crypto/Stablecoin/Payment API 全支付通道。核心原则：幂等性优先（reference ID 去重，零重复付款）、审计全链路、最优通道路由（失败自动切换备选通道）、严格额度管控（超授权额度人工审批）。通过 tool calls 与 Contracts Agent、Project Manager Agent、HR Agent 集成。成功指标：零重复付款、< 2 分钟执行时间、100% 审计覆盖、60 秒 escalation SLA。 +- Concepts created: （文档内概念均为具体实现细节，不满足可独立复用条件，未创建 Concept 页面） +- Entities created: （各协作 Agent 在本文档中各仅出现 1 次，不满足出现 ≥ 2 次条件，未创建 Entity 页面） +- Source page: wiki/sources/accounts-payable-agent.md +- Notes: 无已知冲突。本文档为单一 Agent 设计文档，与 [[Accounts-Payable-Agent]] 协作的各 Agent 需在各自文档中补充对应协作关系。 + +## [2026-04-25] ingest | Specialized Civil Engineer Agent +- Source file: Agent/agency-agents/specialized/specialized-civil-engineer.md +- Status: ✅ 成功摄入 +- Summary: Civil Engineer Agent——全球设计标准覆盖的结构与土木工程专家 Agent，驾驭 Eurocode（EN 1990–1999 + 各国 National Annex）、ACI 318（LRFD/SD）、AISC 360、ASCE 7、GB/IS/AIJ 等全球主流建筑规范体系。核心方法：ULS+SLS 双重验证、多标准冲突处理（识别→记录→保守优先→Basis of Design）、岩土工程全流程。计算交付物：钢梁 AISC 360 LRFD 计算包、RC 梁 Eurocode EN 1992-1-1 计算包、Terzaghi 岩土地基承载力分析。六阶段工作流：项目范围→初步设计→详细计算→建造文档→规范合规→施工支持。 +- Concepts created: [[ULS]], [[SLS]], [[National-Annex]], [[LRFD]], [[Basis-of-Design]], [[BIM-Coordination]], [[Ductility-Class]] +- Entities created: [[Eurocode]], [[AISC-360]], [[ACI-318]], [[ASCE-7]], [[EN-1997]], [[AIJ]] +- Source page: wiki/sources/specialized-civil-engineer.md +- Notes: 无已知冲突。该 Agent 覆盖全球独立规范体系，各标准间差异已明确标注，不可混用。 + +- Source file: Agent/agency-agents/project-management/project-management-experiment-tracker.md +- Status: ✅ 成功摄入 +- Summary: Experiment Tracker Agent——The Agency 项目管理部门的实验追踪专家 Agent，专注于 A/B 测试、功能实验和假设验证的科学化管理。核心交付物：实验设计文档模板和实验结果报告模板。成功指标：95% 实验达统计显著性、每季度 15+ 实验、70% 成功率、80% 成功实验落地。高级能力：多臂老虎机、贝叶斯分析、因果推断、ML 模型 A/B 测试。 +- Concepts created: [[A/B-Testing]], [[Statistical-Significance]], [[Power-Analysis]], [[Hypothesis-Validation]], [[Experiment-Portfolio-Management]], [[Multi-Armed-Bandits]], [[Bayesian-Analysis]], [[Causal-Inference]] +- Entities created: [[Project-Management-Experiment-Tracker]] +- Source page: wiki/sources/project-management-experiment-tracker.md +- Notes: 与 [[Project-Management-Studio-Operations]] 存在潜在张力（实验节奏 vs 内容制作节奏），已记录于 Contradictions + +## [2026-04-25] ingest | Studio Operations Agent Personality +- Source file: Agent/agency-agents/project-management/project-management-studio-operations.md +- Status: ✅ 成功摄入 +- Summary: Studio Operations Agent——The Agency 项目管理部门的执行层 Agent，专注于工作室日常运营效率、流程优化和资源协调。核心交付物：SOP 模板（四步工作流：评估→协调→实施→监控）和运营效率报告模板。成功指标：95% 运营效率、99.5% 系统正常运行时间、年度成本降低 10%、支持响应时间 < 2 小时。 +- Concepts created: （本次未创建独立 Concept 页面——文档内各概念（Standard Operating Procedure/Operational Efficiency 等）均与 [[The Agency]] 生态强绑定，不满足可独立复用条件） +- Entities created: （本次未创建独立 Entity 页面——文档内唯一实体 [[The Agency]] 在 Wiki 中已有充分引用） +- Source page: wiki/sources/project-management-studio-operations.md +- Notes: 与 [[project-management-studio-producer]]（战略层）和 [[ProjectManagerSenior]]（任务分解层）构成完整项目管理体系层级；与 [[Project-Management-Jira-Workflow-Steward]] 和 [[Project-Management-Project-Shepherd]] 协同；index.md 中标记的 expected 条目已补全 + +## [2026-04-25] ingest | Senior Project Manager Agent Personality +- Source file: Agent/agency-agents/project-management/project-manager-senior.md +- Status: ✅ 成功摄入 +- Summary: Senior Project Manager——The Agency 项目管理部门的执行层 Agent，专注于将网站规格文档（site-setup.md）精准转化为 30-60 分钟可执行开发任务列表。核心方法：精确引用规格原则 + 务实范围控制（拒绝 luxury/premium 除非明确）+ 开发者优先任务描述。核心约束：不添加后台进程、不启动开发服务器、必须包含 Playwright 截图测试。 +- Concepts created: （本次未创建独立 Concept 页面——文档内各概念均仅出现 1 次，不满足 ≥ 2 次创建门槛） +- Entities created: （本次未创建独立 Entity 页面——文档内各实体均仅出现 1 次，不满足 ≥ 2 次创建门槛） +- Contradictions detected: 与 [[Project-Management-Project-Shepherd]] 存在职责边界张力——Senior PM 关注任务拆解细节，Shepherd 关注项目整体把控；两者形成执行层与规划层的协作关系，记录于 Source Page Contradictions 部分 +- Source page: wiki/sources/project-manager-senior.md +- Notes: index.md 占位符条目已替换（添加中文摘要）；overview.md 已补充 [[ProjectManagerSenior]] 独立段落，完善了项目管理层级的战略-执行协作关系描述 + +## [2026-04-25] ingest | Jira Workflow Steward Agent Personality +- Source file: Agent/agency-agents/project-management/project-management-jira-workflow-steward.md +- Status: ✅ 成功摄入 +- Summary: Jira Workflow Steward——交付纪律守护者 Agent，通过 Jira-Git 全链路绑定（Task→Branch→Commit→PR→Release）确保代码交付可审查、可回滚、可审计。核心机制：Jira Gate（无 Jira ID 则停止工作流）+ 分支策略（feature/bugfix/hotfix/release）+ Gitmoji 规范提交 + PR 模板 + Commit Hook 自动化验证。定位：Jira-linked commits 是质量工具而非合规打勾。 +- Concepts created: [[Jira-Git-Traceability]], [[Atomic-Commit]], [[Branch-Strategy]], [[Gitmoji-Commit]], [[Jira-Gate]], [[Pull-Request-Governance]], [[Delivery-Traceability]] +- Entities created: [[Jira-Workflow-Steward]], [[Gitmoji]] +- Contradictions detected: 与 [[Project-Management-Project-Shepherd]] 在职责边界存在互补张力——Steward 严格 gate（Jira ID 前置），若 Shepherd 未预创建任务则工作流中断，建议在 Shepherd 端增加预创建步骤；与 [[Project-Management-Studio-Producer]] 在交付粒度上属不同抽象层级（原子 commit vs 组合 Epic/Story），无直接冲突 +- Source page: wiki/sources/project-management-jira-workflow-steward.md +- Notes: 7 个 Concept 页面已创建并添加到 index.md；2 个 Entity 页面已创建（Jira-Workflow-Steward/Gitmoji）并添加到 index.md；source page 已添加与 Project-Management-Project-Shepherd 和 Studio-Producer 的跨文档矛盾记录；index.md 占位符条目已替换（2026-04-20 → 2026-04-25，添加中文摘要） + +## [2026-04-25] ingest | Project Shepherd Agent Personality +- Source file: Agent/agency-agents/project-management/project-management-project-shepherd.md +- Status: ✅ 成功摄入 +- Summary: Project Shepherd——AI Agent 项目管理人格，专职跨职能项目协调、时间线管理、干系人对齐与风险缓解。四阶段工作流：项目启动→团队组建→执行监控→质量交付。核心交付物：Project Charter 模板、Status Report 模板、风险缓解框架。成功指标：95% 按时交付、范围蔓延 < 10%、90% 风险提前缓解、干系人满意度 4.5/5。 +- Concepts created: （本次未创建独立 Concept 页面——文档内各概念均仅出现 1 次，不满足 ≥ 2 次创建门槛） +- Entities created: （本次未创建独立 Entity 页面——文档内各实体均仅出现 1 次，不满足 ≥ 2 次创建门槛） +- Contradictions detected: 无。本文档与 [[Project-Management-Studio-Operations]] 和 [[Project-Management-Senior]] 在项目管理层级上互补而非冲突，属层级差异。 +- Source page: wiki/sources/project-management-project-shepherd.md +- Notes: index.md 占位符条目已替换（2026-04-20 → 2026-04-25，添加中文摘要）；overview.md 第 65 行已包含 [[Project-Management-Project-Shepherd]] wikilink（项目管理层级链一环），无需额外修订 + +## [2026-04-25] ingest | Studio Producer Agent Personality +- Source file: Agent/agency-agents/project-management/project-management-studio-producer.md +- Status: ✅ 成功摄入 +- Summary: Studio Producer——The Agency 项目管理部门的高管级战略领导者 Agent，专注于创意愿景与商业目标对齐的组合管理。核心职责：战略组合规划（Tier 1/2/Innovation Pipeline 三级）、Portfolio ROI 管理（≥ 25%）、95% 按时交付率、高管级利益相关者沟通。四阶段工作流：战略规划→项目编排→领导力发展→绩效优化。 +- Concepts created: [[Strategic-Portfolio-Management]], [[Resource-Allocation]], [[Portfolio-ROI]], [[Innovation-Pipeline]], [[Stakeholder-Alignment]] +- Entities created: [[Studio-Producer]] +- Contradictions detected: 与 [[Project-Management-Studio-Operations]] 在战略（Producer）与运营（Operations）的权责边界存在张力，需通过 Portfolio Review 机制对齐；与 [[Project-Manager-Senior]] 的管理广度差异（组合 vs 单项目）属层级差异而非矛盾 +- Source page: wiki/sources/project-management-studio-producer.md +- Notes: 已在 overview.md 新增 "The Agency — Project Management 部门" 章节（位于 Paid Media 部门之前），包含 Studio Producer 完整段落及与其他项目管理 Agent 的层级关系描述；5 个 Concept 页面已创建；index.md 中 source 条目已替换（2026-04-20 → 2026-04-25）；Studio-Producer Entity 页面已创建并添加至 index.md + +## [2026-04-25] ingest | visionOS Spatial Engineer Agent Personality +- Source file: Agent/agency-agents/spatial-computing/visionos-spatial-engineer.md +- Status: ✅ 成功摄入 +- Summary: visionOS Spatial Engineer——Apple visionOS 26 原生空间计算 Agent，专注于 SwiftUI volumetric interfaces 和 Liquid Glass Design System 实现。核心能力：Liquid Glass 透明材质设计、Spatial Widgets、SwiftUI Volumetric APIs、RealityKit-SwiftUI 集成、Multi-Window Architecture、GPU 高效渲染。技术栈：SwiftUI / RealityKit / ARKit / Metal。 +- Concepts created: [[Liquid-Glass-Design-System]], [[Spatial-Widgets]], [[SwiftUI-Volumetric-APIs]], [[RealityKit-SwiftUI-Integration]], [[Multi-Window-Architecture]] +- Entities created: [[XR-Interface-Architect]], [[XR-Immersive-Developer]], [[XR-Cockpit-Interaction-Specialist]], [[macOS-Spatial-Metal-Engineer]] +- Contradictions detected: 与 [[XR-Immersive-Developer]] 在平台选择上存在差异（WebXR 跨平台 vs visionOS 原生独占），已记录于 Source Page Contradictions 部分；与 [[macOS-Spatial-Metal-Engineer]] 在技术栈选择上存在张力（SwiftUI 声明式 vs Metal 底层渲染），已记录为互补关系 +- Source page: wiki/sources/visionos-spatial-engineer.md +- Notes: index.md 已替换占位符条目（2026-04-20 → 2026-04-25，添加摘要描述）；overview.md 已新增独立段落（位于 macOS Spatial/Metal Engineer 段落后）；5 个 Concept 页面已创建并添加到 index.md；4 个 Entity 页面已创建（XR-Interface-Architect/XR-Immersive-Developer/XR-Cockpit-Interaction-Specialist/macOS-Spatial-Metal-Engineer）并添加到 index.md；相关 Entity 和 Concept 页面的 sources 列表已更新 + +## [2026-04-25] ingest | XR Interface Architect Agent Personality +- Source file: Agent/agency-agents/spatial-computing/xr-interface-architect.md +- Status: ✅ 成功摄入 +- Summary: XR Interface Architect——专注为 AR/VR/XR 沉浸式环境设计空间直觉化 UX/UI 的 AI Agent，支持 HUD / 浮动菜单 / 交互区域，支持四种输入模型（直接触摸/注视+捏合/控制器/手势），以人体工程学约束减少晕动症，构建座舱/仪表盘/可穿戴界面布局模板，运行可用性验证实验 +- Concepts created: [[SpatialInterfaceDesign]], [[MotionSicknessMitigation]], [[PresenceEnhancement]], [[MultimodalInput]], [[HUDDesign]] +- Entities created: [[XRImmersiveDeveloper]], [[XRCockpitInteractionSpecialist]] +- Contradictions detected: 无内容冲突；该 Agent 侧重界面设计与 UX，与侧重底层渲染工程的 [[macOS Spatial/Metal Engineer]] 不在同一问题域 +- Source page: wiki/sources/xr-interface-architect.md +- Notes: 更新了 overview.md 中 [[xr-cockpit-interaction-specialist]] 条目的层级关系描述（原文为 [[XR-Interface-Architect]]，现统一为小写 slug）；Entity 仅出现 1 次，不足独立建页阈值，通过 Sources 页面 Key Entities 建立链接 + +## [2026-04-25] ingest | Terminal Integration Specialist +- Source file: Agent/agency-agents/spatial-computing/terminal-integration-specialist.md +- Status: ✅ 成功摄入 +- Summary: Terminal Integration Specialist——专注于终端仿真、文本渲染优化和 SwiftTerm 集成的 Agent，服务于现代 Swift 应用程序（iOS/macOS/visionOS）。核心能力：VT100/xterm ANSI 转义序列完整支持、SwiftTerm 库集成、Core Graphics 文本渲染优化、SSH I/O 桥接（SwiftNIO SSH/NMSSH）、无障碍支持（VoiceOver/动态类型）。 +- Concepts created: [[VT100/xterm Standards]], [[SwiftTerm]], [[Core Graphics Optimization]], [[SSH I/O Bridging]], [[Scrollback Buffer]], [[Accessibility Integration]] +- Contradictions detected: 无明显内容冲突；该 Agent 专注于 Apple 平台和 SwiftTerm，与通用终端解决方案不在同一问题域 +- Source page: wiki/sources/terminal-integration-specialist.md +- Notes: 相关页面已建立连接：[[visionOS Spatial Engineer]] / [[macOS Spatial Metal Engineer]] / [[XR Interface Architect]] 均依赖终端集成能力；Entity 层面 SwiftTerm/SwiftNIO SSH/NMSSH/Core Graphics/Core Text 仅出现 1 次，不足独立建页阈值，通过 Sources 页面的 Key Entities 部分建立链接 + +## [2026-04-25] ingest | XR Immersive Developer Agent Personality +- Source file: Agent/agency-agents/spatial-computing/xr-immersive-developer.md +- Status: ✅ 成功摄入 +- Summary: XR Immersive Developer Agent——WebXR 沉浸式开发专家，基于 A-Frame/Three.js/Babylon.js 构建跨平台浏览器 AR/VR/XR 体验。核心能力：WebXR Device API 全套沉浸式支持（hand tracking / pinch / gaze / controller）、raycasting / hit testing / 实时物理交互、LOD / occlusion culling / shader tuning 性能优化、跨设备兼容层（Meta Quest / Vision Pro / HoloLens / mobile AR）。典型交付物：VR 训练模拟器、AR 可视化界面、空间界面。 +- Concepts created: [[Spatial-Computing]], [[WebXR]], [[Hand-Tracking]] +- Contradictions detected: 与 [[XR-Cockpit-Interaction-Specialist]] 在运动自由度设计上存在张力——后者强调固定视角约束（降低运动病），前者倾向开放空间沉浸体验；冲突点已记录于 overview.md 第 52 条及 [[xr-cockpit-interaction-specialist]] 来源页 Contradictions 节 +- Source page: wiki/sources/xr-immersive-developer.md +- Notes: Concept 页面 Spatial-Computing/WebXR/Hand-Tracking 已创建并添加到 index.md；overview.md 新增 xr-immersive-developer 独立段落（位于 Paid Media 部门之前）；Entity 层面，Meta Quest/Vision Pro/HoloLens/Mobile-AR 仅出现 1-2 次，不足独立建页阈值，通过 Sources 页面的 Key Entities 部分建立链接 + +## [2026-04-25] ingest | Sales Engineer Agent +- Source file: Agent/agency-agents/sales/sales-engineer.md +- Status: ✅ 成功摄入 +- Summary: Sales Engineer Agent——售前工程师 Agent，专注于在 B2B 技术评估中赢得技术决策。核心理念：技术决策先于商业合同，售前工程师必须将每一次技术对话连接到业务成果。核心能力：Demo Engineering（以影响力为导向的演示设计）+ POC Scoping（严格限定的概念验证）+ FIA Framework（Fact-Impact-Act 竞争定位）+ 技术异议解码 + 评估笔记维护。成功指标：技术赢率 70%+，POC 转化率 80%+，演示到下一步行动率 90%+，中位数 18 天技术决策。 +- Concepts created: [[Demo-Engineering]], [[POC-Scoping]], [[FIA-Framework]], [[Technical-Objection-Handling]], [[Aha-Moment]] +- Contradictions detected: 与 [[Sales Discovery Coach Agent]] 在技术发现阶段参与深度上存在张力——前者主张售前主导技术发现，后者主张销售发现以业务语言建立信任，已记录于 overview.md Conflict Areas 第 6 条 +- Source page: wiki/sources/sales-engineer.md +- Notes: 5 个新 Concept 页面已创建；overview.md 新增 sales-engineer 独立段落；index.md 新增 Sales Engineer Agent 条目；Conflict Areas 新增第 6 条；Entity 层面，Sales Engineer 与同团队其他 Agent 均仅出现 1-2 次，不足独立 Entity 建页阈值，已通过 Sources 页面的 Key Entities 部分建立链接 + +## [2026-04-25] ingest | Pipeline Analyst Agent +- Source file: Agent/agency-agents/sales/sales-pipeline-analyst.md +- Status: ✅ 成功摄入 +- Summary: Pipeline Analyst Agent——Revenue Operations 领域的 Pipeline 健康诊断与收入预测 AI Agent。核心框架：Pipeline Velocity =（合格机会数 × 平均 Deal 规模 × 胜率）/ 销售周期长度；质量调整覆盖度（高质量少量 Pipeline 优于大量低质量 Pipeline）；MEDDPICC Deal 健康评分（资格深度 + 互动强度 + 进展速度三维度 0-36 分）；多信号预测模型（历史转化 + Velocity 加权 + 互动调整 + 季节性 + AI 模式匹配）。预测输出 Commit（>90%）/Best Case（>60%）/Upside（<60%）三档。 +- Concepts created: [[MEDDPICC]], [[PipelineVelocity]], [[DealHealthScoring]], [[QualityAdjustedCoverage]] +- Contradictions detected: sales-coach.md 描述 MEDDPICC 为"六个维度"，正确为八个维度，已修正 +- Source page: wiki/sources/sales-pipeline-analyst.md +- Notes: Entity 层面，Pipeline Analyst 与 Sales Deal Strategist / Sales Account Strategist / Sales Coach 存在依赖关系，待相关 Source 页面完善后可进一步深化链接 + +## [2026-04-25] ingest | Outbound Strategist Agent +- Source file: Agent/agency-agents/sales/sales-outbound-strategist.md +- Status: ✅ 成功摄入 +- Summary: Outbound Strategist Agent——信号型出站销售策略师，将出站从"批量轰炸"转变为"精准触发"。核心理念：信号驱动出站转化率比无触发出站高 4-8 倍；信号半衰期 30 分钟，24 小时后失效，72 小时后竞争对手已成交。核心框架：三层信号分级体系（主动购买/组织变化/技术行为）+ 可证伪 ICP 定义 + 三层账户分级（Tier 1 深度多线程 / Tier 2 半个性化 / Tier 3 自动化轻定制）+ 8-12 触点 3-4 周多渠道序列。冷邮件回复率基准：泛化 1-3%、角色定制 5-8%、信号驱动 12-25%、推荐引入 30-50%。SDR 角色演变：从批量操作员 → 深度账户专家。 +- Concepts created: [[Signal-Based-Selling-Framework]], [[ICP (Ideal Customer Profile)]], [[Multi-Channel-Sequence-Architecture]], [[Account-Tiering-Model]] +- Concepts updated: [[Challenger-Sales-Model]]（sources 添加 sales-outbound-strategist）、[[Land-and-Expand]]（sources 添加 sales-outbound-strategist） +- Entities linked: Outbound Strategist Agent, SDR +- Source page: wiki/sources/sales-outbound-strategist.md +- Notes: overview.md 新增"### Sales Outbound Methodology"章节（位于 Sales Discovery Methodology 之前）；index.md Concepts 节新增 4 个概念条目；Entity 页面未创建（Outbound Strategist Agent 和 SDR 均仅出现 1 次，不足独立建页阈值）；与 [[sales-deal-strategist]] 的漏斗互补关系已记录（出站=漏斗顶部，Deal=漏斗中部） + +## [2026-04-25] ingest | Deal Strategist Agent +- Source file: Agent/agency-agents/sales/sales-deal-strategist.md +- Status: ✅ 成功摄入 +- Summary: Deal Strategist Agent——高级deal策略师与管线架构师智能体，专注于MEDDPICC资质评分、竞争定位和复杂B2B销售周期的赢单规划。核心理念：每个deal都是战略问题而非关系练习；MEDDPICC全面推行的组织赢率提升18%、deal规模扩大24%；Commit deals预测准确率85%+；Qualified Pipeline（28/40+）赢率35%+；永远不做单线程账户。核心框架：MEDDPICC八维评分（每维度5分，满分40）+ Challenger商业教学六步序列 + 竞争三区定位（Winning/Battling/Losing）+ 地雷问题布局 + 交易检查方法论。 +- Concepts updated: [[MEDDPICC]]（新增 Deal-Level Application 和 Deal Verdict Categories）、[[Challenger Sales Model]]（新增 Commercial Teaching 六步序列） +- Entities linked: [[Sales Coach Agent]], [[Discovery Coach Agent]], [[Sales Proposal Strategist]], Deal Strategist Agent（均出现1次，不足独立Entity建页阈值） +- Source page: wiki/sources/sales-deal-strategist.md +- Notes: index.md 已替换占位符条目（2026-04-20 → 2026-04-25）；overview.md 已新增独立段落（Sales Coaching Methodology 章节末尾）；MEDDPICC 和 Challenger Sales Model 两个 Concept 页面均已更新 sources 列表 + 新增 sales-deal-strategist 专属内容；未创建新 Entity/Concept 页面（Deal Scoring/Competitive Positioning/Win Planning 等概念在 sales-deal-strategist 源文档中均仅出现1次，不足独立建页阈值）；与 [[sales-discovery-coach]] 的"发现→策略"协同关系已记录；与 [[sales-proposal-strategist]] 在"策略分析 vs 叙事构建"上的互补关系已记录于 Contradictions + +## [2026-04-25] ingest | Account Strategist Agent +- Source file: Agent/agency-agents/sales/sales-account-strategist.md +- Status: ✅ 成功摄入 +- Summary: Account Strategist Agent——售后账户扩张策略师智能体，专门负责 Land-and-Expand 执行、QBR 设计、利益相关者映射和净收入留存（NRR）最大化。核心理念：最佳销售时机是客户成功时；永远不做单线程账户；NRR 是终极指标。核心框架：扩张信号四维度（信号+情境+时机+利益相关者对齐）、账户健康三色评分（绿扩张/黄稳定/红救流失）、多线程关系建设（每账户至少三条独立关系线）。 +- Concepts created: [[Land-and-Expand]], [[Net Revenue Retention (NRR)]], [[Account Health Score]] +- Entities linked: Account Executive (AE), Customer Success (CS), Product Team, Executive Sponsor +- Source page: wiki/sources/sales-account-strategist.md +- Notes: 与 [[sales-proposal-strategist]] 的"赢单叙事"互补（前者构建叙事，后者交付超越叙事）；与 [[sales-coach]] 协同（后者辅导卖方，前者辅导买方冠军）；与 [[sales-discovery-coach]] 形成完整销售生命周期覆盖（发现→赢单→扩张）；overview.md 新增"Sales Account Expansion Methodology"主题节；创建 3 个独立 Concept 页面（Land-and-Expand、NRR、Account Health Score） + +## [2026-04-25] ingest | Sales Proposal Strategist +- Status: ✅ 成功摄入 +- Summary: Sales Proposal Strategist——将 RFP 响应转化为赢单叙事的系统化提案方法论。核心框架：三幕提案叙事结构（理解挑战→解决方案旅程→转变状态）+ 3-5 个赢标主题矩阵 + 执行摘要五步模板 + 说服架构（首因/近因效应、认知负荷管理、社会认同排序、损失厌恶框架）。核心理念：提案在开篇100词决定胜负；叙事是差异化核心；永远不直接批评竞争对手；定价在价值之后；内容库按赢标主题而非章节组织。 +- Concepts created: [[WinThemes]], [[ThreeActProposalNarrative]], [[PersuasionArchitecture]] +- Entities linked: 无特定命名实体 +- Source page: wiki/sources/sales-proposal-strategist.md +- Notes: 与 [[sales-coach]] 在"辅导行为 vs 撰写结构"上形成 Sales 体系互补关系；与 [[sales-discovery-coach]] 的发现阶段输入为提案策略提供买方情境；无冲突发现；overview.md 暂不需要更新 + +## [2026-04-25] ingest | Sales Coach Agent +- Source file: Agent/agency-agents/sales/sales-coach.md +- Status: ✅ 成功摄入 +- Summary: Sales Coach Agent——AI 销售教练 Agent，通过苏格拉底式提问驱动销售代表成长。核心辅导框架：Richardson Sales Performance（四维能力）、Challenger 辅导模型、MEDDPICC 资质诊断。关键方法论：辅导行为而非结果；一次只做一件事；管道质量是管理工具；挑战"happy ears"要求可验证的承诺。数据支撑：正式辅导项目配额完成率91.2%，vs 非正式辅导84.7%；每周2小时辅导赢单率56%，vs 少于30分钟43%。 +- Concepts created: MEDDPICC, Challenger Sales Model +- Entities linked: Discovery Coach Agent（已有）、Sales Pipeline Analyst Agent（已有）、Sales Deal Strategist Agent（已有） +- Source page: wiki/sources/sales-coach.md +- Notes: 与 Discovery Coach Agent 的辅导焦点层次差异已记录于 Contradictions；source页面内 Key Concepts 详细记录了 MEDDPICC、Challenger、Richardson Sales Performance 等框架；overview.md 新增"Sales Coaching Methodology"主题节，置于"Sales Discovery Methodology"之后，两者协同关系已明确 + +## [2026-04-25] ingest | Discovery Coach Agent +- Source file: Agent/agency-agents/sales/sales-discovery-coach.md +- Status: ✅ 成功摄入 +- Summary: Discovery Coach Agent——销售发现访谈方法论教练智能体，坚信发现是交易成败的真正战场。整合三大发现框架（SPIN Selling / Gap Selling / Sandler Pain Funnel）+ 标准30分钟发现电话结构（开场2分钟 / 发现18分钟 / 定向pitch 6分钟 / 下一步4分钟）+ AECR异议处理框架（Acknowledg/Empathize/Clarify/Reframe）。核心原则：发现不是审讯，Implication问题通过激活损失厌恶推动成交，60/40规则（买家说话60%以上），最优秀销售多问一个问题。 +- Concepts created: SPIN Selling（作为wikilink保留于source页面内）、Gap Selling（同）、Sandler Pain Funnel（同）、AECR Framework（同）、Upfront Contract（同）、Discovery Call Structure（同） +- Entities linked: Neil Rackham（同）、Keenan（同）、Sandler（同） +- Source page: wiki/sources/sales-discovery-coach.md +- Notes: Entity/Concept页面未单独创建（均首次出现且可抽象为独立概念，建议在后续摄入相关源文件时再评估）；未发现与现有Wiki内容的冲突；overview.md新增"Sales Discovery Methodology"主题节；source页面内详细记录了各框架的定义和引用 + +## [2026-04-25] ingest | Paid Media Ad Creative Strategist Agent +- Source file: Agent/agency-agents/paid-media/paid-media-creative-strategist.md +- Status: ✅ 成功摄入 +- Summary: 付费媒体广告创意策略 Agent——由 John Williams（@itallstartedwithaidea）设计，专注于 Google、Meta、Microsoft 及程序化平台的全渠道广告文案创作、响应式搜索广告（RSA）架构设计和系统性创意测试框架。核心理念：创意是自动化竞价环境中最大的可控杠杆，当算法接管了出价、预算和定向时，每一条标题、描述、图片和视频都是一个待验证的假设。 +- Concepts created: [[ResponsiveSearchAds]], [[AdStrength]], [[CreativeFatigue]], [[HookBodyCTA]], [[ABTesting]], [[MessageMatch]], [[AdExtensions]] +- Entities linked: [[GoogleAds]], [[MetaAdsManager]], [[MicrosoftAdvertising]], [[PerformanceMax]], [[JohnWilliams]]（已存在） +- Source page: wiki/sources/paid-media-creative-strategist.md +- Notes: 与 [[paid-media-ppc-strategist]] 在"自动化 vs 创意质量"权衡上的张力已记录于 Contradictions；与 [[paid-media-programmatic-buyer]] 在"创意新鲜度"上的潜在冲突已记录；与 [[paid-media-paid-social-strategist]] 协同关系已记录（受众洞察→平台原生创意执行）；overview.md 中 paid-media-creative-strategist 条目已从简略描述更新为完整条目，Key Concepts 行已更新 + +## [2026-04-25] ingest | Paid Social Strategist +- Source file: Agent/agency-agents/paid-media/paid-media-paid-social-strategist.md +- Status: ✅ 成功摄入 +- Summary: 跨平台付费社交广告专家 Agent，覆盖 Meta（Facebook/Instagram）、LinkedIn、TikTok、Pinterest、X 和 Snapchat，设计从引流到再营销的全漏斗社交广告项目。核心理念：社交广告本质是"打断"而非"回答"，必须构建平台原生体验而非跨平台复用创意。 +- Concepts created: [[Full-Funnel-Campaign-Architecture]], [[Custom-Audience-Engineering]], [[Conversions-API]], [[Advantage+-Campaigns]], [[Incrementality-Testing]], [[SKAdNetwork]] +- Entities created: [[Meta-Ads-Manager]], [[LinkedIn-Campaign-Manager]], [[TikTok-Ads]]; [[JohnWilliams]] 已更新 +- Source page: wiki/sources/paid-media-paid-social-strategist.md +- Notes: 与 [[paid-media-programmatic-buyer]] 在"自动化 vs. 控制"权衡上存在张力已记录于 Contradictions；与 [[paid-media-ppc-strategist]] 在跨渠道预算分配验证原则上有协同关系；与 [[paid-media-creative-strategist]] 在受众策略→创意方向上有依赖关系已记录 + +## [2026-05-06] ingest | Paid Media Search Query Analyst Agent +- Source file: Agent/agency-agents/paid-media/paid-media-search-query-analyst.md +- Status: ✅ 成功摄入 +- Summary: 付费媒体搜索词分析师 Agent——由 John Williams（@itallstartedwithaidea）设计，专注于从用户真实搜索词中挖掘洞察、构建分层负关键词架构、系统化提升付费搜索账户信噪比。核心能力：N-gram 分析、查询意图分类、匹配类型优化、查询雕塑（Query Sculpting）、浪费支出识别、关键词机会挖掘。核心理念：搜索查询优化是持续系统而非一次性任务，每浪费一美元在不相关查询上就是从转化查询中偷走一美元。成功指标：首次分析识别并消除 10-20% 非转化支出、无关查询展示占比 <5%、查询意图对齐度 80%+。 +- Concepts linked: [[SearchQueryOptimization]], [[NegativeKeywordArchitecture]], [[NgramAnalysis]], [[IntentClassification]], [[QuerySculpting]], [[SQOSScoring]], [[CloseVariantAnalysis]], [[WasteIdentification]], [[QueryClustering]], [[MatchTypeOptimization]], [[BrandVsNonbrandLeakageAnalysis]], [[CompetitorQueryInterception]], [[ShoppingSearchTermAnalysis]], [[PerformanceMaxInsights]] +- Entities linked: [[JohnWilliams]], [[GoogleAdsMCP]] +- Source page: wiki/sources/paid-media-search-query-analyst.md +- Notes: index.md 已替换占位符条目（2026-04-20 → 2026-05-06）；overview.md 已有 paid-media-search-query-analyst 条目（line 63），本次摄入更新了 Key Claims 和 Key Quotes，补充了 [[GoogleAdsMCP]] Entity；Concepts 和 Entities 在其他源页面中均仅出现 1 次，不足独立建页阈值（≥2 次），以 wikilink 形式记录于 Source page；与 [[paid-media-ppc-strategist]] 的协同关系已记录（策略制定依赖查询分析结果），与 [[paid-media-auditor]] 的协同关系已记录（审计触发查询分析需求） + +## [2026-05-05] ingest | Paid Media Auditor Agent +- Source file: Agent/agency-agents/paid-media/paid-media-auditor.md +- Status: ✅ 成功摄入 +- Summary: 企业级付费媒体账户审计 Agent——系统化评估 Google Ads、Microsoft Ads 和 Meta Ads 账户，覆盖 200+ 检查点（账号结构/追踪配置/竞价策略/创意/受众/竞争定位），每项发现附严重程度和预估业务影响。核心能力：8 大审计维度（账号结构/追踪/竞价/关键词/创意/Shopping/竞争定位/Landing Page）+ 历史趋势分析 + 合规审计。核心理念：像审计财务报表一样审计广告账户，不遗漏任何设置、假设和每一分钱。成功指标：审计通常识别 15-30% 效率提升机会，80%+ 高优先级建议 30 天内落地。 +- Concepts linked: [[AccountAudit]], [[ConversionTracking]], [[AttributionModeling]], [[BidStrategy]], [[QualityScore]], [[NegativeKeywordManagement]], [[AuctionInsights]], [[Dayparting]], [[ResponsiveSearchAds]], [[ProductFeedOptimization]], [[LandingPageAudit]], [[CompetitivePositioning]] +- Entities linked: [[JohnWilliams]], [[GoogleAds]], [[MicrosoftAdvertising]], [[AmazonAds]], [[GA4]], [[GTM]] +- Source page: wiki/sources/paid-media-auditor.md +- Notes: index.md 已替换占位符条目（2026-04-20 → 2026-05-05）；overview.md 已更新 paid-media-auditor 条目，补充 200+ 检查点框架和成功指标；所有 Entity/Concept 均仅出现 1 次，不足独立建页阈值（≥2 次），以 wikilink 形式记录于 Source page；与 [[paid-media-ppc-strategist]]（架构即战略 vs 现状审计）和 [[paid-media-programmatic-buyer]]（下漏斗 vs 上漏斗指标）的互补张力已记录于 Contradictions 节 + +## [2026-05-05] ingest | Paid Media PPC Campaign Strategist Agent +- Source file: Agent/agency-agents/paid-media/paid-media-ppc-strategist.md +- Status: ✅ 成功摄入 +- Summary: 企业级付费搜索与效果媒体策略 Agent——由 John Williams（@itallstartedwithaidea）设计，专注 Google Ads、Microsoft Advertising、Amazon Ads 三大平台。核心能力：分层活动架构（品牌/非品牌/竞品/征服）、Smart Bidding（tCPA/tROAS/Max Conversions/Max CV）、Performance Max 资产组设计、Google Ads API 自动化、MCC 级策略、增量测试框架。核心理念：账户架构即战略——活动/广告组/受众/信号系统协同驱动业务成果。成功指标：品牌展示份额 90%+、非品牌 40-60%、QS 7+ 占比 70%+、日预算消耗率 95-100%、季度转化量增长 15-25%。 +- Concepts created: [[PerformanceMax]], [[SmartBidding]], [[AccountArchitecture]], [[TieredCampaignArchitecture]], [[IncrementalityTesting]], [[ConversionActionHierarchy]], [[CustomerMatch]], [[BudgetPacing]] +- Entities created: [[GoogleAds]], [[MicrosoftAdvertising]], [[AmazonAds]], [[JohnWilliams]] +- Source page: wiki/sources/paid-media-ppc-strategist.md +- Notes: index.md 已新增 Sources 条目；Entities（4个）和 Concepts（8个）均已创建并添加到 index.md；overview.md 已新增 "The Agency — Paid Media 部门" 章节，整合了所有 Paid Media Agent 的协同关系；冲突已识别并记录：与 [[paid-media-programmatic-buyer]] 在预算分配方向上存在张力（高意图搜索流量 vs 品牌曝光），记录于 Source Page Contradictions 部分 + +## [2026-05-05] ingest | Paid Media Programmatic & Display Buyer Agent +- Source file: Agent/agency-agents/paid-media/paid-media-programmatic-buyer.md +- Status: ✅ 成功摄入 +- Summary: 战略性程序化购买与展示广告 Agent——覆盖 Google Display Network、DV360、The Trade Desk、Amazon DSP 等 DSP 平台，支持 Demandbase/6Sense/RollWorks ABM 展示广告策略，管理 25+ 合作伙伴媒体 AMP 计划。以受众优先为核心（正确的人在正确的上下文以正确的频次触达），强调可见性（70%+ MRC 标准）、品牌安全（IVT <3%）、频次管理（3-7 次/月）。通过 MCP 工具与 Google Ads API 集成实现自动化：placement 性能报告拉取、GDN 广告位排除、跨账户审计自动化。 +- Concepts linked: [[Programmatic Buying]], [[ABM Display]], [[Viewability]], [[Invalid Traffic]], [[Frequency Cap]], [[Supply Path Optimization]], [[Partner Media AMP]], [[MRC Standard]], [[CTV/OTT Advertising]], [[Brand Lift Measurement]] +- Entities linked: [[DV360]], [[The Trade Desk]], [[Amazon DSP]], [[Google Display Network]], [[Demandbase]], [[6Sense]], [[RollWorks]], [[John Williams]] +- Source page: wiki/sources/paid-media-programmatic-buyer.md +- Notes: index.md 已插入新条目至 paid-media-paid-social-strategist 之前；Entity/Concept 均未达到独立建页阈值（N=1）；冲突已识别并记录：与 paid-media-paid-social-strategist 在效果衡量指标上的差异（展示广告看上漏斗指标 vs 社交广告看直接转化指标） + +## [2026-05-05] ingest | Visual Storyteller Agent +- Source file: Agent/agency-agents/design/design-visual-storyteller.md +- Status: ✅ 成功摄入 +- Summary: Visual Storyteller Agent 角色定义——视觉叙事与品牌故事创作专家智能体，专注于将复杂信息转化为引人入胜的视觉叙事内容，驱动情感共鸣和用户参与。核心交付物：叙事弧创作（Beginning-Middle-End 三幕结构）、情感旅程映射、数据可视化叙事、跨平台视觉策略（Instagram/TikTok/YouTube/LinkedIn/Pinterest）。核心原则：叙事结构优先、情感驱动、品牌一致性（95%+触点）、WCAG 可访问性标准。成功指标：参与度提升 50%+、故事完成率 80%、品牌认知度提升 35%、视觉内容表现优于纯文本 3x。与 [[design-brand-guardian]] 互补（品牌叙事体系 vs 具体视觉内容），与 [[design-inclusive-visuals-specialist]] 协同（包容性视觉融入叙事），与 [[UX-Researcher]] 协同（用户洞察驱动情感旅程），与 [[design-whimsy-injector]] 互补（宏观叙事弧 vs 微交互趣味），共同为 [[LuxuryDeveloper]] 提供完整的品牌体验设计支撑。 +- Concepts linked: [[Story-Arc-Creation]], [[Emotional-Journey-Mapping]], [[Data-Storytelling]], [[Cross-Platform-Adaptation]], [[Motion-Graphics]], [[Visual-Pacing]], [[Progressive-Disclosure]], [[Brand-Narrative-Strategy]] +- Entities linked: [[Visual-Storyteller-Agent]], [[The-Agency]], [[LuxuryDeveloper]] +- Source page: wiki/sources/design-visual-storyteller.md +- Notes: index.md 已替换占位符条目（2026-04-20 → 2026-05-05）；overview.md 已新增独立段落（置于 design-whimsy-injector 和 design-image-prompt-engineer 之间）；无新 Entity/Concept 需创建（所有概念均为方法论术语，不足独立建页阈值）；无内容冲突检测到 + +## [2026-05-05] ingest | UI Designer Agent Personality +- Source file: Agent/agency-agents/design/design-ui-designer.md +- Status: ✅ 成功摄入 +- Summary: UI Designer Agent 角色定义——视觉界面设计专家智能体，专注于视觉设计系统、组件库和像素级界面交付。核心交付物：设计令牌系统（CSS 变量管理颜色/字体/间距/阴影/过渡）、响应式设计框架（Mobile-first，4个断点 640/768/1024/1280px）、可访问性标准（WCAG AA，色彩对比度 4.5:1）、组件文档与设计 QA 流程。核心理念：Design System First（先建组件基础再创建界面）、Accessibility Built-In（从架构层面内置无障碍）、Developer Handoff（详细规格实现 90%+ 准确率）。与 [[design-brand-guardian]] 互补（品牌身份 vs 视觉执行），与 [[design-whimsy-injector]] 存在张力——前者追求 95%+ 视觉一致性，后者在规范内注入趣味元素，通过预定义可配置槽位协调。与 [[ArchitectUX]]（技术架构）和 [[UX-Researcher]]（用户研究）协同，构成 [[The Agency]] 设计部门完整设计支撑体系。 +- Concepts linked: [[Design-System]], [[Design-Tokens]], [[Visual-Hierarchy]], [[Responsive-Design]], [[WCAG-AA]], [[Component-Library]], [[Dark-Mode]], [[Design-QA]], [[Accessibility-First-Design]] +- Entities linked: [[The Agency]], [[ArchitectUX]], [[design-brand-guardian]], [[design-whimsy-injector]], [[UX-Researcher]], [[LuxuryDeveloper]] +- Source page: wiki/sources/design-ui-designer.md +- Notes: index.md 已新增 Sources 条目（置于 design-brand-guardian 之前）；overview.md 已新增独立段落并替换原有 design-ux-architect 条目，新增 design-brand-guardian 条目，调整各 Agent 描述使其更准确；无新 Entity/Concept 需创建（Design-System/WCAG/Component-Library 等概念均在 Agency Agent 系统上下文中以方法论形式出现，不足独立建页阈值）；与 [[design-whimsy-injector]] 存在一致性与趣味性的张力，已记录于 Contradictions 部分——通过预定义可配置槽位协调（如微交互动画） + +## [2026-05-05] ingest | Design Brand Guardian +- Source file: Agent/agency-agents/design/design-brand-guardian.md +- Status: ✅ 成功摄入 +- Summary: Brand Guardian Agent 角色定义——品牌战略与身份守护专家智能体，负责创建 cohesive 品牌体系、确保跨所有触点的品牌表达一致性、并通过品牌保护策略维护品牌价值。核心交付物：品牌战略框架（Purpose/Vision/Mission/Values/Personality 五要素）、视觉身份系统（CSS 变量定义的品牌色彩/字体/间距/Logo 变体）、品牌声音指南、品牌保护策略。核心原则：Brand-First（先建品牌基础再战术执行）、一致性优先（95%+ 触点保持一致）、战略性演进（随市场变化成长而不失核心身份）。与 [[design-whimsy-injector]] 互补（Brand Guardian 建边界，Whimsy Injector 在边界内注入个性），共同为 [[LuxuryDeveloper]] 提供完整品牌体验设计。与 [[ArchitectUX]]（技术架构）和 [[UX-Researcher]]（用户研究）协同，构成 [[The Agency]] 设计部门完整设计支撑体系。 +- Concepts linked: [[Brand-Strategy]], [[Visual-Identity-System]], [[Brand-Voice-Guidelines]], [[Brand-Protection-Strategy]] +- Entities linked: [[The Agency]], [[ArchitectUX]], [[design-whimsy-injector]], [[UX-Researcher]], [[LuxuryDeveloper]] +- Source page: wiki/sources/design-brand-guardian.md +- Notes: index.md 已替换占位符条目；overview.md 已新增独立段落（置于 design-whimsy-injector 和 multi-agent-system-reliability 之间）；无新 Entity/Concept 需创建（Brand-Strategy/Visual-Identity-System/Brand-Voice-Guidelines/Brand-Protection-Strategy 及 ArchitectUX/LuxuryDeveloper 仅出现 1 次，不足建页阈值）；与 [[design-whimsy-injector]] 存在品牌一致性与创意表达的张力，已记录于 Contradictions 部分——两者互补而非互斥 + +## [2026-04-24] ingest | Inclusive Visuals Specialist +- Source file: Agent/agency-agents/design/design-inclusive-visuals-specialist.md +- Status: ✅ 成功摄入 +- Summary: Inclusive Visuals Specialist Agent 角色定义——包容性视觉表征专家智能体，专门对抗 AI 图像/视频生成模型（Midjourney、Sora、Runway Gen-3、DALL-E）中内嵌的系统性刻板印象偏见，生成具有文化真实性、尊严感和无歧视性的人类视觉表征。核心挑战：克隆脸（Clone Faces）、异域化偏见（Exoticism Bias）、文化符号乱码、地理/建筑失真。核心技术：结构化提示词架构（Subject → Sub-actions → Context → Camera Spec → Color Grade → Explicit Exclusions）+ 负向提示库 + 视频物理学定义。四阶段工作流：Brief Intake → Annotation Framework → Video Physics Definition → 7-Point QA Review Gate。成功指标：表征准确度 100%、AI 伪影消除率 100%、社区验证认可。 +- Concepts created: [[InclusiveVisuals]], [[NegativePromptingLibrary]] +- Concepts linked: [[IntersectionalRepresentation]], [[CommunityValidation]], [[AIArtifactElimination]], [[PromptEngineering]] +- Entities linked: [[TheAgency]], [[Midjourney]], [[Sora]], [[Runway-Gen-3]], [[DALL-E]], [[InclusiveVisualsSpecialist]] +- Source page: wiki/sources/design-inclusive-visuals-specialist.md +- Notes: index.md 已替换占位符条目（2026-04-20 → 2026-04-24）；overview.md 已新增 InclusiveVisualsSpecialist 独立段落（置于 design-image-prompt-engineer 和 design-brand-guardian 之间）；新增 Concept 页面 [[InclusiveVisuals]] 和 [[NegativePromptingLibrary]]；与 [[design-image-prompt-engineer]] 互补（摄影美学精准度 vs 消除表征偏见），与 [[design-whimsy-injector]] 存在张力——Kumbaya 库存照片套路和表演性象征主义是包容性设计必须坚决拒绝的 + +## [2026-04-24] ingest | UX Researcher Agent Personality +- Source file: Agent/agency-agents/design/design-ux-researcher.md +- Status: ✅ 成功摄入 +- Summary: UX Researcher Agent 角色定义——用户体验研究专家智能体，通过定性和定量研究方法验证设计决策。核心交付物：用户画像模板、用户旅程映射、可用性测试协议、A/B 测试框架。核心理念：研究方法论优先、证据优先沟通、研究推荐 80%+ 实施率。与 [[ArchitectUX]]（技术架构）和 [[design-whimsy-injector]]（品牌趣味）协同，共同为 [[LuxuryDeveloper]] 提供完整的用户中心设计支撑。 +- Concepts linked: [[Mixed-Methods Research]], [[Usability Testing]], [[User Persona]], [[User Journey Mapping]], [[Triangulation]], [[A/B Testing]], [[Accessibility Research]], [[Behavioral Analytics]], [[Research Repository]] +- Entities linked: [[Design Teams]], [[Product Teams]], [[Stakeholders]], [[The Agency]] +- Source page: wiki/sources/design-ux-researcher.md +- Notes: index.md 已新增 Sources 条目；overview.md 已新增独立段落（Multi-Agent AI Systems 主题下，置于 design-whimsy-injector 之前）；无新 Entity/Concept 需创建（大多数概念和实体在源文档中出现次数不足建页阈值）；与 [[design-whimsy-injector]] 存在设计理性与创意表达的互补张力，已记录于 Contradictions 部分 + +## [2026-05-05] ingest | Design Whimsy Injector +- Source file: Agent/agency-agents/design/design-whimsy-injector.md +- Status: ✅ 成功摄入 +- Summary: Whimsy Injector Agent 角色定义——品牌个性化和愉悦感注入专家，通过战略趣味设计为品牌体验增添个性、微交互和游戏化元素。核心交付物：品牌个性框架（专业/休闲/错误/成功四种场景人格光谱）、Whimsy 分类学（微妙/交互/发现/情境四类趣味）、微交互设计系统（CSS 动画 + 彩蛋 + 成就系统）。核心理念：有目的的趣味 + 包容性愉悦设计。与 [[ArchitectUX]] 互补，共同为 [[LuxuryDeveloper]] 提供完整品牌体验设计。 +- Concepts linked: [[Whimsy-Injector]], [[Micro-Interaction-Design]], [[Gamification-System]], [[Inclusive-Delight-Design]] +- Entities linked: [[ArchitectUX]], [[LuxuryDeveloper]], [[The Agency]] +- Source page: wiki/sources/design-whimsy-injector.md +- Notes: index.md 已替换占位符条目；overview.md 已新增独立段落（置于 design-ux-architect 和 multi-agent-system-reliability 之间）；无新 Entity/Concept 需创建（ArchitectUX/LuxuryDeveloper/Micro-Interaction-Design 等仅出现 1 次，不足建页阈值）；无内容冲突 + +## [2026-05-05] ingest | Contributing to The Agency +- Source file: Agent/agency-agents/CONTRIBUTING.md +- Status: ✅ 成功摄入 +- Summary: The Agency 多智能体框架贡献者指南英文原版——涵盖 Code of Conduct、四大贡献方式（创建智能体/优化现有/分享案例/报告问题）、智能体设计模板（YAML frontmatter + 结构化文档）、五大设计原则（鲜明性格/明确交付物/可量化指标/验证工作流/学习记忆）、PR 流程规范（单文件优先/Discussion 前置/提交前检查）、代码风格指南。 +- Concepts linked: [[Agent-Design-Principles]], [[Agent-Template]], [[Multi-Agent-Team]], [[Multi-Agent-System-Reliability]] +- Entities linked: [[The Agency]], [[OpenClaw]], [[msitarzewski]] +- Source page: wiki/sources/contributing.md +- Notes: index.md 已替换占位符条目；overview.md 已更新 contributing_zh-cn 条目，补充英文原版 wikilink；无新 Entity 需创建（msitarzewski/The Agency 仅出现 1 次，不足建页阈值）；无实质内容冲突，与 contributing_zh-cn 差异属语言版本差异 + +## [2026-05-05] ingest | 为 The Agency 贡献代码 +- Source file: Agent/agency-agents/CONTRIBUTING_zh-CN.md +- Status: ✅ 成功摄入 +- Summary: The Agency 项目（agency-agents）贡献者指南，定义智能体设计规范、贡献流程和社区标准。核心贡献方式：创建全新智能体（8大分类）、优化现有智能体、分享成功案例、反馈问题。智能体设计五原则：鲜明性格、明确交付物、可量化指标、经过验证的工作流、学习记忆。PR 流程含提交前检查（真实场景测试、遵循模板、补充示例）、社区评审与迭代优化。 +- Concepts created: [[Agent-Design-Principles]], [[Agent-Template]] +- Entities created: none（The Agency 已在 Wiki 中存在引用，无需新建 Entity 页面） +- Concepts linked: [[Multi-Agent-System-Reliability]], [[Multi-Agent-Team]] +- Source page: wiki/sources/contributing_zh-cn.md +- Notes: index.md 已新增 Sources 条目；overview.md 已新增独立段落（Multi-Agent AI Systems 主题下，置于 multi-channel-assistant 之前）；Agent-Design-Principles 和 Agent-Template 为新创建 Concept 页面；无 Entity 需创建；无冲突内容 + +## [2026-05-05] ingest | CTP Topic 12 Using SES SMTP service terraform module +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/ctp-topic-12-using-ses-smtp-service-terraform-module.md +- Status: ✅ 成功摄入 +- Summary: Christian Deckelmann 和 Filos Christolakis 主讲，Micro Focus 团队通过 Terraform 模块自动化部署 AWS SES SMTP 服务以替代传统本地 SMTP 网关——SES 是网络安全部门唯一批准的云端邮件发送方案；Terraform 模块封装 SMTP 终端节点配置，支持现有应用程序通过标准 SMTP 协议集成；VPC 端点私有连接 + IAM 用户凭证转 SMTP 认证信息存储于 Secrets Manager；自动化 DKIM 验证和 Infoblox DNS 记录创建；两个手动步骤（脱离 Sandbox Mode + 手动更新 DNS TXT 记录）；未来计划收件人限制和凭证滚动更新。 +- Concepts created: [[VPC-Endpoint]], [[DKIM-Email-Authentication]], [[SES-Sandbox-Mode]] +- Entities created: none（Christian Deckelmann、Filos Christolakis、Infoblox 出现频次不足建页阈值，以 wikilink 形式记录于 Source page） +- Concepts linked: [[Infrastructure-as-Code]], [[Secrets-Management]] +- Source page: wiki/sources/ctp-topic-12-using-ses-smtp-service-terraform-module.md +- Notes: index.md 已替换占位符条目（日期 2026-04-14）；overview.md 已新增独立段落（Terraform 段落末尾，置于 RDS via Terraform 和 Topic 21 之间）；VPC-Endpoint/DKIM-Email-Authentication/SES-Sandbox-Mode 为新创建 Concept 页面；Secrets-Management 已存在，已建立 wikilink；无其他 Entity 需创建 +- Conflicts: 与 [[ctp-topic-36-sendgrid-as-an-email-service]] 在邮件服务选型上的差异——SendGrid 被选定为新标准云邮件服务，SES 则服务现有应用通过 SMTP 协议平滑迁移上云，两者互补而非互斥 + +## [2026-05-05] ingest | design-ux-architect +- Source file: Agent/agency-agents/design/design-ux-architect.md +- Status: ✅ 成功摄入 +- Summary: ArchitectUX 智能体角色定义——为 LuxuryDeveloper 提供坚实的技术架构和 UX 基础。核心交付物：CSS 设计系统（颜色/排版/间距令牌，light/dark/system 三模式）、响应式布局框架（Grid/Flexbox/mobile-first）、ThemeManager JS 类、信息架构规范。核心原则：Foundation-First 和消除开发者架构决策疲劳。所有新站点强制要求主题切换功能。 +- Concepts linked: none（CSS 设计系统/ThemeManager 等属单一来源概念，以 wikilink 形式记录于 Source page，不足建 Concept 页阈值） +- Entities linked: [[ArchitectUX]], [[LuxuryDeveloper]], [[The Agency]] +- Source page: wiki/sources/design-ux-architect.md +- Notes: index.md 已替换占位符条目；overview.md 已新增独立段落（置于 multi-agent-system-reliability 之前）；无新 Entity/Concept 需创建（ArchitectUX/LuxuryDeveloper 仅出现 1 次，不足建 Entity 页阈值）；无实质内容冲突 + +## [2026-05-05] ingest | Learning Sessions Cloud Transformation Programme-20230808 183322-Meeting Recording +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi.md +- Status: ✅ 成功摄入 +- Summary: JP 和 Raja M 主讲，CTP/SRE 团队通过 Terraform IaC 实现 ECS 容器化应用自动化部署——基于 Gruntwork 仓库构建 ECS 模块，支持 Docker 容器/EC2 部署；核心功能：自动扩缩容、自动故障恢复、金丝雀部署；Listener 集中管理方式；前置条件：VPC/ELB 安全组/EFS 卷挂载；集成 CloudWatch/Splunk/Grafana/Prometheus。ECS 作为 AWS 原生技术与 AWS 服务深度集成。 +- Concepts linked: [[Infrastructure-as-Code]], [[Canary-Deployment]], [[ECS-Module]] +- Entities linked: [[Gruntwork]], [[AWS]], [[Cloud-Transformation-Programme]] +- Source page: wiki/sources/learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi.md +- Notes: index.md 已替换占位符条目；overview.md 已新增同主题 wikilink；JP 和 Raja M 各出现 1 次，不足独立 Entity 建页阈值，以 wikilink 形式记录于 Source page；无实质性内容冲突，ECS vs EKS 选型差异记录于 Contradictions 节 +- Conflicts: 与 [[ctp-topic-64-scaling-out-with-amazon-eks]] 在容器编排选型上的差异——ECS 强调 AWS 原生集成，EKS 强调可移植性，两者适用于不同场景但可互补 + +## [2026-05-05] ingest | CTP Topic 16 Cross-account Terraform modules +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/ctp-topic-16-cross-account-terraform-modules.md +- Status: ✅ 成功摄入 +- Summary: Fibos 主讲，多账号 AWS 环境中跨账号 Terraform 模块的中心化部署方案——基于 Shared Account（共享账号）作为中转站，Jenkins + ECS Deploy Runner + Assume Role 三联动。核心机制：Jenkins 检测 `cross-account.json` 标记文件触发 ECS Deploy Runner，通过 Assume Role 访问目标账号的 TF state bucket accessor 和 cross-account ECS deploy runner role。三大目标：安全性（无 Workload 账号间直接信任）、自动化（Jenkins 自动识别模块类型）、可复用性（模块代码不硬编码特定账号角色）。 +- Concepts created: [[Cross-account-Terraform-Modules]] +- Entities created: none（Gruntwork 已存在） +- Source page: wiki/sources/ctp-topic-16-cross-account-terraform-modules.md +- Notes: index.md 已替换占位符条目；overview.md 已新增独立段落（置于 ECS Deployment 和 Topic 21 之间）；Entity Jenkins/Fibos 提及次数不足建页阈值，以 wikilink 形式记录于 Source page；无实质性内容冲突，演进关系记录于 Contradictions 节 + +## [2026-05-05] ingest | Learning Sessions ECS Deployment using IAC - 20230808 +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording.md +- Status: ✅ 成功摄入 +- Summary: JP 和 Raja M 主讲，CTP/SRE 团队通过 Terraform IaC 实现 ECS 容器化应用自动化部署——基于 Gruntwork 仓库构建 ECS 模块，支持 Docker 容器/EC2 部署；核心功能：自动扩缩容、自动故障恢复、金丝雀部署；Listener 集中管理方式；前置条件：VPC/ELB 安全组/EFS 卷挂载；集成 CloudWatch/Splunk/Grafana/Prometheus。ECS 作为 AWS 原生技术与 AWS 服务深度集成。 +- Concepts created: [[Canary-Deployment]], [[Infrastructure-as-Code]] +- Entities created: [[Gruntwork]] +- Source page: wiki/sources/learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording.md +- Notes: index.md 已替换占位符条目；overview.md 已新增独立段落（置于 Terraform 工具选型后）；ECS 与 EKS 选型冲突记录于 Contradictions 节；JP 和 Raja M 各出现 1 次，不足独立 Entity 建页阈值，以 wikilink 形式记录于 Source page；无其他内容冲突 +- Conflicts: 与 [[ctp-topic-64-scaling-out-with-amazon-eks]] 在容器编排选型上的差异——ECS 强调 AWS 原生集成，EKS 强调可移植性，两者适用于不同场景但可互补 + +## [2026-05-05] ingest | CTP Topic 48 Terraform vs Terragrunt +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/ctp-topic-48-terraform-vs-terragrunt.md +- Status: ✅ 成功摄入 +- Summary: Bob（AWS Solutions Architect）对比 Terraform 与 Terragrunt——Terraform（HashiCorp 出品）是云厂商无关的 Golang 应用，通过状态文件绑定期望状态与实际环境；Terragrunt 是轻量封装，贯彻 DRY 原则，管理 provider 和 remote_state 块减少跨环境重复声明。两者命令和语法高度一致，Terragrunt 通过减少硬编码优化大规模企业部署。辅助工具：Terraform Enterprise、Gruntwork、Atlantis、tfsec、Terratest +- Concepts created: [[DRY Principle]], [[State-File-Management]] +- Entities created: [[HashiCorp]], [[Terragrunt]], [[Atlantis]] +- Entities updated: [[Terraform]], [[Gruntwork]] +- Concepts updated: [[Infrastructure-as-Code]] +- Source page: wiki/sources/ctp-topic-48-terraform-vs-terragrunt.md +- Notes: 视频由 Gemini 摘要，原文状态为 "summarized (Gemini 摘要)"；来源 NAS 路径为 `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 48_ Terraform vs Terragrunt.mp4` + +## [2026-05-05] ingest | Public Cloud Learning Sessions (OpenText) - AI Use Cases - 20241126 160106 +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec.md +- Status: ✅ 成功摄入 +- Summary: AWS AI 专家 Stephen Frank 分享 Gen2 AI 发展驱动力（数据爆发+算力提升）、企业级 AI 应用场景（客户体验/洞察提取/流程自动化/内容生成）、AWS 三层产品战略（基础设施→Bedrock→AI 应用）、数据差异化策略（RAG/Fine-tuning/持续预训练）、Amazon Q 企业知识问答、负责任 AI 原则 +- Concepts linked: [[RAG]], [[Fine-Tuning]], [[Continued-Pre-Training]], [[Responsible-AI]] +- Entities linked: [[AWS]], [[Amazon-Bedrock]], [[Amazon-SageMaker]], [[Amazon-Q]], [[Stephen-Frank]] +- Source page: wiki/sources/public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec.md +- Notes: index.md 已替换占位符条目（日期修正为 2026-04-14）；overview.md 已新增独立段落（Serverless & AI 专题，置于提示工程后）；RAG/Fine-Tuning/Responsible-AI/Stephen-Frank/Amazon-Q/Amazon-SageMaker 在 wiki 中出现频次不足独立建页阈值，以 wikilink 形式记录于 Source page；无内容冲突 +- Conflicts: 无 + +## [2026-05-05] ingest | Public Cloud Learning Sessions (OpenText) - Event Driven Architecture Part 2 - 20240917 +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091.md +- Status: ✅ 成功摄入 +- Summary: EDA 进阶实践——三组件（事件生产者/消费者/代理）、事件路由器（EventBridge/SNS）与事件存储（SQS/Kinesis）、编排与编排模式（Choreography vs Orchestration）、幂等性、事件排序、去中心化团队所有权、Fan-out 模式、竞争消费者模式、死信队列、EventBridge 最佳实践 +- Concepts updated: [[Event-Driven-Architecture]]（补充 Part 2 内容：EDA 三组件、编排模式对比、生产级最佳实践：幂等性/事件排序/团队独立性、扩展 Event Patterns：Fan-Out/Competing Consumer/DLQ） +- Entities existing (no new): [[AWS]], [[Amazon-EventBridge]], [[Amazon-SQS]], [[Amazon-SNS]], [[AWS-Lambda]], [[AWS-Step-Functions]] +- Source page: wiki/sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091.md +- Notes: index.md 已替换占位符条目（日期修正为 2026-05-05）；overview.md 已添加 Part 2 独立段落（新增于 Serverless 段落和 Part 1 之间），同时更新 Part 1 引用指向 Part 2；Event-Driven-Architecture 概念页已更新 sources + last_updated，新增 EDA 三组件/编排模式/生产级最佳实践内容，扩展 Event Patterns；Kinesis-Data-Streams 出现 1 次，不足独立建 Entity 阈值，以 wikilink 形式记录于 Concept 页 +- Conflicts: 与 [[ctp-topic-64-scaling-out-with-amazon-eks]] 在扩展方式上的差异——EDA 通过事件驱动异步扩展（消费者按需处理），EKS 通过容器编排横向扩展（Pod 副本数调整），两者适用于不同场景但可互补使用 +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091.md +- Status: ✅ 成功摄入 +- Summary: EDA 入门——AWS 解决方案架构师 Dr. Anil Giri 介绍 EventBridge/SQS/SNS 事件驱动架构与 Enterprise Integration Patterns；会议因 Teams 屏幕共享故障仅完成开场介绍，完整演示参见 Part 2 +- Concepts linked: [[Event-Driven-Architecture]], [[Enterprise-Integration-Patterns]], [[Amazon-EventBridge]], [[Amazon-SQS]], [[Amazon-SNS]] +- Entities linked: [[Dr.-Anil-Giri]], [[AWS]], [[OpenText]], [[Micro-Focus]] +- Source page: wiki/sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091.md +- Notes: index.md 已替换占位符条目（日期修正为 2026-04-19）；overview.md 已补充（Serverless & AI 专题段落新增，置于无服务器计算后）；Dr. Anil Giri/AWS/OpenText/Micro Focus 在 wiki 中出现频次不足独立建 Entity 页阈值，以 wikilink 形式记录于 Source page；EventBridge/SQS/SNS/Enterprise-Integration-Patterns 概念频次不足独立建 Concept 页阈值；已建立与 Part 2（public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091）、无服务器计算（public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee）的 Connections 关系；冲突记录与 ctp-topic-64-scaling-out-with-amazon-eks 的扩展方式差异已记录于 Contradictions 节 +- Conflicts: 与 [[ctp-topic-64-scaling-out-with-amazon-eks]] 在扩展方式上的差异——EDA 通过事件驱动异步扩展，EKS 通过容器编排横向扩展，两者适用于不同场景但可互补使用 + +## [2026-05-05] ingest | Public Cloud Learning Sessions - Serverless Computing - 20240903 +- Status: ✅ 成功摄入 +- Summary: AWS 无服务器计算深度解析——Lambda 事件驱动模型（同步/异步/事件源映射）、Step Functions 状态机编排（Standard/Express）、API Gateway（边缘优化/区域/私有）、SAM 本地开发和部署；Serverless 业务价值（快速上市/按需付费/自动扩展/内置安全）；AWS 与客户共担运维责任 +- Entities created: [[AWS-Lambda]], [[AWS-Step-Functions]], [[Amazon-API-Gateway]], [[SAM-Serverless-Application-Model]] +- Concepts linked: [[Serverless-Computing]], [[Event-Driven-Architecture]] +- Source page: wiki/sources/public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee.md +- Notes: index.md 已更新（替换占位符条目，日期修正为 2026-04-14）；overview.md 已补充（Cloud Transformation & DevOps 章节新增独立段落，置于 AI/ML 入门与 CTP Topic 20 之间）；Entity 页均按字母顺序插入 index.md Entities 节；无内容冲突（Serverless-Computing 概念页已存在，内容一致） +- Conflicts: 无 + +## [2026-05-05] ingest | Public Cloud Learning Sessions - Introduction to AI/ML with AWS +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin.md +- Status: ✅ 成功摄入 +- Summary: AWS AI/ML 与生成式 AI 入门——AI 定义（复制人类智能任务的系统）、三类 AI（分类/预测/生成式 AI）、AWS 20 年 ML 积累、Amazon Bedrock 全托管服务（Titan 基础模型+微调+持续预训练+RAG+Agents+Guardrails）、SageMaker Canvas 无代码工具、ML Ops 数据/训练/推理三流水线 +- Concepts linked: [[RAG]], [[MLOps]], [[Foundation-Models]], [[Amazon-Bedrock]], [[Amazon-SageMaker-Canvas]], [[Responsible-AI]] +- Entities linked: [[AWS]], [[Amazon-Bedrock]], [[Amazon-Titan]] +- Source page: wiki/sources/public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin.md +- Notes: index.md 已更新（替换占位符条目）；overview.md 已补充（Cloud Transformation & DevOps 章节新增 Serverless & AI 专题段落，置于 FinOps 后）；Suraav Paul/AWS Senior Solutions Architect 仅出现 1 次，以 wikilink 形式记录于 Source page；RAG/MLOps/Responsible AI 频次不足独立建页阈值；本来源属于 Cloud Transformation Programme 的 Serverless & AI 专题（09_Serverless_AI）；无内容冲突 +- Conflicts: 无 + +## [2026-05-05] ingest | Cloud Learning Master Index +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/_Index/cloud-learning-master-index.md +- Status: ✅ 成功摄入 +- Summary: OpenText/微焦点云转型学习会话视频总索引——NAS 源 `/volume2/work/Public Cloud Learning Sessions/`，覆盖 10 大技术领域共 111 个视频：AWS Landing Zone（22）、OpenText Series（21）、EKS & Kubernetes（14）、Security（9）、Networking（9）、Serverless & AI（9）、FinOps & Cost（10）、CI/CD & GitOps（8）、IAM & Identity（3）、Terraform & IaC（6）。该索引是所有 CTP 专题视频的元数据入口。 +- Concepts created: 无（所有关键技术概念已通过其他来源创建独立页面；该索引为元数据文件，无需新建 Concept） +- Source page: wiki/sources/cloud-learning-master-index.md +- Notes: index.md 已更新（Sources 节新增条目置于顶部）；overview.md 已补充（Cloud Transformation & DevOps 章节新增 cloud-learning-master-index 段落）；CTP-Team 和 OpenText 以 wikilink 形式记录于 Source page（出现次数不足独立建页阈值）；Cloud-Transformation-Programme 已通过 Micro Focus Entity 页覆盖；无内容冲突 +- Conflicts: 无 + +## [2026-05-05] ingest | CTP Topic 27 AWS Instance Scheduler +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/ctp-topic-27-aws-instance-scheduler.md +- Status: ✅ 成功摄入 +- Summary: AWS Instance Scheduler 原生方案——通过 CloudFormation + CloudWatch Events（每15分钟）+ Lambda + DynamoDB 调度配置表，自动定时启停 EC2/RDS 实例；通过标签（Schedule/Period）关联调度规则；由 Guardrails 框架自动推送至公司月消费10美元以上账号；基于"时间表"而非"空闲率"触发；RDS 维护窗口智能协同；关机行为必须设为"停止"而非"终止" +- Concepts created: 无（所有概念仅出现 1 次，以 wikilink 形式记录于 Source page） +- Source page: wiki/sources/ctp-topic-27-aws-instance-scheduler.md +- Notes: index.md 已更新（替换占位符条目，日期修正为 2026-04-14）；overview.md 已补充（FinOps 章节新增段落，置于 ctp-topic-63 后）；已建立与 ctp-topic-13（政策框架）、ctp-topic-63（Terraform Scheduler 互补）、ctp-topic-71（RightSizing 互补）的 Connections 关系；冲突记录：与 ctp-topic-63 在实现路径上的差异（AWS 原生 vs Terraform 层）已于 Contradictions 节说明为互补而非互斥 +- Conflicts: 与 [[ctp-topic-63-optimise-resource-cost-using-automation]] 就 EC2/RDS 自动调度的实现路径差异——Instance Scheduler（AWS 原生方案）覆盖广账户层，Terraform Scheduler（IaC 层）提供细粒度控制，两者互补而非互斥 + +## [2026-04-25] ingest | CTP Topic 63 Optimise resource cost using automation +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/ctp-topic-63-optimise-resource-cost-using-automation.md +- Status: ✅ 成功摄入 +- Summary: 使用自动化手段优化 AWS 云资源成本——五大策略：批准区域标准化、Graviton ARM 实例选型（比 Intel 便宜 20-25%）、承诺计划（1年 40% / 3年 64% 折扣）、GP2→GP3 存储优化（节省 20%）、基于标签的 EC2/RDS 自动化调度（每天只运行 10 小时可节省 70% 成本） +- Concepts created: 无（已存在的 [[Savings-Plans]] 涵盖承诺计划；Graviton/RightSizing 等概念在本 wiki 中出现频次不足以独立建页） +- Source page: wiki/sources/ctp-topic-63-optimise-resource-cost-using-automation.md +- Notes: Pushka 演示 Terraform Scheduler 模块配置（`auto_shutdown = yes` 标签）；无内容冲突 + +## [2026-04-24] ingest | Public Cloud Learning Sessions - Best practices for EC2 cost optimization in AWS - 20240529 +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/public-cloud-learning-sessions-best-practices-for-ec2-cost-optimization-in-aws-2.md +- Status: ✅ 成功摄入 +- Summary: Mike Dukes 和 Steele Taylor（AWS 专家）主讲 EC2 成本优化最佳实践——AWS Nitro 系统外部化网络/存储/安全组件提升效率；Graviton ARM 处理器基于 ARM64 架构，提供 40% 性价比提升，功耗减少 60%；EC2 Spot 实例利用闲置容量提供 90% 折扣；购买选项包括 On-Demand/Savings Plans/Spot Instances；Spot Invaders 游戏展示容错混沌工程实践；Spot + Graviton + 容器组合实现最大化成本节省 +- Concepts created: [[Nitro-System]], [[EC2-Purchase-Options]] +- Concepts linked: [[Graviton]], [[Spot Instances]], [[Savings Plans]], [[FinOps]], [[Cloud Cost Optimization]] +- Entities identified: Mike Dukes 和 Steele Taylor 为演讲者，但提及次数不足 2 次，以 wikilink 形式记录于 Source page +- Source page: wiki/sources/public-cloud-learning-sessions-best-practices-for-ec2-cost-optimization-in-aws-2.md +- Notes: index.md 已更新（Sources 节新增条目）；overview.md 已补充（FinOps 章节新增段落，置于 ctp-topic-13 后）；Nitro-System 和 EC2-Purchase-Options 不存在于现有 Wiki，新建 Concept 页面；已建立与 public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco、ctp-topic-13-cloud-finops-policies 的 Connections 关系 +- Conflicts: 与 ctp-topic-14-octane-hub-on-aws 可能的冲突（Graviton 对有状态服务的适用性），已记录于 Source page Contradictions 节 + +## [2026-04-25] ingest | Public Cloud Learning Sessions - Storage Cost Optimization - 20240305 +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/public-cloud-learning-sessions-storage-cost-optimization-20240305-160037-meeting.md +- Status: ✅ 成功摄入 +- Summary: AWS EBS（GP3 20% 节省+独立扩展 IOPS/吞吐）、EFS/FSx（生命周期分层）、S3（Intelligent Tiering 自动冷热迁移+生命周期策略+PrivateLink 规避数据传输费）、ADM 三阶段迁移案例（OpenZFS → 自管理 NetApp on EC2 → FSx for NetApp ONTAP 实现 60% 成本削减） +- Concepts linked: [[EBS-GP3]], [[EBS-Snapshot-Archive]], [[Data-Lifecycle-Manager]], [[AWS-Backup]], [[EFS-Infrequent-Access]], [[S3-Intelligent-Tiering]], [[S3-Lifecycle-Policies]], [[FSx-for-NetApp-ONTAP]], [[AWS-PrivateLink]], [[FinOps]], [[Cloud Cost Optimization]] +- Entities linked: [[AWS]], [[ADM]] +- Source page: wiki/sources/public-cloud-learning-sessions-storage-cost-optimization-20240305-160037-meeting.md +- Notes: index.md 已更新（Sources 节新增条目，置于 ctp-topic-71 前）；overview.md 已补充（FinOps 章节新增存储成本优化专题段落）；ADM 提及仅 1 次，以 wikilink 形式记录于 Source page；所有 AWS 服务特性概念（EBS-GP3/Snapshot-Archive/EFS-IA/S3-IntelligentTiering 等）已记录于 Source page Key Concepts 节，暂不单独建页；已建立与 public-cloud-learning-sessions-reducing-cloud-costs-20250318、ctp-topic-13-cloud-finops-policies 的 Connections 关系 +- Conflicts: 与 ctp-topic-14-octane-hub-on-aws 可能的 EFS vs EBS 选型冲突，已记录于 Source page Contradictions 节 + +## [2026-04-25] ingest | Public Cloud Learning Sessions - Reducing Cloud Costs - 20250318 +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco.md +- Status: ✅ 成功摄入 +- Summary: Vinay（FinOps）主讲 AWS 云成本优化——工作负载优化（现代化：EC2 新代际/Graviton 20-25% 节省/AMD 6-10% 节省/GP2→GP3 存储 20% 节省/EKS 最新版避免扩展支持费/Spot 实例 90% 折扣）和 Right Sizing（EC2 Right Sizing 报告/实例调度/闲置资源清理）；费率优化（Savings Plans/RI 两种承诺类别 + 实施流程）；关键规则：承诺计划仅无预付选项，最低 $5k/年，仅 Phenops 团队实施 +- Concepts created: [[Savings-Plans]], [[Spot-Instances]] +- Concepts linked: [[Cloud Cost Optimization]], [[Graviton]], [[Right Sizing]], [[EKS Extended Support]], [[EDP (Enterprise Discount Program)]] +- Entities created: [[Vinay]], [[Phenops-Team]] +- Entities linked: [[AWS]] +- Source page: wiki/sources/public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco.md +- Notes: index.md 已更新（Sources 节新增条目，Entities 节新增 Phenops-Team 和 Vinay，Concepts 节新增 Savings-Plans 和 Spot-Instances）；overview.md 已补充（FinOps 章节新增段落，Key Entities 新增 Vinay 和 Phenops-Team）；Graviton/Spot-Instances/Savings-Plans 均满足 Concept 可复用条件，新建页面；Vinay 出现 ≥2 次新建 Entity，Phenops-Team 出现 ≥2 次新建 Entity；与 [[ctp-topic-13-cloud-finops-policies]] 构成政策层→技术实施层互补关系，已记录于 Connections；无内容冲突 +- Conflicts: 无 + +## [2026-04-25] ingest | CTP Topic 13 Cloud FinOps Micro Focus Policies best practices to optimize the costs +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co.md +- Status: ✅ 成功摄入 +- Summary: PCG 团队 Uday 和 Vinay 主讲 Cloud FinOps 成本优化政策与最佳实践；PCG 三层服务模型（成本管理→成本优化→治理与自动化）；5 大核心策略（账单可见性、标签合规、预算责任、Reserved Instances 集中管理、区域限制）；安全控制（Godrails/MFA/告警重定向）；Cloud Health 工具；标准化实例选型 + Graviton；研发环境三合一优化 +- Concepts identified: [[FinOps（云财务管理）]]（已存在）、[[Showback/Chargeback]]（已有引用） +- Entities identified: [[PCG]]（提及但 <2 次）、[[Cloud-Health]]（提及但 <2 次） +- Source page: wiki/sources/ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co.md +- Notes: PCG 和 Cloud Health 出现次数不足 2 次，不满足独立 Entity 页面创建条件，以 wikilink 形式记录于 Source page；index.md 已更新（替换 expected 条目为实际内容）；overview.md Cloud Transformation 章节已补充（置于 ctp-topic-65 后）；已建立与 ctp-topic-63（自动化调度优化）、ctp-topic-71（Rightsizing）、ctp-topic-27（AWS Instance Scheduler）的连接关系；FinOps 概念页已存在于 wiki/concepts/，无需新建 +- Conflicts: 与 [[ctp-topic-53-why-bother-with-cloud]] 存在视角差异：Topic 13 假设已在云上聚焦优化，Topic 53 聚焦是否应迁移的决策论证；已在 Source page Contradictions 节记录 + +## [2026-04-26] ingest | Public Cloud Learning Sessions - Budget Control - 20240319 +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/public-cloud-learning-sessions-budget-control-20240319-160204-meeting-recording.md +- Status: ✅ 成功摄入 +- Summary: SRE Core 团队（Daniela/Evan/Alan）分享 AWS Budget Control 自动化——解决账户蔓延导致的成本失控。核心架构：AWS Budget → SNS → Lambda → Step Functions → SCP Enforcement（服务控制策略封禁新资源创建）。4 类告警：Forecast/Actual 80-98%/Severe/Enforcement。Source Identity 通过 CloudTrail 追踪联邦登录跨角色切换的原始用户身份。初始范围仅限 Lab 账户。 +- Concepts created: [[AWS-Source-Identity]] +- Concepts linked: [[FinOps]], [[SCP-Enforcement]], [[CloudTrail]], [[Step-Functions]], [[Cost-Explorer]], [[AWS-Budget-Alerts]] +- Entities linked: [[SRE-Core-Team]], [[Phenops-Team]], [[NetIQ]] +- Source page: wiki/sources/public-cloud-learning-sessions-budget-control-20240319-160204-meeting-recording.md +- Notes: index.md 已更新（Sources 节新增条目，Concepts 节新增 AWS-Source-Identity）；overview.md 已补充（FinOps 章节新增段落，置于 reducing-cloud-costs-20250318 后）；AWS-Source-Identity 为 Source Identity 追踪机制的完整概念页，满足可复用条件；已建立与 ctp-topic-13（治理自动化政策层）、ctp-topic-63（主动优化）、reducing-cloud-costs-20250318（优化手段）的 Connections 关系；无内容冲突 + +## [2026-04-25] ingest | CTP Topic 15 Working with Renovatebot +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-15-working-with-renovatebot.md +- Status: ✅ 成功摄入 +- Summary: Paul Hopkins 主讲 Renovate Bot 自动化管理云原生基础设施依赖项更新；解决"依赖地狱"问题，实时扫描 Docker/Terraform/Terragrunt/pre-commit 版本标签并自动发起 Pull Request；通过 Dependency Dashboard 提供全局依赖状态视图；集成 Jenkins 流水线，使用 Podman 容器化运行并配置 Rate Limiting +- Concepts created: [[Renovate-Bot]], [[Dependency-Management]], [[Semantic-Versioning]] +- Source page: wiki/sources/ctp-topic-15-working-with-renovatebot.md +- Notes: Renovate-Bot 出现在 6 个以上来源中（index 有 416 行引用记录），满足 ≥2 次条件，创建独立 Concept 页面；Dependency-Management 和 Semantic-Versioning 作为支撑概念也一并创建；index.md 和 overview.md 均已更新；已建立与 ctp-topic-9（Gruntwork CI/CD）、ctp-topic-33（GitOps 入门）、ctp-topic-32（Atlantis CI/CD）的连接关系；Gruntwork 已有 Entity 页面（wiki/entities/Gruntwork.md），无需新建 +- Conflicts: （暂无） + +## [2026-04-24] ingest | Public Cloud Learning Sessions - Ollie Workflow and The Demand Process - 20240416 +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16.md +- Status: ✅ 成功摄入 +- Summary: Oli 工作流（超大规模云厂商支出审批三级工作流）+ 需求管理自动化端到端流程（ITIL 框架、Octane/Qixi 提交入口、主服务目录嵌入 SMACs、"机器做机器能做的事"理念） +- Concepts identified: [[Demand-Management]], [[ITIL-Service-Management]], [[FinOps]], [[SMACs]] +- Entities identified: [[Tom-Bice]], [[FPNA-Team]], [[MUI]], [[Shannon]], [[Octane]], [[Qixi]] +- Source page: wiki/sources/public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16.md +- Notes: entities 和 concepts 目录均为空（无历史页面）；未满足 ≥2 次出现条件，不新建独立页面，以 wikilink 形式记录于 Source page；index.md 已更新；overview.md Cloud Transformation 章节已补充（置于 ctp-topic-57 后）；已建立与 ctp-topic-57（Backlog 管理管道）、ctp-topic-65（价值量化）、public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109（需求分析前置技法）、ctp-topic-4（敏捷实践）的连接关系 +- Conflicts: （暂无） + +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-3-deploy-and-maintain-infrastructure.md +- Status: ✅ 成功摄入 +- Summary: Landing Zone 环境下通过 Terraform/Terragrunt 实现基础设施部署与维护的完整方法论；核心区分 Service Module（业务视角）与 Regular Module（技术视角）的分层抽象；Terragrunt HCL 版本锁定；Service Catalog 三级复用（单账户→产品团队→跨团队） +- Concepts identified: [[Service Module]], [[Service Catalog]], [[Terragrunt]], [[Infrastructure as Code]], [[Terraform Module]] +- Entities identified: [[Gruntwork]], [[AWS Landing Zone]] +- Source page: wiki/sources/ctp-topic-3-deploy-and-maintain-infrastructure.md +- Notes: 已建立与 ctp-topic-1（Gruntwork LZ 架构）、ctp-topic-9（CI/CD with Gruntwork）、ctp-topic-32（Atlantis CI/CD）、ctp-topic-33（GitOps 入门）、ctp-topic-39（EKS Atlantis 约束差异）的连接关系；Service Module/Service Catalog 仅出现 1 次，不满足 ≥2 次建页条件，以 wikilink 形式记录于 Source page；index.md 已更新；overview.md Cloud Transformation & DevOps 章节已更新 +- Conflicts: 与 [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]] 存在 Atlantis EKS 支持约束差异（Topic 3 通用原则 vs Topic 39 具体实践） + +## [2026-04-24] ingest | CTP Topic 9 CI CD with Gruntwork +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-9-ci-cd-with-gruntwork.md +- Status: ✅ 成功摄入 +- Summary: CTP Topic 9 CI/CD 与 Gruntwork 在 AWS Landing Zone 中的实践视频；源文档状态为"待 Whisper 转录"，基于文件元数据生成初始页面 +- Concepts identified: [[CI/CD Pipeline]], [[Infrastructure as Code]], [[Gruntwork]], [[Terraform]], [[Terragrunt]] +- Entities identified: [[Gruntwork]], [[AWS Landing Zone]], [[Cloud Transformation Programme]] +- Source page: wiki/sources/ctp-topic-9-ci-cd-with-gruntwork.md +- Notes: 源视频待转录，Key Claims/Key Quotes 为占位内容；已建立与 ctp-topic-1（Gruntwork LZ 架构）、ctp-topic-2（Git）、ctp-topic-33（GitOps 入门）、ctp-topic-32（Atlantis CI/CD）的连接关系；index.md 已更新；overview.md Cloud Transformation & DevOps 章节已更新；无需新建 Entity/Concept 页面 +- Conflicts: （暂无，待视频转录后补充） + +## [2026-04-14] ingest | CTP Topic 32 Using Atlantis CICD for Infrastructure Deployments +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments.md +- Status: ✅ 成功摄入 +- Summary: Atlantis 替代 Jenkins 用于 Terraform IaC 部署的 CTP 学习视频，涵盖 Atlantis 架构（单 EC2 + GitHub Webhook）、PR 评论式协作模型、跨账户 IAM 角色访问、并行构建、模块锁定机制 +- Concepts identified: [[GitOps]], [[Infrastructure-as-Code]], [[CI/CD Pipeline]], [[Terraform]] +- Source page: wiki/sources/ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments.md +- Notes: Source page 已创建；index.md 已更新（Sources 节顶部）；overview.md Cloud Transformation & DevOps 章节已更新；GitOps.md sources 列表已更新；已识别与 ctp-topic-39（EKS 不支持 Atlantis）的矛盾点并记录于 Contradictions 节 +- Conflicts: [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]]（Atlantis 不支持 EKS 部署 vs Atlantis 可替代 Jenkins 全面部署） + +## [2026-04-14] ingest | CTP Topic 2 Git +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-2-git.md +- Status: ✅ 成功摄入 +- Summary: CTP Topic 2 Git 版本控制系统基础与实践视频讲座，作为 CI/CD/GitOps 系列开篇；源文档状态为"待 Whisper 转录" +- Concepts identified: [[Git]], [[Version Control]], [[DevOps]] +- Entities identified: [[Cloud Transformation Programme]] +- Source page: wiki/sources/ctp-topic-2-git.md +- Notes: 源视频待转录，Key Claims/Key Quotes 为占位内容；已建立与 ctp-topic-9（CI/CD with Gruntwork）和 ctp-topic-33（GitOps 入门）的连接关系；index.md 已更新，overview.md Cloud Transformation & DevOps 章节已更新 + +## [2026-04-14] ingest | CTP Topic 24 Micro Focus Product Privacy Framework +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/ctp-topic-24-micro-focus-product-privacy-framework.md +- Status: ✅ 成功摄入 +- Summary: Micro Focus 产品隐私框架在云转型中的应用——PSAC 与法律顾问合作，将 GDPR/CCPA 等晦涩法律条款翻译为约 110 项低级别技术要求；隐私框架是 STLC（安全开发生命周期）中 13 个安全与隐私轨道之一；通过五类需求（架构类/文档类/法律类/实现类/SAS 运营类）和成熟度模型（0-4 级）评估产品隐私合规状态；通过"蜘蛛图"直观展示产品隐私 KPI 合规现状 +- Concepts identified: [[Product Privacy Framework（产品隐私框架）]], [[STLC（Security Development Life Cycle）]], [[PSAC（Product Security Advisory Committee）]], [[PII（Personally Identifiable Information）]], [[Maturity Model（成熟度模型）]], [[Spider Chart（蜘蛛图）]], [[Product Privacy Settings Document]], [[Data Controller vs. Data Processor]], [[Anonymization & Pseudonymization]] +- Entities identified: [[Micro Focus]], [[Shlomi Ben-Hur]] +- Source page: wiki/sources/ctp-topic-24-micro-focus-product-privacy-framework.md +- Notes: 无冲突检测；CTP Topic 21 和 Topic 24 均由 Shlomi Ben-Hur 主讲，PSAC 作为产品安全顾问委员会在多个 topic 中出现，实体创建条件待后续评估；STLC 作为 SDLC 的安全扩展已有提及，本次独立建 Concept 页面；overview.md 已更新，新增条目和 Key Concepts/Entities + +## [2026-04-24] ingest | CTP Topic 49 Container Lifecycle Hardening Standards +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/ctp-topic-49-container-lifecycle-hardening-standards.md +- Status: ✅ 成功摄入 +- Summary: Micro Focus 产品安全小组 Ashish 主讲，容器镜像构建阶段 11 条安全加固标准——基础镜像选择、Init 系统（tini 防止僵尸进程）、只读根文件系统（readOnlyRootFilesystem: true）、emptyDir Volume、禁用 Kubernetes API 自动挂载（automountServiceAccountToken: false）、私有服务账号+RBAC、避免 hostNetwork/hostPort +- Concepts created: [[Container-Lifecycle-Hardening]], [[Pod-Security-Context]], [[emptyDir-Volume]] +- Entities created: [[Ashish]], [[Product-Security-Group]], [[tini]] +- Source page: wiki/sources/ctp-topic-49-container-lifecycle-hardening-standards.md +- Notes: 与 [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]] 就 hostNetwork 配置存在场景冲突（Topic 39 Lab 环境特例 vs Topic 49 通用最佳实践）；检测到 3 个潜在概念（Container-Lifecycle-Hardening/Pod-Security-Context/emptyDir-Volume）和 3 个实体（Ashish/Product-Security-Group/tini），均已创建 Entity/Concept 页面；overview.md 已更新 + +## [2026-04-14] ingest | CTP Topic 21 Supply Chain Security in Micro Focus +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/ctp-topic-21-supply-chain-security-in-micro-focus.md +- Status: ✅ 成功摄入 +- Summary: Micro Focus 软件供应链安全新方法——供应链（产品层面）涵盖 SCM/CI/CD 全环节；驱动因素：SolarWinds 攻击事件、美国网络安全行政命令、AWS/SaaS 迁移风险；安全观念转变：从 99% 关注研发安全转向全生命周期防护；供应链安全成为 SDL 第五支柱，强调 CI 和 CD 过程完整性 +- Concepts identified: [[Supply Chain Security（供应链安全）]], [[SolarWinds Hack]], [[CI/CD Security]], [[SDL（Security Development Lifecycle）]], [[Executive Order on Cybersecurity]], [[Lateral Movement]] +- Entities identified: [[Micro Focus]], [[Shlomi Ben-Hur]] +- Source page: wiki/sources/ctp-topic-21-supply-chain-security-in-micro-focus.md +- Notes: 无冲突检测；Micro Focus 已在多处来源提及但无独立 Entity 页面，本次补充创建；SolarWinds/Shlomi Ben-Hur 仅出现一次，不满足 Entity 创建条件 + +## [2026-04-24] ingest | CTP Topic 52 3 Lines of Defence (3LoD) Framework Cloud Security Posture Management +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/ctp-topic-52-3-lines-of-defence-3lod-framework-cloud-security-posture-management.md +- Status: ✅ 成功摄入 +- Summary: 3LoD 安全治理框架落地（业务单元→集团职能部门→审计三层责任分层）+ Cloud Guard CSPM 工具选型（态势管理/资产管理/网络可视化/事件管理/威胁情报）+ 新账户创建流程中自动纳入 Cloud Guard +- Concepts identified: [[Three Lines of Defence（3LoD）]], [[Cloud Security Posture Management（CSPM）]] +- Source page: wiki/sources/ctp-topic-52-3-lines-of-defence-3lod-framework-cloud-security-posture-management.md +- Notes: 无冲突内容；3LoD/CSPM 均属行业通用概念，已有 CSPM 相关内容于 cloud-security.md；Cloud Guard 为该组织专用 CSPM 工具，暂不单独建 Entity 页面 + +## [2026-04-24] ingest | CTP Topic 55 AWS Firewall Manager +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/ctp-topic-55-aws-firewall-manager.md +- Status: ✅ 成功摄入 +- Summary: AWS Firewall Manager 在 Grand Torque 多 Landing Zone 环境中的集中化安全策略管理实践——跨 RLABS/R&D/SAS/CAT 多个 Landing Zone 统一部署基线安全组；三种策略类型（通用/审计强制/清理冗余）；通过 AWS Config + Lambda 实现自动修复；RAM 前缀列表跨账户共享规则；独立 Firewall Manager 账户支持跨 LZ 部署；Demo 展示 EC2 实例安全组的自动附加与移除 +- Concepts identified: [[Security-Group]], [[Prefix-List]], [[Auto-Remediation]], [[WAF-Rules-Management]] +- Entities identified: [[AWS-Firewall-Manager]], [[Landing-Zones]], [[QALIS]], [[Checkpoint-Firewall]] +- Source page: wiki/sources/ctp-topic-55-aws-firewall-manager.md +- Notes: 无冲突检测；与 [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] 中的 Checkpoint 方案属互补关系（网络边界防火墙 vs 实例级安全组基线），已于 Contradictions 节记录 + +## [2026-04-30] ingest | CTP Topic 37 Secrets Certificates Management +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/ctp-topic-37-secrets-certificates-management.md +- Status: ✅ 成功摄入 +- Summary: 云转型计划密钥与证书管理解决方案选型与实施——30天试点对比 AWS Secrets Manager 与 HashiCorp Vault，AWS Secrets Manager 以更低成本和更简实施胜出；实施阶段从 Control Tower 开始，从 CI/CD 流程清除明文密钥，集中化管理。 +- Concepts identified: [[Secrets-Management]], [[AWS-Secrets-Manager]] +- Entities identified: [[Micro-Focus]], [[CCLE]]（CCLE 在 2022 年 3 月负责评估工作，关键组织角色） +- Source page: wiki/sources/ctp-topic-37-secrets-certificates-management.md +- Notes: 无冲突；与 [[ctp-topic-62-aws-secrets-manager]] 的关系记录于 Contradictions 节（Topic 37 试点结论 + Topic 62 深度实践，属补充关系而非冲突） + +## [2026-04-30] ingest | CTP Topic 62 AWS Secrets Manager +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/ctp-topic-62-aws-secrets-manager.md +- Status: ✅ 成功摄入 +- Summary: AWS Secrets Manager 企业级密钥管理——Nurit & Daniel 分享。选型：HashiCorp Vault vs AWS Secrets Manager POC，AWS Secrets Manager 以更低成本和更简实施胜出。分阶段实施：集中化密钥 → 自动化获取 → 轮换。核心原则：开发者无需直接访问密钥，IAM 角色+标签控制访问。实施案例：Oracle DB 密码轮换（Lambda）、SendGrid API 密钥集中化轮换（无需应用重启）、JDBC Wrapper + AWS SDK 免密登录。 +- Concepts identified: [[Secrets-Management]], [[Secret-Rotation]], [[JDBC-Wrapper]], [[AWS-Secrets-Manager]], [[HashiCorp-Vault]]（HashiCorp Vault 作为备选方案被记录于源页面，实体重要性待定） +- Entities identified: [[Nurit]], [[Daniel]], [[Victor]]（CTP Topic 62 演讲者和演示者，作为演讲者提及一次，暂不创建独立页面） +- Source page: wiki/sources/ctp-topic-62-aws-secrets-manager.md +- Notes: 无冲突检测；相关来源 [[ctp-topic-37-secrets-certificates-management]] 和 [[ctp-topic-36-sendgrid-as-an-email-service]] 已于 Contradictions 和 Connections 节记录 + +## [2026-04-29] ingest | Public Cloud Learning Sessions - OpenText GIS Security Policies - 20241015 +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/public-cloud-learning-sessions-opentext-gis-security-policies-20241015-160257-me.md +- Status: ✅ 成功摄入 +- Summary: OpenText 全球信息安全团队（GIS）安全策略全景——Mike & Ed 主讲。GIS 分层组织架构（安全运营/合规/治理风险验证/隐私）；OpenText 分层方法定义安全策略；ISO 27001 姿态框架（2022年更新）；Global Information Security Policy（GISP）是最高纲领性政策，季度审查；每月处理 2250 亿条日志，分诊约 350 个案例；FedRAMP 等多项认证支撑多垂直市场销售。 +- Concepts identified: [[ISO-27001]], [[FedRAMP]], [[Global-Information-Security-Policy]], [[Security-Awareness-Training]], [[Third-Party-Penetration-Testing]], [[Threat-Intelligence]], [[BrightCloud]]（均以 wikilink 形式记录于 Source page，各仅出现 1 次，暂不创建独立页面） +- Entities identified: [[Mike]]（GIS Team 主讲人，仅出现 1 次，以 wikilink 形式记录于 Source page）, [[Ed]]（GIS Team 主讲人，仅出现 1 次，以 wikilink 形式记录于 Source page） +- Source page: wiki/sources/public-cloud-learning-sessions-opentext-gis-security-policies-20241015-160257-me.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/public-cloud-learning-sessions-opentext-gis-security-policies-20241015-160257-me.md） + - index.md 更新：Sources 节新增条目（日期 2026-04-14，置顶于所有条目最前） + - overview.md 更新：新增 GIS Security Policies 摘要条目（置于 Thor Platform 之后，CTP Topic 28 之前）；Key Concepts 新增 ISO-27001/FedRAMP（已有条目）、BrightCloud 等 + - Connections 已建立：与 [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] 建立 related_to 关系 + - 冲突检测：与 [[ctp-topic-10]] 的互补而非冲突关系已记录于 Source Page Contradictions 节——GISP 定义全局政策纲领，Landing Zone 层面通过标签和 SCP 实现技术落地 + +## [2026-04-25] ingest | CTP Topic 64 Scaling out with Amazon EKS +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-64-scaling-out-with-amazon-eks.md +- Status: ✅ 成功摄入 +- Summary: Amazon EKS 工作负载扩缩容完整方法论——Pod 层：HPA（标准指标）+ KEDA（事件驱动）；Node 层：Cluster Autoscaler（ASG 联动）+ Karpenter（直接 EC2 API）；IP 耗尽解决方案：IPv6 双栈 VPC；集群稳定性：API Server PPF + CoreDNS 扩缩容。Suravpul 主讲。 +- Concepts identified: [[Horizontal Pod Autoscaler (HPA)]]（已在 ctp-topic-59 提及）, [[KEDA]]（新）, [[Cluster Autoscaler]]（已在 ctp-topic-70 提及）, [[Karpenter]]（已在 Part 1 提及） +- Entities identified: [[Suravpul]]（AWS 高级解决方案架构师，ctp-topic-59/64/67 三专题讲师） +- Source page: wiki/sources/ctp-topic-64-scaling-out-with-amazon-eks.md +- Notes: 与 ctp-topic-59（EKS 可靠性，HPA/VPA）和 ctp-topic-70（IaC 部署，Cluster Autoscaler）形成互补知识链路。与 Part 3 EKS Auto Mode 共享 Karpenter 知识节点。 + +## [2026-04-25] ingest | CTP Topic 67 Cloud native observability using OpenTelemetry +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-67-cloud-native-observability-using-opentelemetry.md +- Status: ✅ 成功摄入 +- Summary: AWS 解决方案架构师 Surav 分享的 EKS/ECS 云原生可观测性深度实践。涵盖可观测性三信号模型（Traces/Metrics/Logs）、OpenTelemetry Collector 架构（Receivers → Processors → Exporters）、ADOT 的多种 EKS/ECS 部署模式。核心观点：构建可观测的应用是开发者的责任；Trace 捕获调用栈各层处理耗时；Correlation ID 实现跨信号关联。 +- Concepts identified: [[OpenTelemetry]], [[Three Signals]], [[SIGV4 Auth Extension]], [[Correlation ID]] +- Source page: wiki/sources/ctp-topic-67-cloud-native-observability-using-opentelemetry.md +- Notes: 与 ctp-topic-60（Hyperscale Observability with Grafana）同属可观测性专题，与 public-cloud-learning-sessions-observability-with-opentelemetry-20240402 同属 OpenTelemetry 主题 + +## [2026-04-24] ingest | Public Cloud Learning Sessions - EKS Optimization Part 2 of 3 - Running Containers with Bottlerocket OS +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w.md +- Status: ✅ 成功摄入 +- Summary: Bottlerocket OS（火箭瓶）深度解析——AWS 专为容器工作负载优化的最小化开源 Linux 发行版。核心设计理念：最小化（去除包管理器/Shell/SSH，仅打包必要内核组件）、安全更新（分区镜像 A/B 切换确保原子性）、安全加固（dm-verity 根文件系统加密验证 + SE Linux enforcing 模式 + 根文件系统默认只读）。Variant 机制通过平台+架构+工作负载组件组合在构建时定制功能，支持 Bottlerocket for EKS AMI（自管理节点组）、托管节点组（Managed Node Groups）和 Carpenter 节点池三种集成方式。 +- Concepts identified: [[Immutable-Root-Filesystem]], [[dm-verity]], [[SE-Linux-Enforcing]], [[Partition-Updates]], [[CIS-Benchmark]] +- Entities identified: [[Bottlerocket]], [[Amazon EKS]], [[AWS]] +- Source page: wiki/sources/public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w.md +- Notes: EKS 优化三专题 Part 2（Part 1 = Karpenter 计算优化，Part 3 = EKS Auto Mode）。Bottlerocket Entity 和 5 个 Concept 均为新增。Part 3 的 EKS Auto Mode 默认使用 Bottlerocket 作为节点操作系统，形成知识链路补充。 + +## [2026-04-24] ingest | CTP Topic 42 Grafana Observability Dashboard +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-42-grafana-observability-dashboard.md +- Status: ✅ 成功摄入 +- Summary: 企业级 Grafana 可观测性平台在 AWS 多账户环境下的架构设计与 Terraform IaC 自动化实践。涵盖 Grafana 核心定位（不存储数据，仅从数据源可视化）、基础设施架构（监控账户部署 Grafana，通过 IAM 角色跨账户访问产品团队 AWS 账户）、用户和团队访问控制、示例仪表盘（CPU/I/O/Network/EBS/Estimated Charges）、告警系统（Microsoft Teams 通知）、Terraform 模块化供给（数据源模块 + 组织模块 + LZSAP 自动化接入）、Prometheus 网络监控（Checkpoint/防火墙 SNMP 指标）。 +- Concepts identified: [[Observability（可观测性）]], [[Prometheus]], [[SNMP（Simple Network Management Protocol）]], [[IAM Role（跨账户角色）]] +- Entities identified: [[AWS CloudWatch]], [[AWS Landing Zone]], [[Micro Focus Operations Bridge Manager]] +- Source page: wiki/sources/ctp-topic-42-grafana-observability-dashboard.md +- Notes: 该视频与 [[ctp-topic-60]] 均介绍 Grafana，视角互补（Grafana 本身 vs Hyperscale 场景），与 [[ctp-topic-54]] 和 [[ctp-topic-67]] 同属可观测性专题，共同构成监控知识体系。长期目标是构建应用级仪表盘替代 Micro Focus OBM。Entity 和 Concept 已有 Grafana/Prometheus/Terraform/Checkpoint 等，无需新建。 + +## [2026-04-25] ingest | CTP Topic 54 ESM SaaS Log Analytics +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-54-esm-saas-log-analytics.md +- Status: ✅ 成功摄入 +- Summary: ITOM ESM SAS 架构师 Jackie 主讲的企业级日志分析解决方案——ELK/OpenSearch 技术栈架构（BEATS/Filebeat → Logstash → Elasticsearch/OpenSearch → Kibana）、双 VPC 隔离架构、Redis 缓冲层、GDPR 合规区域分割。安全：NVMe 静态加密、TLS 1.2、VPC 私有流量、RBAC。方案对比：AWS OpenSearch（~$1,500/月，SLA 99.9%，推荐）vs Logz.io（~$4,000/月，SLA 99.8%）vs 自托管 ELK vs Microfocus OBA。 +- Concepts identified: [[ELK Stack]], [[OpenSearch]], [[Logstash]], [[Kibana]], [[BEATS]], [[Filebeat]], [[Centralized-Logging]], [[Redis缓存]], [[RBAC]], [[TLS]], [[GDPR]] +- Entities identified: [[AWS OpenSearch]], [[Jackie]] +- Source page: wiki/sources/ctp-topic-54-esm-saas-log-analytics.md +- Notes: 新建 Concept 页面 ELK-Stack.md、BEATS.md；新建 Entity 页面 AWS-OpenSearch.md；已更新 overview.md（Sources 条目 + Key Concepts）；Key Concepts 列表中已有 Centralized-Logging、Redis缓存（Redis缓存.md）、TLS，未发现冲突内容 + +## [2026-04-26] ingest | CTP Topic 59 Achieving reliability with Amazon EKS +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-59-achieving-reliability-with-amazon-eks.md +- Status: ✅ 成功摄入 +- Summary: Amazon EKS 可靠性最佳实践——Surav Paul（AWS 高级解决方案架构师）主讲。涵盖 ECS vs EKS 选型、可靠性五维度（故障检测/优雅降级/确定性故障/自愈/按需扩缩）、Shared Responsibility Model（Fargate 免除节点管理）、应用层可靠性（AZ 分散/拓扑约束/HPA/VPA/部署策略/健康探针/PodDisruptionBudget）、控制平面可靠性（指标监控/认证加固/Webhook 管理/集群升级）和数据平面可靠性（节点问题检测/资源预留/QoS/配额/Pod 优先级）。 +- Concepts identified: [[Reliability（系统可靠性）]], [[Application Reliability（应用可靠性）]], [[Control Plane Reliability（控制平面可靠性）]], [[Data Plane Reliability（数据平面可靠性）]], [[Shared Responsibility Model（EKS）]], [[Pod Anti-Affinity]], [[Topology Spread Constraints]], [[Horizontal Pod Autoscaler (HPA)]], [[Vertical Pod Autoscaler (VPA)]], [[Liveness/Readiness/Startup Probes]], [[PodDisruptionBudget]], [[Rolling/Blue-Green/Canary Deployment]]（均以 wikilink 形式记录于 Source page；均仅出现 1 次，暂无独立页面） +- Entities identified: [[Surav Paul]], [[Amazon EKS]], [[Amazon ECS]], [[AWS Fargate]]（均以 wikilink 形式记录于 Source page；仅 [[Amazon EKS]] 在多个页面中反复出现，符合独立页面创建条件，其余仅出现 1 次，暂无独立页面） +- Source page: wiki/sources/ctp-topic-59-achieving-reliability-with-amazon-eks.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/ctp-topic-59-achieving-reliability-with-amazon-eks.md） + - index.md 更新：新增 CTP Topic 59 条目于 Sources 节顶部 + - overview.md 更新：新增 CTP Topic 59 条目于 Cloud Transformation & DevOps → EKS 知识链路 + - Contradictions 记录：与 ctp-topic-39（EKS Lab LZ 网络部署）存在视角差异——Topic 39 面向受限网络环境的自定义网络方案，Topic 59 提供通用 EKS 可靠性最佳实践，互为补充而非冲突 + - 无需新建 Concept/Entity 独立页面（所有概念和实体仅在本页面出现 1 次；Amazon EKS 虽在多个其他页面提及，但本页面无新增独立维度，不单独创建） + +## [2026-04-26] ingest | CTP Topic 29 Cloud Monitoring – SaaS LZ accounts +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-29-cloud-monitoring-saas-lz-accounts.md +- Status: ✅ 成功摄入 +- Summary: AWS 云监控解决方案 OpsBridge Cloud Monitoring 覆盖多账户多区域的云原生监控架构——容器化部署于 EKS，支持 20+ AWS 数据服务，数据存储于 Optic Data Lake（Vertica）；通过 IAM Role 信任关系实现只读跨账户 CloudWatch 数据采集，无需在被监控账户安装服务器或共享 Access Key；基于标签的监控是最佳实践，自动化识别缺失标签；单一 OpsBridge 实例监控多账户多区域，降低运维成本；与 OpsBridge 产品研发团队协作，报表功能在下一版本持续增强。 +- Concepts identified: [[Cloud Monitoring（AWS）]], [[Tag-Based Monitoring]], [[Vertica]], [[OpsBridge]], [[ITOM（IT Operations Management）]]（均以 wikilink 形式记录于 Source page；仅出现 1 次，暂无独立页面） +- Entities identified: [[Micro Focus OpsBridge]], [[AWS CloudWatch]], [[AWS Landing Zone]]（均以 wikilink 形式记录于 Source page；仅出现 1 次，暂无独立页面） +- Source page: wiki/sources/ctp-topic-29-cloud-monitoring-saas-lz-accounts.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/ctp-topic-29-cloud-monitoring-saas-lz-accounts.md） + - index.md 更新：新增 CTP Topic 29 条目于 Sources 节顶部 + - Contradictions 记录：与 ctp-topic-8（OBM 监控）存在视角差异——Topic 8 描述基础 OBM 组件栈（三层架构），Topic 29 描述 Cloud Monitoring 新模块（容器化+EKS+20+数据服务），当前观点认为两者是同一方案的不同层面 + +## [2026-04-24] ingest | CTP Topic 60 - Monitor AWS using Hyperscale Observability with Grafana +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana.md +- Status: ✅ 成功摄入 +- Summary: 使用 Grafana Enterprise 实现 AWS 超大规模可观测性监控——Vinay 主讲（代替休假的 Sashi）。核心内容：Grafana 与多数据源集成、事件追踪、告警配置、实例监控和资源标签化；Optic DR 作为 VaticaDB 插件是导入 Grafana 仪表板的关键数据源；*Opsbridge 监控解决方案使用仪表板展示触发事件；Grafana 告警系统支持多通知渠道，可转发至 Opsbridge 创建工单；Terraform 模块自动化创建 Grafana 组织、用户、文件夹、IAM 角色和仪表板；默认指标不产生额外成本，自定义指标可能产生费用。未来路线图：SSO 认证、报表、URL 监控、进程监控、日志监控、与 PagerDuty/Slack Manager 集成。 +- Concepts identified: [[Hyperscale Observability]], [[Dashboard as Code]], [[Grafana Alert System]], [[Resource Tagging]], [[Instance Monitoring]], [[Event Tracking]]（均以 wikilink 形式记录于 Source page） +- Entities identified: [[Vinay]], [[Optic DR]], [[Opsbridge]], [[VaticaDB]], [[Grafana]], [[Terraform]]（均以 wikilink 形式记录于 Source page） +- Source page: wiki/sources/ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana.md） + - index.md 更新：新增 CTP Topic 60 条目于 Sources 节顶部 + - Contradictions 记录：与 ctp-topic-8（OBM 监控）的互补而非冲突关系已记录 + +## [2026-04-26] ingest | CTP Topic 8 Implementation of Cloud monitoring using Micro Focus Operations Bridge Manager +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid.md +- Status: ✅ 成功摄入 +- Summary: 使用 Micro Focus Operations Bridge Manager (OBM) 实现 AWS 公有云监控的完整解决方案——OBM AWS Account 部署 OBM 应用 + Postgres RDS + Operation Agent 三层组件；Agent 通过 AWS Management Pack 利用 IAM Role 跨账户采集 CloudWatch 指标，无需在被监控账户安装服务器或共享 Access Key；Global OBM 作为 Manager of Managers 汇聚 Regional OBM 数据，事件通过 SMACKS 触发工单；新增实例自动发现与策略自动下发，解决云环境动态性监控难题；支持任意公有云（AWS/Azure/GCP）的 CloudWatch 兼容服务。 +- Concepts identified: [[Cloud-Monitoring]], [[Management-Pack]]（均已创建独立 Concept 页面） +- Entities identified: [[SMACKS]]（已有页面，更新 sources；其余实体仅出现 1 次，以 wikilink 形式记录于 Source page） +- Source page: wiki/sources/ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid.md） + - 新增 2 个 Concept Page（wiki/concepts/Cloud-Monitoring.md, wiki/concepts/Management-Pack.md） + +## [2026-04-24] ingest | CTP Topic 39 Implementing EKS in the AWS Lab Landing Zone +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone.md +- Status: ✅ 成功摄入 +- Summary: EKS 在受限 Lab Landing Zone 网络环境下的技术实施方案——Spencer 和 Guy 分享。核心问题：Micro Focus 网络的 AWS Lab 环境 IP 地址池不足，无法满足 Octane（IP 密集型 SaaS 应用）的 EKS Pod 需求。解决方案：创建独立私有子网（非主 VPC 子网）为 EKS Pod 提供充足 IP 池；EKS 模块自定义网络标志控制 Pod IP 分配；Terraform/Terragrunt 模块封装完整 EKS 部署逻辑，支持跨账户角色映射；Pod 规范设置 `hostNetwork: true` 使其同时访问内部 Micro Focus 网络和外部资源。Atlantis 当前不支持 EKS 部署，需通过 Jenkins + Terragrunt 模块替代。 +- Concepts identified: [[Amazon EKS]], [[Kubernetes Custom Networking]], [[Terraform-Terragrunt Module]], [[IAM Role Mapping (EKS)]], [[Host Network Mode (Pod)]], [[Container Hardening]]（均以 wikilink 形式记录于 Source page；均仅出现 1 次，暂无独立页面） +- Entities identified: [[Octane-Hub]]（已有页面，更新 sources）、[[Terragrunt]], [[Atlantis]]（工具名，均仅出现 1 次，以 wikilink 形式记录于 Source page） +- Source page: wiki/sources/ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone.md） + - index.md 更新：新增 CTP Topic 39 条目于 Sources 节顶部 + - overview.md 更新：新增 CTP Topic 39 条目于 EKS 知识链路 + - 无需新建 Concept/Entity 独立页面（所有概念和实体仅出现 1 次） + +## [2026-04-26] ingest | Public Cloud Learning Sessions EKS Optimization Part 3 of 3 Introduction to EKS Auto Mode +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks-.md +- Status: ✅ 成功摄入 +- Summary: EKS Auto Mode 将 Kubernetes 数据平面管理责任从用户扩展至 AWS。Carpenter Controller 负责节点生命周期和滚动升级；Bottlerocket OS 提供最小化安全容器操作系统，自动应用安全补丁；AWS Load Balancer Controller（eks.aws/alb）管理 ingress；EBS CSI Controller 支持有状态工作负载；Pod Identity Associations 替代 K8s RBAC 实现 Pod 级 IAM 权限控制；Prefix Delegation 默认启用优化 Pod 网络 IP 分配。默认两个节点池（General Purpose AMD64 + System taint），支持自定义 Graviton 节点池。每个 Auto Mode 实例附加 12% 管理溢价。 +- Concepts created: [[EKS Auto Mode]]（已创建独立 Concept 页面） +- Source page: wiki/sources/public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks.md） + - 新增 1 个 Concept Page（wiki/concepts/EKS-Auto-Mode.md） + - Entities：AWS 和 Amazon EKS 已在 overview.md 中存在，无需新建 Entity 页面 + +## [2026-04-24] ingest | Image Prompt Engineer Agent +- Source file: Agent/agency-agents/design/design-image-prompt-engineer.md +- Status: ✅ 成功摄入 +- Summary: Image Prompt Engineer Agent 角色定义——AI 图像生成提示词工程专家智能体，专注于将视觉概念精准翻译为可执行的提示词语言，驱动 Midjourney/DALL-E/Stable Diffusion/Flux 等 AI 图像生成工具产出专业级摄影作品。核心方法：五层提示词结构框架（主体描述层 → 环境设定层 → 光线规范层 → 摄影技术层 → 风格美学层）+ 平台特定语法优化 + 体裁专属提示模式（人像/产品/风光/时尚摄影）。核心原则：摄影术语精确性 + 负向提示词 + 宽高比构图。成功指标：视觉概念还原率 90%+。与 [[design-ui-designer]]（像素级精确）存在张力，已记录于 Contradictions；与 [[design-brand-guardian]]（品牌一致性）、[[design-whimsy-injector]]（品牌趣味）协同，构成 [[The Agency]] 设计部门完整设计支撑体系。 +- Concepts linked: [[Prompt-Engineering]], [[Five-Layer-Prompt-Structure]], [[Platform-Specific-Prompt-Optimization]], [[Negative-Prompts]], [[Film-Emulation]], [[Lighting-Patterns]] +- Entities linked: [[Midjourney]], [[DALL-E]], [[Stable-Diffusion]], [[Flux]], [[Annie Leibovitz]], [[Peter Lindbergh]], [[The Agency]] +- Source page: wiki/sources/design-image-prompt-engineer.md +- Notes: index.md 已替换占位符条目；overview.md 已新增独立段落（置于 design-whimsy-injector 之后，design-brand-guardian 之前）；无新 Entity/Concept 需创建（Midjourney/DALL-E/Stable-Diffusion/Flux/Prompt-Engineering 等仅出现 1 次，不足建页阈值）；与 [[design-ui-designer]] 在概率生成 vs 像素精确的张力已记录于 Contradictions 节——通过确定性约束（具体颜色值/光照参数）协调 +- Conflicts: 与 [[design-ui-designer]] 在视觉还原精度上的差异——Image Prompt Engineer 目标 90%+ 概念还原（概率生成固有不确定性），UI Designer 要求 95%+ 实现准确率（设计到代码的翻译环节）；已建立协调方案 + +## [2026-04-24] ingest | CTP Topic 11 AD Integration and Login using AD Accounts +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/02_IAM/ctp-topic-11-ad-integration-and-login-using-ad-accounts.md +- Status: ✅ 成功摄入 +- Summary: Jenkins 与 SW Infra AD 安全域集成，实现基于 AD 账号的统一身份认证与自动化用户管理（入离职无需手动维护本地用户）；通过 AD 组策略实现 RBAC 精细化权限控制（只读/读写/流水线创建）；pre-commit 框架集成 terraform fmt/TFLint/Checkov 三款工具在代码提交阶段嵌入自动化安全检查；CI/CD 流水线分层治理模式（Commit 检查 → PR 检查+plan → Master 人工审核后 apply），核心理念为"左移"（Shift-Left）将安全问题提前到开发早期。 +- Concepts identified: [[Active Directory Integration]], [[RBAC (Role-Based Access Control)]], [[Pre-commit Framework]], [[Terraform Fmt]], [[TFLint]], [[Checkov]], [[Shift-Left Security]], [[CI/CD Pipeline Governance]]（均以 wikilink 形式记录于 Source page；各仅出现 1-2 次，未达 ≥2 次阈值，暂不创建独立页面） +- Entities identified: [[Niranjan]]（仅出现 1 次，未达 ≥2 次阈值，以 wikilink 形式记录于 Source page） +- Source page: wiki/sources/ctp-topic-11-ad-integration-and-login-using-ad-accounts.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/ctp-topic-11-ad-integration-and-login-using-ad-accounts.md） + - index.md 更新：新增 CTP Topic 11 条目于 Sources 节顶部 + - overview.md 更新：新增 CTP Topic 11 详细条目于身份治理知识体系段落 + - Contradictions 记录：与 Atlantis（ctp-topic-32）关于 terraform apply 审批权的差异已记录 + +## [2026-04-24] ingest | CTP Topic 5 - AWS Identity and Access Management (IAM) +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/02_IAM/ctp-topic-5-aws-identity-and-access-management-iam.md +- Status: ✅ 成功摄入 +- Summary: AWS IAM 核心组件与联邦访问机制——IAM Dashboard 四大资源（用户、组、客户托管策略、角色、身份提供商）；联邦用户通过 Active Directory 组映射到 IAM 角色；accounts.json 位于 Landing Zone 根目录；IAM 用户主要用于服务账号，人工用户优先使用联邦访问；角色本身不启用操作，而是将"谁可以做什么"与"可以做什么"关联；策略分为 AWS 托管和客户托管，Terraform 模块可定义 IAM 角色；PFSSO 工具实现 CLI 联邦访问；最小权限原则贯穿始终。 +- Concepts identified: [[IAM（身份和访问管理）]], [[Federation（联邦身份）]], [[Least Privilege（最小权限）]], [[IAM Role（IAM 角色）]], [[IAM Policy（IAM 策略）]], [[Managed Policy vs Inline Policy]], [[Cross-Account Role Assumption]], [[PFSSO]]（均以 wikilink 形式记录于 Source page；各仅出现 1 次，未达 ≥2 次阈值，暂不创建独立页面） +- Entities identified: [[accounts.json]], [[VSM]]（均以 wikilink 形式记录于 Source page；各仅出现 1 次，未达 ≥2 次阈值） +- Source page: wiki/sources/ctp-topic-5-aws-identity-and-access-management-iam.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/ctp-topic-5-aws-identity-and-access-management-iam.md） + - index.md 更新：替换原有缺失条目为完整条目（日期 2026-04-24） + - overview.md 更新：新增 CTP Topic 5 条目于身份治理知识体系段落 + +## [2026-04-24] ingest | Public Cloud Learning Sessions - AWS End User Compute Services - 20240430 +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee.md +- Status: ✅ 成功摄入 +- Summary: AWS EUC 服务全景介绍——覆盖 Workspaces（全持久虚拟桌面）、AppStream 2.0（选择持久/非持久应用流，多租户降本）、Workspace Core（第三方 VDI 集成）、Workspace Web（低成本安全浏览器）四大服务。选型原则：知识工作者完整桌面 → Workspaces；实验室/培训/非持久 → AppStream 2.0；第三方 VDI → Workspace Core；安全浏览 → Workspace Web。安全措施包括 AD 集成、加密、IAM 配置文件、SAML 认证、多因素认证。 +- Concepts identified: [[Amazon-Workspaces]], [[AppStream-2.0]], [[AWS-End-User-Computing]], [[Virtual-Desktop-Infrastructure]], [[WSP-Protocol]], [[BYOD]], [[VDI]], [[SAML-Authentication]], [[VPC-Interface-Endpoints]]（均以 wikilink 形式记录于 Source page；各仅出现 1-2 次，未达 ≥2 次阈值，暂不创建独立页面） +- Entities identified: [[Christian-O'Donough]]（仅出现 1 次，未达 ≥2 次阈值，以 wikilink 形式记录于 Source page） +- Source page: wiki/sources/public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee.md） + - index.md 更新：在 Sources 节顶部新增条目（日期 2026-04-24） + - overview.md 更新：在 ctp-topic-6-aws-workspaces-demo 之后新增摘要段落；与 [[ctp-topic-6-aws-workspaces-demo]] 建立关联关系 + - Connections 已建立：与 [[ctp-topic-6-aws-workspaces-demo]]（实操演示）、[[AWS-Landing-Zone]]（VPC 架构）建立 depends_on 关系 + - 冲突检测：无已知冲突内容 + +## [2026-04-30] ingest | Public Cloud Learning Sessions - Applicable Business Analysis Techniques - 20240109 +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109-.md +- Status: ✅ 成功摄入 +- Summary: 业务分析（Business Analysis）基础技能与三大核心技法——T型技能模型（连接业务与技术）、BOSCARD框架（复杂新工作定义）、干系人轮盘（Stakeholder Wheel）、结合元数据的用户故事需求收集。INVEST原则检查需求质量，SAFe框架补充Features/Capabilities/NFR。核心理念：业务分析将业务需求与技术变更解决方案对齐，帮助定义企业架构中哪些变更是有益的。 +- Concepts identified: [[Business-Analysis]], [[T-Shaped-Skills]], [[BOSCARD]], [[Stakeholder-Wheel]], [[Requirements-Gathering]], [[INVEST]], [[SAFe]], [[RACI]]（均以 wikilink 形式记录于 Source page；各仅出现 1 次，未达 ≥2 次阈值，暂不创建独立页面） +- Entities identified: [[BCS]], [[IIBA]], [[OpenText]]（均仅出现 1 次，未达 ≥2 次阈值，以 wikilink 形式记录于 Source page） +- Source page: wiki/sources/public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109.md） + - index.md 更新：替换预期占位符为正式条目（日期修正为 2024-01-09，添加摘要） + - overview.md 更新：在 Cloud Transformation & DevOps 部分新增摘要段落（置于 ctp-topic-4 之后）；Key Concepts 新增 Business-Analysis、T-Shaped-Skills、BOSCARD、Stakeholder-Wheel、Requirements-Gathering、INVEST、SAFe + - Connections 已建立：与 ctp-topic-4（敏捷实践）、ctp-topic-57（需求管理）、ctp-topic-20（需求流程）、ctp-topic-41（NFR）建立 related_to 关系 + - 冲突检测：与 [[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]] 互补而非冲突——Topic 4 提供敏捷持续流动实践框架，本视频提供需求定义前置技法，构成云转型计划完整方法论（规划→需求→执行） + +## [2026-04-14] ingest | CTP Topic 23 Introduction to the Technical Architecture Team and Function +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-23-introduction-to-the-technical-architecture-team-and-function.md +- Status: ✅ 成功摄入 +- Summary: Martin Nash（技术架构经理）介绍技术架构团队的核心职能、组织架构及在云转型中的价值。核心主题：从被动响应转向主动规划。团队推行"云优先"策略，维护 AWS Enterprise Landing Zones。三层架构分工：EA（企业架构）对接业务战略，SA（方案架构）负责中间件与服务优化，TA（技术架构）专注底层技术实施与基础设施治理。通过划分"技术领域"并由首席架构师负责，制定 12-24 个月前瞻性路线图。 +- Concepts created: [[Enterprise-Architecture]], [[Solution-Architecture]], [[Technical-Architecture]]（均已创建独立页面） +- Entities created: [[Martin-Nash]]（Technical Architecture Manager，已创建独立页面） +- Source page: wiki/sources/ctp-topic-23-introduction-to-the-technical-architecture-team-and-function.md +- Notes: + - 新增 1 个 Source Page + - index.md 更新：替换预期占位符为正式条目（日期修正为 2026-04-14，添加摘要） + - overview.md 更新：在 CTP Topics 部分添加 Topic 23 摘要条目（位于 Topic 47 和 Topic 72 之间） + - 新增 3 个 Concept 页面：Enterprise-Architecture.md, Solution-Architecture.md, Technical-Architecture.md + - 新增 1 个 Entity 页面：Martin-Nash.md + - Key Concepts 新增：[[Cloud-First Strategy]], [[AWS Enterprise Landing Zones]], [[Technical Domains]], [[Enterprise Architecture (EA)]], [[Solution Architecture (SA)]], [[Technical Architecture (TA)]], [[Roadmaps]], [[ITIL Alignment]] + - 无冲突内容 + +## [2026-04-25] ingest | CTP Topic 57 Product backlog managing demand +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-57-product-backlog-managing-demand.md +- Status: ✅ 成功摄入 +- Summary: CTP 产品待办列表（Backlog）需求管理完整管道——SMACs提交→双周评审（20题问卷）→Octane特性化→Sprint规划（50%新需求/50%支持+技术债）→Prerequisite Phase→SRE构建账号→2周Hyper Care。核心理念：透明化需求管道，确保所有工作以同一标准评估。 +- Concepts identified: [[Product-Backlog]], [[Demand-Management]], [[SMACs]], [[Prerequisite-Phase]], [[Hyper-Care]], [[Sprint-Planning]], [[Octane]]（均以 wikilink 形式记录于 Source page） +- Entities identified: [[Matthew Chapman]], [[David Grant]], [[Brendan Starnig]], [[ADM]], [[ITOM]], [[PCG]], [[SRE]]（均以 wikilink 形式记录于 Source page；Matthew Chapman/David Grant 仅出现1-2次，未达 ≥2 阈值，暂不创建独立 Entity 页面） +- Source page: wiki/sources/ctp-topic-57-product-backlog-managing-demand.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/ctp-topic-57-product-backlog-managing-demand.md） + - index.md 更新：替换预期占位符为正式条目（日期修正为 2026-04-14，添加摘要） + - overview.md 更新：在 CTP Topics 部分添加 Topic 57 摘要条目（位于 Topic 41 和 Topic 65 之间）；Key concepts 新增 [[Product-Backlog]], [[Demand-Management]], [[SMACs]], [[Prerequisite-Phase]], [[Hyper-Care]], [[Octane]] + - Connections 已建立：与 CTP Topic 20（需求流程）、CTP Topic 4（敏捷实践）、CTP Topic 30（变更管理）建立 related_to 关系 + - 无冲突内容 + +## [2026-04-25] ingest | Public Cloud Learning Sessions (OpenText) - Thor Platform & Flows +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet.md +- Status: ✅ 成功摄入 +- Summary: Arnold Dacan 详解 Project Thor 平台架构与数据流——五大支柱框架（敏捷周期治理、产品发布治理、开发者门户 Backstage、安全治理、Build Hub）；核心数据流：源代码（GitLab）→ 制造流程（Build Farms）→ Artifactory → 客户环境；地理分布：主站点 Brook Park + 灾备站点 Sacramento；标准化目标：统一 GitLab/Artifactory/UCMDB 工具链，夯实供应链安全基础。 +- Concepts identified: Project Thor, Supply Chain Security, Build Hub, GitLab Proxy, GitLab Geo, Code Signing（均以 wikilink 形式记录于 Source page，暂不创建独立 Concept 页面） +- Entities identified: Arnold Dacan（仅出现1次，未达 ≥2 阈值，以 wikilink 形式记录于 Source page）；GitLab/Artifactory/Backstage/UCMDB（通用工具名称，不创建独立 Entity 页面） +- Source page: wiki/sources/public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet.md） + - index.md 更新：替换预期占位符为正式条目（添加摘要） + - overview.md 更新：在 GitHub→GitLab 迁移条目后新增 Thor Platform & Flows 摘要条目 + - Connections 已建立：与 GitHub→GitLab 迁移文档建立 extends 关系；与 CTP Topic 21 建立 related_to 关系 + - 无冲突内容 + +## [2026-04-25] ingest | CTP Topic 6 AWS Workspaces Demo +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-6-aws-workspaces-demo.md +- Status: ✅ 成功摄入 +- Summary: AWS Workspaces 虚拟桌面演示——Windows Server 2016 托管桌面，预装 PFSSO/Terraform/TerraGrunt/Git/VS Code；21分钟完成 TerraGrunt Plan；通过 Federation 访问 AWS Console，GitHub Enterprise 登录（已过期，应为 GitLab） +- Concepts identified: [[AWS Workspaces]], [[Terraform]], [[TerraGrunt]], [[PFSSO]], [[AWS Federation]]（均已存在于 Wiki 或通过 Source page 内 wikilink 引用，暂不创建独立页面） +- Entities identified: [[Naga]]（仅出现1次，未达 ≥2 阈值，以 wikilink 形式记录于 Source page） +- Source page: wiki/sources/ctp-topic-6-aws-workspaces-demo.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/ctp-topic-6-aws-workspaces-demo.md） + - index.md 更新：替换预期占位符为正式条目（日期修正为 2026-04-14，添加摘要） + - overview.md 更新：在 Cloud Transformation & DevOps 部分新增 Topic 6 摘要条目 + - Contradiction 已记录：与 GitHub→GitLab 迁移文档冲突（视频录制时仍使用 GitHub Enterprise，当前已被 GitLab 替代） + +## [2026-04-25] ingest | CTP Topic 53 Why bother with Cloud +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-53-why-bother-with-cloud.md +- Status: ✅ 成功摄入 +- Summary: Micro Focus 云转型计划商业价值论证——14个数据中心近20,000台资产，年营收25亿美元但VMware利用率不足40%；三个产品从Bublikan迁出后下线575台物理服务器，云端仅需240台虚拟服务器；Redding退出时40%应用直接关机；当前55% AWS成本发生在LZ之外。云迁移不仅是成本节约，更是创新催化剂。 +- Concepts identified: Cloud Transformation Programme, Landing Zone (Labs/SAS/Corporate), AWS Account Tagging Framework, Enterprise Platform, Multi-Cloud Strategy（均已在 overview.md 中以 wikilink 关联，暂不创建独立 Concept 页面） +- Entities identified: Micro Focus, ELT, Bublikan, Redding, Houston, Dart, CCOE, SRE（均已在 overview.md 中以 wikilink 关联，暂不创建独立 Entity 页面） +- Source page: wiki/sources/ctp-topic-53-why-bother-with-cloud.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/ctp-topic-53-why-bother-with-cloud.md） + - index.md 更新：替换预期占位符为正式条目（日期修正为 2026-04-14，添加摘要） + - overview.md 更新：在 Cloud Transformation & DevOps 部分添加 Topic 53 摘要条目 + - Contradiction 已记录：与 ctp-topic-43-vmware-cloud-on-aws 的观点张力（完全迁移 vs 混合云中间路线） + +## [2026-04-24] ingest | Public Cloud Learning Sessions (OpenText) - GitHub Enterprise to GitLab Migration +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20.md +- Status: ✅ 成功摄入 +- Summary: OpenText 将源代码管理平台从 GitHub Enterprise 迁移至 GitLab——Project Thor 整合工具链，GitLab 作为源代码控制黄金标准；GitHub 许可证12月底到期不续；各团队自服务模式规划迁移；两种迁移方案（镜像同步 / 搬移重构）；PHT 跟踪进度；网络挑战通过 Brook Park GitLab 代理解决。 +- Concepts identified: Project Thor（企业工具链整合）, Build Hub（中心工具支持团队）, Self-Serve Migration（自服务迁移模式）, Mirroring（镜像同步迁移）, Shift and Lift（搬移重构迁移）, Service Account Standard（服务账号标准） +- Entities identified: OpenText, GitHub Enterprise, GitLab, Build Hub, PHT（均未达 ≥2 次阈值，暂不创建独立页面，以 wikilink 关联） +- Source page: wiki/sources/public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20.md） + - index.md 更新：替换预期占位符为正式条目（日期修正为 2026-04-24） + - overview.md 更新：新增摘要段落（置于 tagging-standard-v2 之后，ctp-topic-28 之前） + - 冲突检测：未发现与其他 Wiki 页面的矛盾冲突 + +## [2026-04-29] ingest | Public Cloud Learning Sessions - OpenText Tagging Standard v2 +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-opentext-tagging-standard-v2-20250429-170111-meet.md +- Status: ✅ 成功摄入 +- Summary: OpenText 云资源标签标准 v2，Martin Rosler 主讲——三大驱动力（成本优化/风险降低/自动化效率）；覆盖云账户、云资源、Kubernetes 对象和容器镜像；标准化前缀（OT\_/app.opentext.com/com.opentext.image）确保跨平台语义无歧义；最佳实践：IaC 自动化、禁止标签存敏感数据。 +- Concepts identified: Cloud-Cost-Optimization（成本优化）, Tag-Standardization（标签标准化）, Kubernetes-Labeling（Kubernetes 标签）, Container-Image-Tagging（容器镜像标签）, IaC-Tagging-Automation（IaC 标签自动化） +- Entities identified: Martin-Rosler（讲师，出现 1 次，未达 ≥2 次阈值，以 wikilink 关联）, Phenops-Team（发起团队，出现 1 次，未达 ≥2 次阈值，以 wikilink 关联） +- Source page: wiki/sources/public-cloud-learning-sessions-opentext-tagging-standard-v2-20250429-170111-meet.md +- Notes: + - 新增 1 个 Source Page（替换 index.md 占位符条目，日期修正为 2026-04-14） + - overview.md 新增摘要段落（置于 ctp-topic-17 之后，ctp-topic-28 之前）；Key Entities 新增 Martin Rosler 和 Phenops-Team + - 冲突检测：与 [[ctp-topic-28-aws-tag-validation-tool]] 无矛盾——标签标准定义「应该怎么标」，验证工具发现「谁没标好」，两者互补 + - Terraform/Kubernetes/Container-Images 已在 Key Concepts 中存在，以 wikilink 关联 + + +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-41-nfrs-and-error-budgets.md +- Status: ✅ 成功摄入 +- Summary: NFR（非功能需求）与 Error Budget（错误预算）在云转型和敏捷开发中的实践——Brendan Standing（Head of SRE）主讲。核心：NFR Epic 模板将 NFR 集成到 Sprint Backlog；AWS 共享责任模型；Error Budget = 1 - SLO，量化系统可容忍的不可靠程度；SLR/SLO/SLA 三层体系；混沌工程主动注入故障验证韧性。核心理念：Error Budget 将失败归一化为开发流程的一部分，弥合开发与运维的文化鸿沟。 +- Concepts identified: NFR（非功能需求）, Error Budget（错误预算）, Chaos Engineering +- Entities identified: Brendan-Standing, AWS, Micro Focus（各仅出现 1-2 次，未达 ≥2 次阈值，暂不创建独立页面） +- Source page: wiki/sources/ctp-topic-41-nfrs-and-error-budgets.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/ctp-topic-41-nfrs-and-error-budgets.md） + - NFR/Error Budget/Chaos Engineering 以 wikilink 形式建立关联，暂不创建独立页面（各仅出现 1 次，未达 ≥2 次阈值） + - Brendan-Standing 以 wikilink 形式建立关联，暂不创建独立页面（仅出现 1 次，未达 ≥2 次阈值） + - index.md 更新：替换预期占位符为正式条目（日期修正为 2026-04-14） + - overview.md 更新：新增 CTP Topic 41 摘要段落（置于 ctp-topic-30 之后，ctp-topic-65 之前）；Key Concepts 新增 NFR（非功能需求）、Error Budget（错误预算）、Chaos Engineering + - 冲突检测：与 [[ctp-topic-30-managing-change]] 在 SRE 职责范围上存在视角差异——Topic 30 强调变更管理，Topic 41 强调可靠性工程，两者互补而非矛盾，已记录于 Source Page Contradictions 节 + +## [2026-04-28] ingest | CTP Topic 10 AWS Landing Zone (LZ) Data Collection, Tagging Related Security +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md +- Status: ✅ 成功摄入 +- Summary: AWS Landing Zone 部署数据收集策略与基于标签的云原生安全架构——Steve Jarman 和 Pradeep 主讲。核心：OU+SCP 分层治理、标签即凭证（替代 IP 规则）、Checkpoint 有序层防火墙（地理→类型→BU→产品→环境→角色）、Inline 层账号号父子规则。标签缺失/篡改触发 SCP 拒绝策略，确保合规。 +- Concepts identified: Service-Control-Policies-SCPs, Checkpoint-Firewall, AWS-Landing-Zone, Tag-Based-Security, OU-Layered-Security +- Entities identified: Steve-Jarman, Pradeep, Checkpoint, AWS-Organizations +- Source page: wiki/sources/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md +- Notes: + - 新增 1 个 Source Page（替换 2 个占位符条目） + - 5 个 Concepts 以 wikilink 形式建立关联，暂不创建独立页面（Service-Control-Policies-SCPs/Checkpoint 已存在于 entities/；其余各仅出现 1-2 次，未达 ≥2 次阈值） + - 4 个 Entities 以 wikilink 形式建立关联，暂不创建独立页面（Checkpoint 已存在于 entities/；Steve-Jarman/Pradeep/AWS-Organizations 各仅出现 1-2 次，未达 ≥2 次阈值） + - index.md 更新：修正日期为 2026-04-14，移除重复占位符条目（line 416） + - overview.md 更新：修正 CTP Topic 10 段落的 wikilink 指向新 source page；Key Concepts 新增 3 个概念（Service-Control-Policies-SCPs/OU-Layered-Security/Tag-Based-Security） + - 冲突检测：与 [[ctp-topic-28-aws-tag-validation-tool]] 在 SCP 标签强制能力边界上存在视角差异——Topic 10 认为 SCP 可「阻止不合规资源创建」，Topic 28 认为「无法修复存量资源」。两者互补：SCP 负责预防（准入控制），Tag Validation Tool 负责发现（存量审计） + +## [2026-04-27] ingest | CTP Topic 20 Program demand process flow and PoC onboarding +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-20-program-demand-process-flow-and-poc-onboarding.md +- Status: ✅ 成功摄入 +- Summary: 云转型计划的程序需求流程与 POC 入职流程——Sergio 和 Damian 主讲。核心内容：需求来源（业务案例/战略优先级/产品路线图）、Gate Process 三阶段审批（Gate 0/1/3）、POC 目的（验证架构可行性+熟悉 Gruntwork Landing Zone）、新环境强调 IaC（Terraform/Terragrunt）自动化、PCG 团队职责、成功标准前置定义。 +- Concepts identified: Program-Demand-Process, Proof-of-Concept, Gate-Process, Solution-Design +- Entities identified: Sergio, Damian, PCG-Team, Gruntwork, Terraform, Terragrunt +- Source page: wiki/sources/ctp-topic-20-program-demand-process-flow-and-poc-onboarding.md +- Notes: + - 新增 1 个 Source Page + - 4 个 Concepts 以 wikilink 形式建立关联，暂不创建独立页面（各仅出现 1 次，未达 ≥2 次阈值） + - 6 个 Entities 以 wikilink 形式建立关联，暂不创建独立页面（Sergio/Damian/PCG-Team 各仅出现 1 次；Gruntwork/Terraform/Terragrunt 已存在于 wiki/） + - index.md 更新：替换预期占位符为正式条目（日期修正为 2026-04-14） + - overview.md 更新：新增 CTP Topic 20 摘要段落（置于 ctp-topic-65 之后，ctp-topic-47 之前）；Key Concepts 列表新增 4 个概念（Program-Demand-Process/Proof-of-Concept/Gate-Process/Solution-Design） + - 冲突检测：与 [[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]] 存在流程视角差异——Topic 4 强调 Kanban 持续流动允许随时调整优先级，Topic 20 强调 Gate Process 阶段性审批节点。两者非逻辑矛盾，而是适用场景不同（敏捷迭代 vs 迁移治理），已记录于 Source Page Contradictions 节 + +## [2026-04-24] ingest | CTP Topic 4 Using Agile to Run the Cloud Transformation Programme +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-4-using-agile-to-run-the-cloud-transformation-program.md +- Status: ✅ 成功摄入 +- Summary: 云转型计划中敏捷实践落地经验——从 Scrum（两周 Sprint）因"Sprint 期间不允许变更"转向 Kanban 持续流动，采用混合框架（Kanban 为主 + 保留 Scrum 仪式）。Microsoft Planner 看板五列布局，最佳实践：单一负责人、依赖链接、优先级和截止日期。核心价值观：快速反馈驱动产品和开发文化持续改进。 +- Entities created: Heather-Norris, Microsoft-Planner +- Concepts created: Scrum, Kanban, Agile-Ceremonies, Continuous-Delivery +- Source page: wiki/sources/ctp-topic-4-using-agile-to-run-the-cloud-transformation-program.md +- Notes: 与 CTP Topic 30 (变更管理) 和 Topic 57 (需求管理) 共同构成项目管理知识体系 + +## [2026-04-26] ingest | CTP Topic 65 Tracing the Value Delivered in Cloud Transformation +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation.md +- Status: ✅ 成功摄入 +- Summary: 云转型价值交付量化框架——涵盖 Process/Value/Value-Stream 基础概念、Lean 三类活动识别、收益四维度量化（财务/生产力/质量/体验）、WSJF 优先级排序（Cost of Delay / Size of Job）、功能级价值拆解方法。核心理念："以最小投入尽早交付最大价值"。 +- Concepts identified: Process, Value, Value-Stream, Value-Adding, Waste, Benefits-Quantification, Cost-of-Delay, WSJF, SOM, Feature-Level-Value-Breakdown +- Entities identified: CTP（Cloud Transformation Programme），Scaled-Agile（WSJF 来源框架） +- Source page: wiki/sources/ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation.md + + - 新增 1 个 Source Page（wiki/sources/ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation.md） + - 所有 Concepts 和 Entities 均以 wikilink 形式建立关联，暂不创建独立页面（各仅出现 1 次，未达 ≥2 次阈值） + - index.md 更新：替换预期占位符为正式条目（日期修正为 2026-04-14） + - overview.md 更新：新增 CTP Topic 65 摘要段落（置于 ctp-topic-30 之后，ctp-topic-47 之前）；Key Concepts 列表新增 10 个概念 + - 冲突检测：与 [[ctp-topic-53-why-bother-with-cloud]] 存在视角张力——Topic 53 质疑迁移必要性，Topic 65 假设迁移已决策并聚焦如何量化交付价值。两者互补而非逻辑矛盾——前者回答"是否迁移"，后者回答"如何衡量价值"。已记录于 Source Page Contradictions 节。 + + +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-30-managing-change.md +- Status: ✅ 成功摄入 +- Summary: 云转型中的变更管理与 SRE 团队协作——Brendan Starnig（SRE Function Lead）主讲。核心内容：①SRE 职责——用软件工程思维解决运维问题，追求可靠性、可测试性、可重复性；②变更分类——Standard Change（预批准，完全自动化）→ Normal Change（需 CAB 审批）→ Emergency Change（立即执行，事后 CAPA）；③SRE 三阶段协作——Build/Early Live Support/BAU；④Self-Healing 演进方向。 +- Concepts created: Standard-Change, Normal-Change, Emergency-Change, CAPA, Early-Live-Support +- Entities created: Brendan-Starnig, SMACs +- Source page: wiki/sources/ctp-topic-30-managing-change.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/ctp-topic-30-managing-change.md） + - 新增 2 个 Entity 页面（Brendan-Starnig.md, SMACs.md） + - 新增 5 个 Concept 页面（Standard-Change.md, Normal-Change.md, Emergency-Change.md, CAPA.md, Early-Live-Support.md） + - 更新现有 Entity：SRE-Team.md（添加三阶段支持职责和 Topic 30 来源） + - index.md 更新：替换预期占位符为正式条目（日期修正为 2026-04-14） + - overview.md 更新：新增 CTP Topic 30 摘要段落 + - 冲突检测：与 [[ctp-topic-53-why-bother-with-cloud]] 的观点张力——Topic 30 假设迁移决策已做出，聚焦执行层面变更管理；Topic 53 质疑迁移必要性。已记录于 Source Page Contradictions 节。 + +## [2026-04-25] ingest | CTP Topic 69 Best Practices for Migrating On-Premises (IOD) Virtual Machines to VMware Cloud on AWS +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-69-best-practices-for-migrating-on-premises-iod-virtual-machines-to-vm.md +- Status: ✅ 成功摄入 +- Summary: VMC on AWS 虚拟机迁移最佳实践——HCX 多云管理（每次迭代最多 200 台 VM）、UI 和 CCOE 脚本两种迁移方案、Direct Connect + Virtual Transit Gateway 混合云连接、预/后迁移自动化、Brown to Manage 系统集成 SMACS + HCMX 实现后迁移管理。 +- Concepts created: Direct Connect, Virtual Transit Gateway, BGP, EC2-Bare-Metal, CCOE, SMACS Suite, HCMX +- Source page: wiki/sources/ctp-topic-69-best-practices-for-migrating-on-premises-iod-virtual-machines-to-vm.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/ctp-topic-69-best-practices-for-migrating-on-premises-iod-virtual-machines-to-vm.md） + - 所有 Concepts 和 Entities 均以 wikilink 形式建立关联，暂不创建独立页面（各仅出现 1 次，未达 ≥2 次阈值） + - index.md 更新：替换预期占位符为正式条目（日期修正为 2026-04-14） + - overview.md 更新：新增 CTP Topic 69 摘要段落（置于 ctp-topic-43 之后），补充 HCX 和迁移执行层面的详细信息 + - 冲突检测：与 [[ctp-topic-43-vmware-cloud-on-aws]] 互补而非冲突——Topic 43 提供 VMC on AWS 概述，Topic 69 提供迁移执行细节，已记录于 Source Page Contradictions 节 + +## [2026-04-24] ingest | Public Cloud Learning Sessions (OpenText) - Evolving from DR to Recovery Assurance - 20240723 +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2.md +- Status: ✅ 成功摄入 +- Summary: OpenText DR 向 Recovery Assurance 演进框架——Jim Rose 主讲，涵盖 CrowdStrike 事件警示、RTO/RPO 合同差异、DR 测试瓶颈（被动/手动/按客户时间表）、多云复杂性（AWS/GCP/Azure）、混合架构挑战，以及 Design/Software/Build/Environments 四位框架转型路径。SRE + 可观测性工程是核心驱动力。 +- Concepts identified: RTO, RPO, SRE, Observability-Engineering, Disaster-Recovery, Business-Continuity-Plan, Self-Healing, Customer-Zero-Environment +- Entities identified: OpenText, Jim-Rose, CrowdStrike +- Source page: wiki/sources/public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2.md +- Notes: + - 新增 1 个 Source Page + - Concepts 和 Entities 均以 wikilink 形式建立关联，暂不创建独立页面（各仅出现 1 次，未达 ≥2 次阈值） + - index.md 更新：插入至 Sources 顶部，日期 2026-04-24 + - overview.md 更新：无需更新（已有 ctp-topic-72 覆盖 DR 核心内容，本视频内容已通过 Connections 节与相关 Topic 建立关联） + - 冲突检测：无冲突——与现有 Wiki DR 内容互补，记录于 Source Page Contradictions 节 + +## [2026-04-25] ingest | CTP Topic 31 Network Segregation and Secure Access to the New AWS Landing Zones +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones.md +- Status: ✅ 成功摄入 +- Summary: AWS Landing Zone 网络隔离与安全远程访问方案。核心：①网络隔离——Checkpoint 防火墙 SPI default-deny 阻断内部网络直连 AWS；②安全访问——AWS SSM 替代 VPN，IAM 角色假设 + SSM Agent 实现浏览器/CLI 远程访问。定位为 SD-WAN 实施前过渡方案；长期目标 IaC 化消除控制台访问。与 Topic 18 互补（打通 vs 限制）。 +- Concepts created: (已存在: SD-WAN, AWS-Landing-Zone, Network-Segregation, AWS-Systems-Manager-SSM, SPI-Security-Policy-Infrastructure; 新增 wikilinks 于 source page) +- Entities created: (已存在: Checkpoint) +- Source page: wiki/sources/ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones.md +- Notes: + - 新增 1 个 Source Page + - 冲突记录：与 [[ctp-topic-18-wide-area-networking-in-aws-cloud]] 的视角张力——Topic 18 关注打通网络，Topic 31 关注限制网络；已记录于 source page Contradictions 章节 + +## [2026-04-25] ingest | CTP Topic 18 Wide Area Networking in AWS Cloud +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-18-wide-area-networking-in-aws-cloud.md +- Status: ✅ 成功摄入 +- Summary: AWS Transit Gateway 全球广域网架构与 SD-WAN 演进路径——Micro Focus IT 网络架构师 Christian Deckelman 主讲。核心架构：全球划分为 APJ/EMEA/AMS 三个地理区域，每个区域设立 Hub，Landing Zones 通过 TGW Peering 以星型拓扑接入 Hub，区域 Hub 之间全网状互联。现状依赖静态路由缺乏 BGP，DR 需人工干预。未来演进：引入 Silver Peak SD-WAN 实现动态路径选择，Pulse VPN 迁移至 Prisma Access (SASE) 实现就近接入。 +- Concepts created: AWS-Transit-Gateway, Hub-and-Spoke, SD-WAN, Overlay-Network, Static-Routing, Prisma-Access, TGW-Peering +- Entities created: (已存在: Micro Focus, AWS, Christian Deckelman, Silver Peak, Palo Alto Networks) +- Source page: wiki/sources/ctp-topic-18-wide-area-networking-in-aws-cloud.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/ctp-topic-18-wide-area-networking-in-aws-cloud.md） + - 新增 7 个 Concept 页面 + - index.md 更新：Sources 节新增条目（日期 2026-04-14） + - overview.md 更新：新增 Topic 18 的完整段落 + - 冲突检测：无已知冲突 + +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-43-vmware-cloud-on-aws.md +- Status: ✅ 成功摄入 +- Summary: VMware Cloud on AWS（VMC on AWS）混合云服务介绍——VMware与AWS联合开发，在AWS裸金属服务器（i3.metal/i3en.metal）上原生安装vSphere 8。工作负载可在数秒内往返迁移于本地与云端之间，通过HCX实现any-to-any vSphere迁移。相比常规云方案节省27%成本，云经济学团队可提供TCO计算。 +- Concepts created: VMware-Cloud-on-AWS, HCX, SDDC, Stretched-Cluster, Hybrid-Cloud +- Entities created: VMware, AWS +- Source page: wiki/sources/ctp-topic-43-vmware-cloud-on-aws.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/ctp-topic-43-vmware-cloud-on-aws.md） + - 新增 2 个 Entity 页面（VMware.md, AWS.md） + - 新增 4 个 Concept 页面（VMware-Cloud-on-AWS.md, HCX.md, SDDC.md, Stretched-Cluster.md） + - index.md 更新：Sources 节新增条目（日期 2026-04-25，置顶于所有条目最前）；Entities 节新增 VMware 和 AWS；Concepts 节新增 4 个概念 + - overview.md 更新：新增 Topic 43 的完整段落；Key Concepts 新增 VMware-Cloud-on-AWS、VMware、HCX、SDDC、Stretched-Cluster、Hybrid-Cloud + - 冲突检测：与 ctp-topic-53-why-bother-with-cloud 存在是否应迁移至云端的观点张力，已在 source page 中记录为 Contradictions + +## [2026-04-24] ingest | CTP Topic 61 Workload VPC provision with IPAM Automation +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-61-workload-vpc-provision-with-ipam-automation.md +- Status: ✅ 成功摄入 +- Summary: +- Concepts created: VPC-自动化供给, CIDR-审批流程, Availability-Zone-ID +- Source page: wiki/sources/ctp-topic-61-workload-vpc-provision-with-ipam-automation.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/ctp-topic-61-workload-vpc-provision-with-ipam-automation.md） + - index.md 更新：Sources 节新增条目（日期 2026-04-24，置顶于所有条目最前）；移除原有的 source missing 条目 + - overview.md 更新：新增 Topic 45 和 Topic 61 的完整段落，描述 IPAM 的"机制 → 应用"完整链路；Key Concepts 新增 [[VPC-自动化供给]] 和 [[CIDR-审批流程]] + - 冲突检测：无已知冲突内容 + - IPAM（IP Address Management）和 Infoblox Grid 概念已在 overview.md Key Concepts 中，无需单独 Concept 页面 + +## [2026-04-24] ingest | CTP Topic 45 Automatic IP address allocation with IPAM +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-45-automatic-ip-address-allocation-with-ipam.md +- Status: ✅ 成功摄入 +- Summary: 使用 Infoblox NIOS IPAM 实现 AWS VPC 自动化 IP 地址分配的架构实践。核心内容：①传统方式（手工请求→网络团队计算CIDR→电子表格→手工配置YAML）效率低下；②Infoblox NIOS 自动分配下一个可用 IP 地址块（≤/24 自动，>/24 需审批）；③新 YAML 配置仅声明期望子网大小和区域父 CIDR，不含硬编码 IP；④销毁 VPC 时自动从 IPAM Grid 清除条目，支持撤销保护；⑤向后兼容旧配置。目标：创建 VPC 无需网络团队参与，建立单一可信数据源。 +- Concepts created: IPAM（IP Address Management），Infoblox-NIOS，VPC-自动化供给 +- Source page: wiki/sources/ctp-topic-45-automatic-ip-address-allocation-with-ipam.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/ctp-topic-45-automatic-ip-address-allocation-with-ipam.md） + - index.md 更新：将原有的 source missing 条目替换为正式条目（日期 2026-04-24） + - IPAM 关键概念在 source page 内已有详细说明，无需单独 Concept 页面 + - 冲突检测：无已知冲突内容 + +## [2026-04-24] ingest | CTP Topic 19 Configuring DNS within AWS LZs +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-19-configuring-dns-within-aws-lzs.md +- Status: ✅ 成功摄入 +- Summary: AWS Landing Zone 多账号环境中的集中化 DNS 配置架构——Sankar Gopov 主讲。核心内容：①设立专用 DNS 账号集中管理所有私有托管区（优于分散管理）；②Route 53 Resolver Inbound/Outbound Endpoints 打通混合 DNS（Inbound 接收本地请求，Outbound 转发 AWS 请求至本地）；③AWS RAM 跨账号共享 Resolver Rules；④跨账号 VPC 关联必须先授权（Authorization）再关联（Association）；⑤Terraform 自动化实现新账号上线即具备完整解析能力。 +- Concepts created: Hybrid DNS Resolution, Route 53 Resolver Rules, VPC Association Authorization, Terraform DNS Automation +- Entities created: Sankar Gopov +- Source page: wiki/sources/ctp-topic-19-configuring-dns-within-aws-lzs.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/ctp-topic-19-configuring-dns-within-aws-lzs.md） + - 新增 1 个 Entity 页面（wiki/entities/SankarGopov.md） + - 新增 1 个 Concept 页面（wiki/concepts/HybridDnsResolution.md） + - index.md 更新：Sources 节新增条目（日期 2026-04-24，置顶于所有条目最前） + - overview.md 更新：更新 CTP Topic 22 段落，移除"（待摄入）"标注，补全两条 DNS 视频的知识体系关系描述 + - 冲突检测：与 [[ctp-topic-22-global-dns-service-offerings]] 存在潜在视角差异——DNS 账号是否应包含公共托管区；前者侧重落地配置，后者侧重服务提供架构；两者的冲突是视角互补而非逻辑矛盾 + +## [2026-04-26] ingest | CTP Topic 36 SendGrid as an Email Service +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-36-sendgrid-as-an-email-service.md +- Status: ✅ 成功摄入 +- Summary: SendGrid 被选定为 CTP 标准邮件服务，替换 Port 25 不安全的语义消息网关和每封限制 50 收件人的 SES。SendGrid 支持每封最多 1,000 收件人、TLS 端到端加密、双因素认证；两种架构（直连 vs 中继）；配置要求 software.microcopy.com 域名、smtp.sendgrid.net:587、TLS；SPF/DKIM 必要；API 密钥 180 天轮换；日志 7 天保留。同期更新了 Cyber Suite 加密标准（FIPS/Java/Golang/Node.js/OpenCell 等），可选套件因含 CBC 弱加密仅作向后兼容。 +- Concepts created: SPF, DKIM, TLS, API-Key-Rotation, Cyber-Suite, CBC-Mode +- Entities touched: SendGrid, Twilio, Rejoy Ganapati, Rajiv, Yu-Yan, PSAC +- Source page: wiki/sources/ctp-topic-36-sendgrid-as-an-email-service.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/ctp-topic-36-sendgrid-as-an-email-service.md） + - 所有 Concepts 和 Entities 均以 wikilink 形式建立关联，暂不创建独立页面（各仅出现 1 次，未达 ≥2 次阈值） + - index.md 更新：Sources 节新增条目（日期 2026-04-14，置顶于 CTP Topic 34 之后） + - overview.md 更新：新增 CTP Topic 36 摘要段落（置于 ctp-topic-22 之后，ctp-topic-17 之前）；Key Concepts 列表新增 8 个概念（SPF/DKIM/TLS/API-Key-Rotation/Cyber-Suite/CBC-Mode/SendGrid/Twilio） + - 冲突检测：与 [[ctp-topic-12-using-ses-smtp-service-terraform-module]] 存在冲突——SES 作为标准邮件服务 vs SendGrid 被选定为新标准；SES 适合 AWS 原生集成场景，SendGrid 为大规模需求首选 + + +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-22-global-dns-service-offerings.md +- Status: ✅ 成功摄入 +- Summary: 企业级全球 DNS 服务架构详解——Sankar 和 Vino 主讲。核心架构：Route 53 Private Hosted Zone + AD 托管 DNS，通过 Route 53 Resolver 入站/出站终端节点打通 AWS VPC 与本地网络 DNS 查询；Outbound Endpoint 配置多区域 AD 域控制器 IP 实现故障自动切换；Infoblox Anycast 提供本地 DNS 全球低延迟和高可用；AWS EC2 不支持 Anycast；DNS 安全涵盖防隧道攻击、缓存污染等；就近解析优化 Office 365 访问 +- Concepts touched: Hybrid DNS Resolution、Route 53 Private Hosted Zone、Route 53 Resolver、DNS Anycast、Infoblox Grid、IPAM（IP Address Management）、Active Directory DNS、Landing Zone +- Entities touched: AWS、Infoblox、Microsoft Active Directory、Office 365、Sankar、Vino +- Source page: wiki/sources/ctp-topic-22-global-dns-service-offerings.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/ctp-topic-22-global-dns-service-offerings.md） + - 所有 Concepts 和 Entities 均以 wikilink 形式建立关联，暂不创建独立页面（各仅出现 1 次，未达 ≥2 次阈值） + - index.md 更新：Sources 节替换预期占位符为正式条目（日期修正为 2026-04-14） + - overview.md 更新：新增 CTP Topic 22 摘要段落（置于 ctp-topic-14 之后，ctp-topic-17 之前）；Key Concepts 列表新增 7 个 DNS 相关概念 + - 冲突检测：ctp-topic-19（configuring DNS within AWS LZs）尚未摄入，无法进行完整对比；source page Contradictions 节已记录，待 ctp-topic-19 摄入后补充对比 + +## [2026-04-26] ingest | CTP Topic 50 AMI Roadmap for AWS AMIs +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-50-ami-roadmap-for-aws-amis.md +- Status: ✅ 成功摄入 +- Summary: CCOE AMI 路线图详解——涵盖 CCOE AMI 路线图规划、操作系统 EOL 时间线（Windows Server 2008/2008 R2 已 EOL；CentOS 8 已 EOL；Windows Server 2012 将于 2023 年 10 月 EOL；RHEL 7 和 CentOS 7 将于 2024 年 6 月 EOL）、AMI 通知机制、变更日志（CCRE 门户）、新 AMI 添加流程、当前支持的 AMI 清单及未来路线图。自 2023 年 5 月起所有 ARM AMI 同步发布。路线图优先级主要由 ADM 需求驱动，变更需通过需求管道流程提交。AMI 通过跨账号共享分发给组织内所有账户。 +- Concepts touched: Foundation AMI、OS-End-of-Life、AMI Sharing、ARM-AMI、CCOE、ADM、SSM Agent +- Entities touched: CCOE、AWS、Ubuntu、CentOS、Rocky Linux、Red Hat Enterprise Linux、SLES、Windows Server、McAfee +- Source page: wiki/sources/ctp-topic-50-ami-roadmap-for-aws-amis.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/ctp-topic-50-ami-roadmap-for-aws-amis.md） + - 所有 Concepts 和 Entities 均以 wikilink 形式建立关联，暂不创建独立页面（各仅出现 1 次，未达 ≥2 次阈值） + - index.md 更新：Sources 节替换预期占位符为正式条目（日期修正为 2026-04-14） + - overview.md 更新：新增 CTP Topic 50 摘要段落（置于 learning-sessions-standard-amis-updates 之后，ctp-topic-26 之前） + - 冲突检测：与 [[learning-sessions-standard-amis-updates]] 的 EOL 时间线一致（CentOS 7/RHEL 7 将于 2024 年 6 月 EOL）；与 [[ctp-topic-26-standard-ami-build-publish-share-processes]] 存在描述角度差异（本话题聚焦路线图规划，Topic 26 聚焦生命周期管理），非矛盾而是互补关系，已记录于 Source Page Contradictions 节 + +## [2026-04-24] ingest | CTP Topic 40 SaaS Database Architecture On AWS Cloud +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-40-saas-database-architecture-on-aws-cloud.md +- Status: ✅ 成功摄入 +- Summary: SAS 数据库团队在 AWS 云上的架构与运维实践——全球分布式团队（美国/加拿大/印度/以色列）提供 24/7 支持，管理 500+ 数据库和 1000+ DB 服务器；支持 Oracle、Vertica、Postgres、DynamoDB、SQL Server、MongoDB、MySQL 等多引擎；高可用架构采用三可用区模式（主库/备用库/见证节点）；使用 Oracle Data Guard、Postgres Active-Passive/Active-Active、RDS HA 实现多活；通过 Terraform、AWS CLI、Shell/PowerShell 实现 IaC 自动化；Oracle GoldenGate 支持零停机迁移 +- Concepts created: 无新增（高可用/Oracle Data Guard/Multi-AZ Deployment/Database Migration/DB-as-a-Service 各仅出现 1-2 次，不满足 ≥2 次建页条件，跳过独立建页） +- Entities created: 无新增（AWS/RDS/Aurora/Terraform/Micro Focus 各仅出现 1-2 次，不满足 ≥2 次条件，跳过独立建页） +- Source page: wiki/sources/ctp-topic-40-saas-database-architecture-on-aws-cloud.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/ctp-topic-40-saas-database-architecture-on-aws-cloud.md） + - 所有 Concepts 和 Entities 均以 wikilink 形式建立关联，暂不创建独立页面（未达 ≥2 次阈值） + - index.md 更新：Sources 节新增条目（置顶） + - overview.md 更新：新增 CTP Topic 40 摘要段落（置于 ctp-topic-10 之后，ctp-topic-46 之前）；Key Concepts 列表新增 Database Migration + - 冲突检测：无明显冲突内容 + +## [2026-04-26] ingest | CTP Topic 26 Standard AMI – build, publish, share processes +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-26-standard-ami-build-publish-share-processes.md +- Status: ✅ 成功摄入 +- Summary: Foundation AMI 全生命周期管理详解——基于市场主流 OS（CentOS/Ubuntu/Windows）进行 CIS 安全基准加固；集成 McAfee EPO + Syslog-ng + AD SSO + SSM Agent + SiteScope；HashiCorp Packer + Jenkins 流水线实现全自动化；跨账号 AMI Sharing 分发至全球多区域（俄勒冈/法兰克福/悉尼）；每两个月更新，N-2 版本保留策略；责任共担模型（CCOE 提供 Foundation AMI，产品团队构建产品特定 AMI） +- Concepts created: 无新增（Foundation AMI/OS Hardening/CIS Benchmarks/HashiCorp Packer/SSM Agent/AMI Sharing/Central Repository 各仅出现 1 次，不满足 ≥2 次建页条件，跳过独立建页） +- Entities created: 无新增（Srihari/Alan/Praveen 各仅出现 1 次，不满足 ≥2 次条件；CCOE 仅出现 1 次） +- Source page: wiki/sources/ctp-topic-26-standard-ami-build-publish-share-processes.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/ctp-topic-26-standard-ami-build-publish-share-processes.md） + - 7 个 Concept 均以 wikilink 形式建立关联，暂不创建独立页面（未达 ≥2 次阈值） + - index.md 更新：Sources 节替换预期条目占位符为正式条目（日期修正为 2026-04-14） + - overview.md 更新：新增 CTP Topic 26 摘要段落（置于 learning-sessions-standard-amis-updates 之后，替换原 ctp-topic-58 段落位置）；Key Concepts 列表新增 Foundation AMI / OS Hardening / CIS Benchmarks / AMI Sharing / Central Repository + - 冲突检测：与 [[ctp-topic-58-aws-ec2-image-builder]] 描述不同 AMI 生命周期阶段——ctp-topic-26 描述当前 Packer+Jenkins 生产实践，ctp-topic-58 描述 EC2 Image Builder 未来演进方向，非冲突而是演进关系，已记录于 Source Page Contradictions 节 + +## [2026-04-23] ingest | CTP Topic 68 Introduction to Redshift +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-68-introduction-to-redshift.md +- Status: ✅ 成功摄入 +- Summary: AWS Redshift 数据仓库入门——核心架构（Leader Node + Compute Node + Slices）、MPP 并行处理、列式存储 vs 行式存储、数据压缩（ZSTD/LZO）、Sort Key / Distribution Key 优化、RA3 实例类型（AWS 托管 NVMe） +- Concepts created: [[MPP]], [[Columnar-Storage]] +- Entities created: [[Amazon-Redshift]] +- Source page: wiki/sources/ctp-topic-68-introduction-to-redshift.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/ctp-topic-68-introduction-to-redshift.md） + - 新增 1 个 Entity Page（wiki/entities/Amazon-Redshift.md） + - 新增 2 个 Concept Page（wiki/concepts/MPP.md、wiki/concepts/Columnar-Storage.md） + - index.md 更新：Sources 节移除预期占位符（"source missing"）替换为正式条目；Entities 节新增 Amazon-Redshift；Concepts 节新增 MPP、Columnar-Storage + - overview.md 更新：新增 CTP Topic 68 摘要段落（置于 ctp-topic-51 之后）；Key Concepts 列表新增 Data-Warehouse、MPP、Columnar-Storage、Sort-Key、Distribution-Key + - 冲突检测：与 [[ctp-topic-66-rds-vs-aurora]] 存在架构差异（Redshift 独立 Compute Node vs Aurora 共享存储），记录于 Source Page 的 Contradictions 节 + - Sort Key 和 Distribution Key 概念因在其他页面中暂未出现，本次不创建独立页面 + +## [2026-04-14] ingest | CTP Topic 58 AWS EC2 Image Builder +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-58-aws-ec2-image-builder.md +- Status: ✅ 成功摄入 +- Summary: AWS EC2 Image Builder 替代 Packer/Jenkins 实现企业级 AMI 生命周期自动化——通过 Pipeline/Recipe/Component/Infrastructure Config 四层抽象，将 CCOE 加固脚本转换为可复用组件；POC 实现 CentOS 7 和 Ubuntu 18 端到端流水线；Lambda 工作流触发 AWS Inspector 扫描、邮件通知和 S3 报告归档 +- Concepts identified: [[Golden-AMI]], [[CCOE]], [[Image-Pipeline]], [[Image-Recipe]], [[Image-Component]], [[Infrastructure-Configuration]], [[Distribution-Settings]], [[AWS-Inspector]] +- Entities identified: [[AWS]]（仅出现 1 次，不满足 ≥2 次建页条件，跳过独立建页） +- Source page: wiki/sources/ctp-topic-58-aws-ec2-image-builder.md +- Notes: + - 新增 1 个 Source Page + - 新增 8 个 Concept，均仅出现 1 次，不满足 ≥2 次建页条件，本次不创建独立页面 + - AWS Entity 页面已存在于 wiki/entities/（Amazon-RDS.md 等系列页面），本次复用 + - index.md 更新：Sources 节替换预期条目占位符为正式条目（日期修正为 2026-04-14） + - overview.md 更新：新增 CTP Topic 58 摘要段落（置于 learning-sessions-standard-amis-updates 之后） + - 冲突检测：与 [[ctp-topic-26-standard-ami-build-publish-share-processes]] 描述不同 AMI 生命周期阶段，非冲突，记录于 Source Page 的 Contradictions 节 + +## [2023-12-05] ingest | Learning Sessions: Standard AMI Updates 20231205 +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2.md +- Status: ✅ 成功摄入 +- Summary: AWS 标准 AMI 更新机制与生命周期管理——标准 AMI 基于 AWS 原生镜像增加 OS 加固、安全补丁、SSM Agent、QALIS Agent；Jenkins 多分支流水线构建测试 AMI，将验证周期从 3-4 天缩短至 60 分钟；支持 23 种 AMI 涵盖 Amazon Linux/CentOS/OEL/RHEL/Rocky Linux/SUSE/Ubuntu/Windows；机器人框架自动化验证为核心优化手段；CentOS 7/RHEL 7 将于 2024 年 6 月 EOL，由 Rocky Linux 替代；SSM 打补丁方案适用于长期运行实例。 +- Concepts identified: [[Amazon-Machine-Image]], [[Jenkins-Multi-Branch-Pipeline]], [[AWS-Inspector]], [[Robotic-Framework]], [[SSM-Patching]], [[GP3-EBS-Storage]], [[OS-End-of-Life]] +- Entities identified: [[Rocky-Linux]], [[Sentinel-1]]（均仅出现 1 次，不满足 ≥2 次建页条件，跳过独立建页） +- Source page: wiki/sources/learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2.md +- Notes: + - 新增 1 个 Source Page + - 新增 overview.md 条目，置于 CTP Topic 7 之前（按日期 2023-12-05 排序） + - 7 个 Concept 均仅出现 1 次，不满足 ≥2 次建页条件，本次不创建独立 Concept 页面 + - 无内容冲突 + +## [2026-04-23] ingest | CTP Topic 7 SaaS Landing Zone Design +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-7-saas-landing-zone-design.md +- Status: ✅ 成功摄入 +- Summary: SAS（生产）Landing Zone 顶层设计——采用单一 Landing Zone 承载所有产品组；定义四层账户体系（Core Accounts: Shared/Logs/Security；Baseline Accounts: Network/DNS/AD；Shared Services Accounts: Software Factory/Cyber/ARC/Monitoring；Product Accounts）；Terraform IaC + GitHub/Jenkins CI/CD 端到端自动化部署链路（GitHub Hook → Jenkins → Management VPC → Lambda → ECS Cluster）；工作负载置于私有子网，WAF + CloudFront 提供入站安全；远程接入从 Checkpoint VPN 迁移至 Pulse VPN（AD 认证）。 +- Concepts identified: [[Landing-Zone-Architecture]], [[Active-Directory-Integration]], [[Transit-Gateway]], [[WAF-Web-Application-Firewall]], [[Private-Subnet-Architecture]], [[Terraform-IaC]] +- Entities identified: [[Gruntwork]], [[Jenkins]], [[Checkpoint]], [[CloudFront]], [[Qalis]], [[OBM]]（均仅出现 1 次，不满足 ≥2 次建页条件，跳过独立建页） +- Source page: wiki/sources/ctp-topic-7-saas-landing-zone-design.md +- Notes: + - 新增 1 个 Source Page + - 新增 6 个 Concept（Landing-Zone-Architecture/Active-Directory-Integration/Transit-Gateway/WAF-Web-Application-Firewall/Private-Subnet-Architecture/Terraform-IaC），均仅出现 1 次，不满足 ≥2 次建页条件，本次不创建独立页面 + - 新增 6 个 Entity（Gruntwork/Jenkins/Checkpoint/CloudFront/Qalis/OBM），均仅出现 1 次，不满足 ≥2 次条件，跳过独立建页 + - Gruntwork、Checkpoint Entity 页面已存在于 wiki/entities/，本次复用 + - Landing-Zone-Architecture Concept 页面已存在于 wiki/concepts/，本次复用 + - index.md 更新：Sources 节替换预期条目占位符为正式条目 + - overview.md 更新：新增 CTP Topic 7 摘要段落（置于 ctp-topic-1 之前） + - 冲突检测：与 [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] 存在时间维度的架构演进关系（非冲突）——ctp-topic-7 定义原始设计，ctp-topic-35 补充近期变更（网络分段、Pulse VPN 替换 Checkpoint VPN），记录于 Source Page 的 Contradictions 节 + +## [2026-04-14] ingest | CTP Topic 34 Azure Landing Zone Architecture Overview +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-34-azure-landing-zone-architecture-overview.md +- Status: ✅ 成功摄入 +- Summary: Kishore Garlopati 讲解 Azure Landing Zone 在 Micro Focus 的实施架构。核心：Azure Enterprise Enrollment → 管理组（Management Groups）四层分级（Platform/Landing Zones/Decommission/Sandbox）→ 独立订阅隔离目的 → Terraform Cloud IaC 自动化。Platform 层含 Identity 和 Connectivity 两个独立订阅；Connectivity 订阅作为中心枢纽汇聚所有入站/出站 Azure 流量（含 DDoS 防护和 Checkpoint 防火墙）；Landing Zones 设计为可扩展、模块化、全自动化；Terraform Cloud 管理跨订阅依赖；PIM/PAG 实现精细化访问控制。 +- Concepts identified: [[Azure Landing Zone]], [[Management Groups]], [[Terraform Cloud]], [[Privileged Identity Management (PIM)]], [[Privileged Access Groups]] +- Source page: wiki/sources/ctp-topic-34-azure-landing-zone-architecture-overview.md +- Notes: + - 新增 1 个 Source Page + - 新增 5 个 Concept（Azure Landing Zone / Management Groups / Terraform Cloud / Privileged Identity Management (PIM) / Privileged Access Groups），均仅出现 1 次，不满足 ≥2 次建页条件，本次不创建独立页面 + - 新增 1 个 Entity（Kishore Garlopati），仅出现 1 次，不满足 ≥2 次条件，本次不创建独立页面 + - index.md 更新：Sources 节替换预期条目占位符为正式条目 + - overview.md 更新：Cloud Transformation & DevOps 节新增 Azure Landing Zone 概念标注 + - 无冲突检测到 + - 本文档原状态为"🟡 Awaiting Whisper transcription → Summary"，现已摄入完成 + +## [2026-04-23] ingest | CTP Topic 35 AWS Landing Zone Design Refresher (SaaS Labs) +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-35-aws-landing-zone-design-refresher-saas-labs.md +- Status: ✅ 成功摄入 +- Summary: AWS Landing Zone 设计复习，明确 SaaS（生产）与 Labs（开发）的职责划分。SaaS LZ 为每个产品区域提供客户专属产品账户，连接共享服务账户（安全、日志、网络）；核心账户组含 AD、DNS、Network 账户；Gruntwork 账户跨所有账户管理 AMI、日志和安全。近期变更：网络分段阻断 SaaS 工作负载直接连通性；CCOEs CloudTrail 取代 Gruntworks CloudTrail；入站流量通过 Network 账户 Checkpoint 重新路由；AWS Backup 有望强制化；新账户可能取消 Management VPC。核心结论：SaaS = 生产，Labs = 开发；PoC LZ 并入 Labs。 +- Concepts created: [[AWS-Landing-Zone]], [[Gruntwork]], [[Shared-Services-Account]], [[Core-Accounts]], [[Product-Accounts]], [[Gruntwork-Accounts]], [[CCOEs-CloudTrail]], [[Network-Segmentation]] +- Source page: wiki/sources/ctp-topic-35-aws-landing-zone-design-refresher-saas-labs.md +- Notes: + - 新增 1 个 Source Page + - 新增 8 个 Concept（AWS-Landing-Zone/Gruntwork/Shared-Services-Account/Core-Accounts/Product-Accounts/Gruntwork-Accounts/CCOEs-CloudTrail/Network-Segmentation） + - 新增 1 个 Entity（Cloud-Technology-Design-Forum，仅在本文档提及，不满足 ≥2 次条件，跳过独立建页） + - overview.md 更新：新增 CTP Topic 35 摘要段落（置于 ctp-topic-1 之前） + - index.md 更新：Sources 节替换预期条目占位符为正式条目 + - 无冲突检测到 + +## [2026-04-14] ingest | CTP Topic 47 Enterprise Architecture Cloud Standards +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-47-enterprise-architecture-cloud-standards.md +- Status: ✅ 成功摄入 +- Summary: Lindsay 分享企业架构云标准。核心：Landing Zone 框架聚焦安全、合规和可管理性；账户结构与环境和角色对齐，零信任+最小权限原则；Terraform/Terragrunt 实现 IaC 标准化；云防护栏文档捕获强制性要求和最佳实践；功能分区将单体应用拆分为更小的独立模块或无服务器函数；强调需要应用团队输入完善防护栏。 +- Concepts created: [[Landing Zone]], [[Cloud Guardrails]], [[Functional Partitioning]] +- Source page: wiki/sources/ctp-topic-47-enterprise-architecture-cloud-standards.md +- Notes: + - 新增 1 个 Source Page + - 新增 3 个 Concept（Landing Zone / Cloud Guardrails / Functional Partitioning） + - overview.md 更新：新增 CTP Topic 47 摘要段落（置于 ctp-topic-17 之后） + - 无 Entity 创建（Lindsay 仅出现 1 次，不满足 ≥2 次条件） + - 无冲突检测到 + +## [2026-04-14] ingest | CTP Topic 72 Implementing an Enterprise DR Strategy Using AWS Backup +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup.md +- Status: ✅ 成功摄入 +- Summary: AWS 解决方案架构师 Sabith 深入讲解企业级灾难恢复策略与 AWS Backup 架构设计。核心：HA（高可用）关注运行时间和 MTBF，DR（灾难恢复）专注防止数据丢失；RPO/RTO 定义恢复目标；AWS Backup 集中化、基于策略，支持跨账户跨区域复制；四级 DR 架构模式（Backup and Restore → Pilot Light → Warm Standby → Active-Active）；增量备份节省成本；Vault Lock 合规模式防勒索软件；Bunker Account + Forensic Account 增强隔离性和测试验证。 +- Concepts created: [[高可用（High Availability）]], [[灾难恢复架构模式]], [[Vault Lock]], [[跨账户备份]], [[增量备份]], [[全量备份]], [[AWS Backup Audit Manager]] +- Source page: wiki/sources/ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup.md +- Notes: + - 新增 1 个 Source Page + - 新增 7 个 Concept（高可用/灾难恢复架构模式/Vault Lock/跨账户备份/增量备份/全量备份/AWS Backup Audit Manager） + - overview.md 更新：新增 CTP Topic 72 摘要段落（置于 ctp-topic-17 之后），Key Concepts 节新增 7 个概念标注 + - index.md 更新：Sources 节新增条目（置顶于 ctp-topic-28 之前），并删除预期条目占位符 + - 冲突检测：与 [[ctp-topic-44-aws-backup-in-micro-focus]] 互补而非冲突，Topic 72 提供理论框架，Topic 44 提供内部评估视角，构成完整 AWS Backup 知识体系 + - 与 [[ctp-topic-44-aws-backup-in-micro-focus]] 和 [[ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program]] 三者构成递进关系（理论基础 → 内部评估 → 迁移实施） + +## [2026-04-23] ingest | CTP Topic 51 Architecting with AWS Purpose-Built Databases +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-51-architecting-with-aws-purpose-built-databases.md +- Status: ✅ 成功摄入 +- Summary: AWS 数据库专家 Femi George 分享专用数据库选型与架构原则。核心：现代应用"为正确的工作选择正确的专用数据库"，避免一刀切。AWS 提供完整数据库品类（关系型/NoSQL/键值/文档/宽列/内存/图/时序）。实战案例：Duolingo 用 DynamoDB + ElastiCache + Aurora；Netflix 用 DynamoDB 做高弹性 JSON；Peloton 用 ElastiCache Redis 即时反馈。云时代 DBA 从平台管理转向应用创新。 +- Entities created: Amazon-DynamoDB, Amazon-DocumentDB, Amazon-ElastiCache, Amazon-Keyspaces, Amazon-Neptune, Amazon-Timestream +- Concepts created: Purpose-Built-Databases, DBA-Role-Evolution, Multi-Database-Architecture +- Source page: wiki/sources/ctp-topic-51-architecting-with-aws-purpose-built-databases.md +- Notes: + - 新增 1 个 Source Page + - 新增 6 个 Entity（Amazon-DynamoDB/ElastiCache/Neptune/Timestream/Keyspaces/DocumentDB） + - 新增 3 个 Concept（Purpose-Built-Databases / DBA-Role-Evolution / Multi-Database-Architecture） + - overview.md 更新：新增 CTP Topic 51 摘要段落，置于 ctp-topic-66 之前 + - index.md 更新：Sources 节替换预期条目为实际摘要，Entities 节新增 6 个实体，Concepts 节新增 3 个概念 + - 冲突检测：与 [[ctp-topic-66-rds-vs-aurora]] 视角互补而非冲突，已记录于 Source Page Contradictions 节 + +## [2026-04-23] ingest | CTP Topic 46 NetApps on AWS +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-46-netapps-on-aws.md +- Status: ✅ 成功摄入 +- Summary: Sandeep 和 Yael 主讲的 NetApp 存储系统培训。覆盖传统 NetApp 架构（ONTAP / Aggregate / FlexVol / Qtree / LUN / LIF / SVM）和 AWS 云版本 CVO。CVO 通过 EC2 实例提供软件定义存储，支持单节点或 HA 配对（跨多 AZ 同步复制）；数据分层机制将 30 天非活跃数据从 EBS 自动迁移到 S3；SnapMirror 实现块级跨集群复制；迁移工具包括 SnapMirror、NetApp XCP、Cloud Sync、AWS DataSync。组织已在 15 个 AWS 区域部署约 1.3 PB 数据。 +- Concepts created: [[SnapMirror]] +- Entities created: [[NetApp]] +- Source page: wiki/sources/ctp-topic-46-netapps-on-aws.md +- Notes: + - 新增 1 个 Source Page + - 新增 1 个 Entity（NetApp） + - 新增 1 个 Concept（SnapMirror） + - overview.md 更新：新增 CTP Topic 46 摘要段落，置于 ctp-topic-66 之前 + - index.md 更新：Sources 节新增条目（置顶于 Blogwatcher 前），Entities 节新增 NetApp，Concepts 节新增 SnapMirror + - 冲突检测：暂无检测到与其他 Wiki 页面的冲突（NetApp 存储与 RDS/Aurora 属不同技术域，互补关系） + +## [2026-04-14] ingest | CTP Topic 17 Active Directory Services in Gruntwork AWS LZs +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs.md +- Status: ✅ 成功摄入 +- Summary: Paul 讲解 Gruntwork AWS Landing Zones 中的 AD 服务集成。核心内容：双域名策略（`swinford.net` 用于 R&D Labs，`intsas.local` 用于生产/SAS 环境）；SRE 预制 AMI 内置 PowerShell（Windows）/Shell（Linux）域加入脚本，通过 Terraform `user_data` 触发自动域加入；旧域名 `infra` 和 `AST` 已废弃，提供迁移路径；Linux 支持安全动态更新（Secure Dynamic Updates）自动注册 DNS A 记录；R&D 环境使用 MIM 自助服务，生产/SAS 环境通过 SMACKS 工单系统申请账号。 +- Concepts created: [[Swinford.net]]（作为 AD 域名概念）、[[Intsas.local]]（作为 AD 域名概念）、[[SMACKS]]（作为工单系统概念） +- Entities created: [[Gruntwork]]（Company/Project类实体）、[[SMACKS]]（Project类实体） +- Source page: wiki/sources/ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs.md +- Notes: + - 新增 1 个 Source Page + - 新增 1 个 Entity（Gruntwork） + - 新增 2 个 AD 域名概念实体（Swinford.net、Intsas.local） + - 新增 1 个工单系统实体（SMACKS） + - overview.md 更新：新增 CTP Topic 17 摘要段落 + - 冲突检测：暂无检测到与其他 Wiki 页面的冲突 + +## [2026-04-24] ingest | CTP Topic 66 Exposing the differences between PostgreSQL RDS and Aurora +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora.md +- Status: ✅ 成功摄入 +- Summary: Greg Klau 深度对比 PostgreSQL RDS 与 Aurora。核心维度：①最小规格/成本（RDS 更低）；②最大容量/IO性能（Aurora 更优，>10-20TB首选）；③RTO（Aurora 30秒 vs RDS 2分钟）；④存储灵活性（RDS GP2/GP3/预置IOPS/磁性，Aurora按IO收费）；⑤架构（RDS：EC2+EBS分离，Multi-AZ备用；Aurora：6副本跨3AZ共享集群卷）；⑥Blue-Green部署（仅Aurora MySQL支持）；⑦端点设计（Aurora独立Writer/Reader Endpoint）。高可用调优：DNS TTL=1秒、TCP Keep-Alive、JDBC reader/writer端点路由。 +- Concepts created: [[RTO]] +- Entities created: [[Amazon-Aurora]]（Product类实体）、[[Amazon-RDS]]（Product类实体） +- Source page: wiki/sources/ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora.md +- Notes: + - 新增 1 个 Source Page + - 新增 1 个 Concept（RTO，灾备核心指标） + - 新增 2 个 Entity（Amazon-Aurora、Amazon-RDS） + - 冲突检测：与 learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform 存在视角差异——Terraform IaC 部署关注资源标准化，存储选型属运维决策层面，已记录于 Contradictions + - overview.md 更新：新增 CTP Topic 66 摘要段落，更新 Key Entities 和 Key Concepts + +## [2026-04-23] ingest | CTP Topic 14 Octane Hub on AWS Real Life Experience +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services-i.md +- Status: ✅ 成功摄入 +- Summary: Octane Hub CTO Holger Rode 分享将生产服务从 Bibling Lab 数据中心迁移到 AWS Landing Zone 的实战经验。涵盖 Docker 容器化工作负载（QuickSee、Release Manager、Patch Manager 等）、Packer+Terraform/TerraGrunt IaC 演进、EFS vs EBS 存储选型（EFS 不适合数据库，需用 EBS）、VPC Transit Gateway 网络互联、Route 53 DNS 设置。下一步：DR 改进、MSSQL→Postgres 迁移、ECS 演进。 +- Concepts created: [[Docker-Containerization]]、[[EFS-vs-EBS]] +- Entities created: [[Octane-Hub]] +- Source page: wiki/sources/ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services-i.md +- Notes: + - 新增 1 个 Source Page + - 新增 2 个 Concept（Docker-Containerization、EFS-vs-EBS） + - 新增 1 个 Entity（Octane-Hub） + - 冲突检测：与 ctp-topic-7（SaaS Landing Zone 设计）存在视角差异——前者侧重多租户架构，后者侧重单体团队实际迁移路径，已记录于 Contradictions + +## [2026-04-24] ingest | CTP Topic 44 AWS Backup in Micro Focus +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-44-aws-backup-in-micro-focus.md +- Status: ✅ 成功摄入 +- Summary: AWS Backup 托管服务详解，vs Micro Focus 当前分散式快照管理。涵盖四级 DR 策略（Backup and Restore / Pilot Light / Warm Standby / Active-Active），不可变性防勒索软件，法律保留合规，AWS Backup 功能演示（备份保管库、备份计划、时间点恢复），以及当前流程的五大差距。 +- Concepts created: 无（AWS Backup / RTO / RPO / Disaster Recovery / Pilot Light / Warm Standby / Active-Active / Legal Holds 已在 overview Key concepts 中覆盖） +- Entities created: 无（CCIE 门户仅出现1次，不满足创建条件） +- Source page: wiki/sources/ctp-topic-44-aws-backup-in-micro-focus.md +- Notes: + - 新增 1 个 Source Page + - 无新增 Entity/Concept + - 无冲突内容，与 ctp-topic-72、ctp-topic-73 构成递进关系 + +## [2026-04-24] ingest | 实战笔记：本地部署 RSSHub 并获取 YouTube 订阅 +- Source file: Home Office/实战笔记：本地部署 RSSHub 并获取 YouTube 订阅.md +- Status: ✅ 成功摄入 +- Summary: 本地 Docker 部署 RSSHub（diygod/rsshub，端口1200），通过浏览器 view-source 方式获取 YouTube 频道 ID，使用 `/youtube/channel/{channel_id}` 路由生成稳定 RSS 订阅源。相比第三方在线服务，本地部署更稳定可靠。 +- Concepts created: 无（RSSHub 已在 overview Key concepts 中） +- Entities created: 无（diygod 仅出现1次，不满足创建条件） +- Source page: wiki/sources/实战笔记-本地部署-rsshub-并获取-youtube-订阅.md +- Notes: + - 新增 1 个 Source Page + - 无新增 Entity/Concept + - 冲突检测：与 "How to Get the RSS Feed For Any YouTube Channel" 的在线 vs 本地方案略有差异，已记录于 Contradictions + +## [2026-04-24] ingest | Mac必装软件清单 +- Source file: Home Office/Mac必装软件清单-2026-04-17.md +- Status: ✅ 成功摄入 +- Summary: 精选8款Mac必备软件——Claude（AI助手）、Obsidian（AI知识库）、Chrome（浏览器）、Rectangle（分屏工具）、iShot（截图录屏）、Lemon（系统清理）、Raycast（启动器）、Homebrew（包管理器）。核心理念：用最少的软件达到最高的效率。Homebrew 是用 Claude Code 搭 Agent 的前置依赖。 +- Concepts created: 无 +- Entities created: 无 +- Source page: wiki/sources/mac必装软件清单-2026-04-17.md +- Notes: + - 新增 1 个 Source Page + - 无新增 Entity/Concept（软件均不满足创建条件） + - 冲突检测：无冲突 + +## [2026-04-18] ingest | fireworks-tech-graph +- Source file: raw/Skills/fireworks-tech-graph.md +- Status: ✅ 成功摄入 +- Summary: fireworks-tech-graph Claude Code Skill，将自然语言描述转化为精美 SVG 技术图，支持 7 种视觉风格和 14 种 UML 图类型，通过 rsvg-convert 导出 1920px PNG。内置语义形状词汇表和语义箭头系统，确保图形语义一致性。安装：npx skills add yizhiyanhua-ai/fireworks-tech-graph，依赖 librsvg。 +- Concepts created: 7种视觉风格系统、14种UML图、语义形状词汇表、语义箭头系统、技术图生成 +- Entities created: fireworks-tech-graph、rsvg-convert +- Source page: wiki/sources/fireworks-tech-graph.md +- Notes: + - 新增 1 个 Source Page + - 新增 5 个 Concept Page（7种视觉风格系统、14种UML图、语义形状词汇表、语义箭头系统、技术图生成） + - 新增 2 个 Entity Page（fireworks-tech-graph、rsvg-convert） + - 更新 wiki/index.md（Sources + Entities + Concepts 章节追加条目） + - 更新 wiki/overview.md（AI Tools & Prompt Engineering 章节追加条目） + - 无内容冲突 + +## [2026-04-18] ingest | Install WSL +- Source file: raw/Home Office/Install WSL.md +- Status: ✅ 成功摄入 +- Summary: 微软官方 WSL 完整安装指南，`wsl --install` 一键安装，支持 Ubuntu/Debian/SUSE/Kali 等多发行版并行安装，`wsl.exe --set-default-version` 切换 WSL1/WSL2；离线场景通过 MSI + DISM 命令手动启用 Virtual Machine Platform；运行入口推荐 Windows Terminal。与 [[WSL2 启动与网络配置指南]] 互补——前者解决安装，后者解决网络。 +- Concepts created: 无新增（WSL2 已存在于 overview.md，WSL1/WSL安装命令/多发行版支持/离线安装 为 WSL 特定术语，无需独立页面） +- Entities created: 无新增（Microsoft/Ubuntu/PowerShell/Windows Terminal 已存在于 overview.md） +- Source page: wiki/sources/install-wsl.md +- Notes: + - 新增 1 个 Source Page（install-wsl.md） + - 更新 wiki/index.md（Sources 章节追加条目） + - 更新 wiki/overview.md（新增 Install WSL 段落于 Home Server Automation 章节） + - 冲突记录：[[WSL2 启动与网络配置指南]] vs [[Install WSL]] — 侧重点差异，均为互补关系，非矛盾 + +## [2026-04-23] ingest | Obsidian 官方 CLI 命令全景速查表 +- Source file: raw/Skills/Obsidian 官方 CLI 命令全景速查表.md +- Status: ✅ 成功摄入 +- Summary: Obsidian v1.12+ 内置官方 CLI 命令行工具的完整速查表，包含 80+ 条命令覆盖 16 个功能模块（基础操作/数据库/书签/命令面板/日记/文件历史/文件目录/链接网络/大纲/插件管理/属性元数据/发布/随机笔记/全局搜索/官方同步/标签/任务管理/模板/外观样式/卡片盒/仓库管理/内置浏览器/字数统计/工作区布局/开发者模式）。文档还包含 7 个典型自动化应用场景工作流（全局极速闪记、播客知识榨取、AI 收件箱自动分拣、绝对隐私本地 RAG 对话助理、跨平台数据库级联录入、历史知识自动唤醒、批量元数据重构清洗）。 +- Concepts created: 无新增（Obsidian CLI / Obsidian Bases / Zettelkasten / 本地 RAG / 工作流自动化 / 元数据管理 / 快速闪记 均已存在于 overview.md） +- Entities created: 无新增（Obsidian / Obsidian CLI / Dataview / QuickAdd / Templater 已存在于 overview.md 或前次摄入） +- Source page: wiki/sources/obsidian-官方-cli-命令全景速查表.md +- Notes: + - 新增 1 个 Source Page + - 更新 wiki/index.md（Sources 章节追加条目） + - 无内容冲突（与 obsidian-必装-skills 和 obsidian-cli 形成互补） + +## [2026-04-23] ingest | Obsidian 必装 Skills +- Source file: raw/Skills/Obsidian 必装 Skills.md +- Status: ✅ 成功摄入 +- Summary: Obsidian 与 AI Agent 集成的必装 Skills 全景图。覆盖五大方向：①kepano 官方 Skills（defuddle 网页清洗、obsidian-cli 官方 CLI、obsidian-bases .base 数据库）；②Axton 可视化 Skills（obsidian-canvas-creator 径向布局算法、mermaid-visualizer、excalidraw-diagram）；③学术研究工具链（tutor-skills 输入-内化-检测学习闭环、scholar-skill L1/L2/L3 分级论文阅读）；④第三方插件（Claudian 适配 Claude Code、obsidian-agent-client 支持多 Agent）；⑤不推荐工具（obsidian-skill 过时、json-canvas 自动化程度低）。 +- Concepts created: Defuddle, Obsidian-CLI, Obsidian-Bases, Canvas, StudyVault, Scholar-Skill, Tutor-Skills, Claudian, Obsidian-Agent-Client +- Entities created: kepano, Axton, YishenTu, RAIT-09, Choi-Wontak, EESJGong +- Source page: wiki/sources/obsidian-必装-skills.md +- Notes: + - 新增 1 个 Source Page + - 新增 9 个 Concept 页面（Defuddle / Obsidian-CLI / Obsidian-Bases / Canvas / StudyVault / Scholar-Skill / Tutor-Skills / Claudian / Obsidian-Agent-Client） + - 新增 6 个 Entity 页面（kepano / Axton / YishenTu / RAIT-09 / Choi-Wontak / EESJGong） + - 更新 wiki/index.md（Sources / Entities / Concepts 三个章节均已追加条目） + - 更新 wiki/overview.md，补充 Obsidian Skills 生态段落 + - 无内容冲突（与已有 Obsidian 相关文档形成互补） + +- Source file: raw/AI/在 Ubuntu 安装 Ollama 并运行 Qwen2.5‑Coder 7B +- Status: ✅ 成功摄入 +- Summary: Ubuntu 系统上通过官方 install.sh 脚本一键部署 Ollama + Qwen2.5-Coder 7B。涵盖系统要求、安装步骤、服务管理、API 暴露（OLLAMA_HOST=0.0.0.0）、GPU 加速（CUDA 自动检测）、Python/Node.js SDK 调用，以及与 Open WebUI/n8n/OpenClaw 的集成方案。推荐搭配工具：Open WebUI（ChatGPT UI）、n8n（AI 自动化）、LangChain（Agent framework）、OpenClaw（AI coding agent）。qwen2.5-coder:7b 比通用版 qwen2.5:7b 更适合工程任务，因其 Tool usage 能力强、Shell/Python/SQL 理解强、Repo 级代码理解强。 +- Concepts created: 无新增（[[Ollama]]/[[本地大模型部署]]/[[GPU 加速推理]]/[[REST API]] 已存在于 overview.md） +- Entities created: 无新增（[[Open WebUI]]/[[n8n]]/[[OpenClaw]] 已存在于 overview.md） +- Source page: wiki/sources/在-ubuntu-安装-ollama-并运行-qwen2-5‑coder-7b.md +- Notes: + - 新增 1 个 Source Page + - 更新 wiki/index.md Sources 节，追加新条目（按日期排序） + - 更新 wiki/overview.md AI Tools 区域，追加 Qwen2.5-Coder 部署实战段落，关联 [[Ollama 本地 LLM 部署]]（DeepSeek-R1）形成 Ollama 部署双场景覆盖 + - 无需新建 Entity/Concept 页面（相关实体和概念已在 overview.md 中定义） + - 检测冲突：无 + +## [2026-04-16] ingest | Learn AI for free directly from top companies +- Source file: raw/AI/Learn AI for free directly from top companies +- Status: ✅ 成功摄入 +- Summary: @RodmanAi 汇总的 10 家顶级科技公司免费 AI 学习资源直链。涵盖：Anthropic（Skilljar）、Google（Grow.google/AI）、Meta（AI 资源中心）、NVIDIA（CUDA 开发者课程）、Microsoft（Microsoft Learn）、OpenAI（Academy）、IBM（SkillsBuild）、AWS（Skill Builder）、DeepLearning.AI（吴恩达课程）、Hugging Face（学习路径）。 +- Concepts created: 无新增 +- Entities created: [[DeepLearning.AI]], [[IBM]] +- Source page: wiki/sources/learn-ai-for-free-directly-from-top-companies.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/learn-ai-for-free-directly-from-top-companies.md） + - 新增 2 个 Entity 页面：wiki/entities/DeepLearningAI.md, wiki/entities/IBM.md + - 更新 wiki/overview.md Educational Resources 区域，追加免费 AI 学习资源全景介绍 + +## [2026-04-23] ingest | I Went Through Every AI Memory Tool I Could Find. There Are Two Camps. +- Source file: raw/Agent/AI-Memory-Tools-Two-Camps.md +- Status: ✅ 成功摄入 +- Summary: AI 记忆工具全景分类框架。揭示两个根本不同的技术路线：Camp 1（Memory Backend，向量提取+检索，优化召回）vs Camp 2（Context Substrate，文件累积+背景整合，优化复合增长）。代表工具：Mem0、MemPalace（Camp 1）；OpenClaw、Zep、Thoth、TrustGraph（Camp 2）。核心洞察：Zep 从"memory"重塑为"context engineering"是最强市场信号；预测 6 个月内"context engineering"将取代"memory"成为主流术语；持续运行 Agent 必须采用 Context Substrate 架构。 +- Concepts created: [[Context Substrate]], [[Memory Backend]] +- Entities created: [[OpenClaw]], [[Mem0]] +- Source page: wiki/sources/ai-memory-tools-two-camps.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/ai-memory-tools-two-camps.md） + - 新增 2 个 Concept 页面：wiki/concepts/Context-Substrate.md, wiki/concepts/Memory-Backend.md + - 新增 2 个 Entity 页面：wiki/entities/OpenClaw.md, wiki/entities/Mem0.md + - overview.md 新增 ai-memory-tools-two-camps 摘要条目，置于 semantic-memory-search 之后 + - index.md Sources 节新增条目（置顶） + - 冲突记录：与 semantic-memory-search 存在文件优先 vs 向量优先的表面张力，实际互补（已记录） + +## [2026-04-23] ingest | 可自动化、可扩展、AI增强的电商数据采集与处理系统 +- Source file: raw/Others/可自动化、可扩展、AI增强的电商数据采集与处理系统.md +- Status: ✅ 成功摄入 +- Summary: 基于 Docker + Ubuntu + n8n 的可自动化、可扩展、AI增强的电商数据采集与处理系统设计方案。三层架构：爬虫层（Scrapy/Playwright）→ AI处理层（n8n + LLM API）→ 存储展示层（PostgreSQL/MinIO + Grafana）。推荐 Scrapy + Playwright 组合，Docker Compose 容器化；n8n 工作流实现定时爬取→LLM处理→数据库写入→报表通知的全链路自动化；本地可使用 Ollama 无需外部 API Key；防封策略包括 User-Agent 轮换和代理池。 +- Concepts touched: [[Scrapy]], [[Playwright]], [[n8n]], [[Docker Compose]], [[Ollama]], [[Bright Data]], [[Scrapyd]], [[MinIO]], [[Grafana]], [[Metabase]], [[FastAPI]], [[LangChain]] +- Entities touched: [[Amazon]], [[JD]], [[Taobao]], [[Shopee]] +- Source page: wiki/sources/可自动化-可扩展-ai增强的电商数据采集与处理系统.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/可自动化-可扩展-ai增强的电商数据采集与处理系统.md） + - Concept 和 Entity 均以 wikilink 形式建立关联，暂不创建独立页面（已存在于 Wiki） + - 冲突检测：无已知冲突，与 [[scrapy-playwright-抓取tiktok-shop-data]] 同属电商数据采集技术栈 + - 已在 index.md 添加 Source 条目 + - 已在 overview.md TikTok E-commerce Operations 部分新增条目 + +## [2026-04-26] ingest | 电商视频Prompt库 +- Source file: 跨境电商/电商视频Prompt.md +- Status: ✅ 成功摄入 +- Summary: AI 生成宠物电商视频的 7 模块 Prompt 库（产品展示/宠物动作/衣服防穿帮/场景变化/Negative Prompt/卖货文案/全流程示例），以"拼积木"组合方式实现低翻车率 + 高真实感的 TikTok Shop 带货视频生成，扩展至 1产品→3视频→6文案→A/B 测试全链路自动化。 +- Concepts touched: [[Prompt库设计原则]], [[Negative Prompt]], [[Image-to-Video]], [[TikTok电商内容自动化]], [[AI图生视频]] +- Entities touched: [[TikTok Shop]], [[宠物用品]], [[TikTok]] +- Source page: wiki/sources/电商视频prompt.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/电商视频prompt.md） + - Concept 和 Entity 均以 wikilink 形式建立关联，暂不创建独立页面（出现次数 < 2 次阈值） + - 冲突检测：无已知冲突，与 [[AI图生视频工具盘点]]（工具盘点）和 [[做TK跨境思路不对努力白费]]（运营策略）互补 + - 已在 index.md 添加 Source 条目 + - 已在 overview.md 新增 [[电商视频Prompt库]] 小节，链接于 AI图生视频工具盘点 之后 + +## [2026-04-26] ingest | TikTok Shop - Apache Superset Dashboard设计思路 +- Source file: 跨境电商/TikTok Shop - Apache Superset Dashboard设计思路.md +- Status: ✅ 成功摄入 +- Summary: Apache Superset 在 TikTok Shop 电商选品分析场景的完整 Dashboard 设计方案——基于 products/reviews/variations 三表数据，通过 SQL View 预处理 JSON 字段，设计 4-Tab 专业 Dashboard（爆品雷达/类目洞察/店铺监控/评论分析），包含 KPI 卡/散点图/箱线图/热力图等可视化组件，提供选品评分加权公式（sold×0.4 + rating×15 + discount×0.5 + rating_count×0.2）。 +- Concepts created: [[Apache Superset]], [[KPI Card]], [[选品评分公式]], [[SQL View]], [[Dynamic Filter]], [[GMV]], [[Scatter Plot]], [[Box Plot]], [[Heatmap]] +- Entities created: [[TikTok Shop]], [[tiktok_products 数据库]], [[products 表]], [[product_reviews 表]], [[product_variations 表]] +- Source page: wiki/sources/tiktok-shop-apache-superset-dashboard设计思路.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/tiktok-shop-apache-superset-dashboard设计思路.md） + - Concept 和 Entity 均以 wikilink 形式建立关联，暂不创建独立页面（各仅出现 1 次，未达 ≥2 次阈值） + - 冲突检测：无实质冲突，与 [[电商如何选品-如何找到爆款-选品策略]] 互补（策略 vs 数据工具） + - 已在 index.md 添加 Source 条目 + - overview.md 已在 "TikTok E-commerce Product Management" 小节提及 Apache Superset 与 Dashboard 集成，无需额外更新 + +## [2026-04-18] ingest | 做TK跨境思路不对努力白费 +- Source file: 跨境电商/做TK跨境思路不对努力白费.md +- Status: ✅ 成功摄入 +- Summary: TikTok跨境电商全流程实战指南——从市场选择(美区/日本>东南亚)→账号准备→选品策略(数据软件+垂直类目)→店铺运营(流量监控+商品优化)→流量获取(短视频+达人营销)→仓储物流(海外仓+海运补货)→团队建设，提供完整执行框架。 +- Concepts touched: [[跨境电商]], [[选品策略]], [[TikTok电商]], [[达人营销]] +- Entities touched: [[TikTok Shop]], [[美区]], [[日本]] +- Source page: wiki/sources/做tk跨境思路不对努力白费.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/做tk跨境思路不对努力白费.md） + - Concept 和 Entity 均以 wikilink 形式建立关联，暂不创建独立页面（出现次数<2次阈值） + - 冲突检测：无已知冲突内容 + - 已在 index.md 添加 Source 条目 + - 已在 overview.md 新增 "TikTok E-commerce Operations" 小节 + +## [2026-04-23] ingest | 超达物流定价 +- Source file: 跨境电商/超达物流定价.md +- Status: ✅ 成功摄入 +- Summary: 超达物流跨境电商定价规则：申报/实重/材积取最大值计费，UIN渠道24-48h轨迹推送，TK平台面单"TKM"开头单号无效，UIN/TK取消单号收费规则，发货截止时间12点/美区周日休息。 +- Concepts touched: [[计费重量原则]], [[轨迹推送机制]], [[取消单号收费]] +- Source page: wiki/sources/超达物流定价.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/超达物流定价.md） + - Entity 和 Concept 均以 wikilink 形式建立关联，暂不创建独立页面（各仅出现 1 次，未达 ≥2 次阈值） + - 冲突检测：无实质冲突，与 [[TK美国面单授权及操作流程]] 互为补充（前者专注授权配置，本文专注计费规则） + - 已在 index.md 添加 Source 条目 + - overview.md 无需更新（物流定价内容与 AI/软件主题 overview 相关性低） + +## [2026-04-25] ingest | TK美国面单授权及操作流程 +- Source file: 跨境电商/TK美国面单授权及操作流程.md +- Status: ✅ 成功摄入 +- Summary: TikTok美国市场面单授权配置与操作流程截图教程，通过6张Zipline图床备份图片展示具体操作步骤。 +- Concepts touched: [[TikTokShop]], [[面单授权]], [[跨境电商物流]] +- Entities touched: [[TikTok美国站]] +- Source page: wiki/sources/tk美国面单授权及操作流程.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/tk美国面单授权及操作流程.md） + - Concept 和 Entity 均以 wikilink 形式建立关联，暂不创建独立页面（内容为截图教程，信息量有限） + - 冲突检测：无已知冲突内容 + - 已在 index.md 修正 Source 条目 + - overview.md 无需更新（物流操作类内容与 overview 主题相关性低） + +## [2026-04-24] ingest | Scrapy + Playwright 抓取TikTok Shop Data +- Source file: 跨境电商/Scrapy + Playwright 抓取TikTok Shop Data.md +- Status: ✅ 成功摄入 +- Summary: 使用 Scrapy + Playwright 技术栈抓取 TikTok Shop 商家数据的环境配置与运行指南。涵盖 Python venv 虚拟环境搭建、scrapy-playwright 依赖安装、Chromium 浏览器安装、Docker 容器化部署配置，以及 Playwright 验证方法。 +- Concepts touched: [[Scrapy]], [[Playwright]], [[scrapy-playwright]], [[venv]], [[Docker]], [[Chromium]] +- Entities touched: [[TikTok Shop]], [[shenwei]] +- Source page: wiki/sources/scrapy-playwright-抓取tiktok-shop-data.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/scrapy-playwright-抓取tiktok-shop-data.md） + - Concept 和 Entity 均以 wikilink 形式建立关联，暂不创建独立页面（各仅出现 1 次，未达 ≥2 次阈值） + - 冲突检测：无已知冲突内容 + - 已在 index.md 添加 Source 条目 + - overview.md 无需更新（TikTok Shop 已存在于 Key Entities，Scrapy/Playwright 属技术工具不需独立概念页） + +## [2026-04-23] ingest | GOG CLI 安装配置指南 +- Source file: Skills/GOG-CLI-安装配置指南.md +- Status: ✅ 成功摄入 +- Summary: gog CLI（Google Workspace 命令行工具）在 macOS 系统上的完整安装与配置流程。涵盖 Homebrew 安装、OAuth 凭证配置、测试用户白名单添加、Google API 启用、常用命令速查及故障排除。 +- Concepts touched: [[OAuth 2.0]], [[Google Cloud Console]], [[API Enablement]], [[Google Workspace]] +- Entities touched: [[gog CLI]] +- Source page: wiki/sources/gog-cli-安装配置指南.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/gog-cli-安装配置指南.md） + - 新增 1 个 Entity Page（wiki/entities/gog-CLI.md） + - 冲突检测：无已知冲突内容 + - 已在 index.md 修正 Source 条目（去除 "(expected: source missing)" 标注） + - 已在 overview.md Key Entities 添加 [[gog CLI]] 条目 + - 已在 overview.md Key Concepts 添加 [[OAuth 2.0]], [[Google Cloud Console]], [[API Enablement]] + + +- Source file: Skills/Last30Days-使用指南.md +- Status: ✅ 成功摄入 +- Summary: Last30Days 方法论——通过 AI Agent 自动化追踪近30天内新增/更新的内容源，避免信息过载。核心价值：将"主动订阅"转变为"被动接收"，用 AI 替代人工巡检，节省 80% 信息搜集时间。 +- Concepts touched: [[Last 30 Days Method]], [[信息消费习惯]] +- Entities touched: [[Last30Days]] +- Source page: wiki/sources/last30days-使用指南.md +- Notes: + - 新增 1 个 Source Page + - Concept 和 Entity 均以 wikilink 形式建立关联，暂不创建独立页面 + - 冲突检测：无已知冲突内容 + - 已在 index.md 添加 Source 条目 + - overview.md 无需更新（Last 30 Days Method 已存在于 Key Concepts） + +## [2026-04-25] ingest | 如何利用Sora接口实现视频自动化生成工作流 +- Source file: AI/如何利用Sora接口实现视频自动化生成工作流.md +- Status: ✅ 成功摄入 +- Summary: 利用亚马逊 Bedrock 平台的 Sora API 实现视频生成全自动化工作流，覆盖注册→API调用→批量生成完整流程。成本仅 2-3 元人民币，远低于市场水平；新用户享 200 美元抵扣金和 6 个月免费试用；支持文本转视频和图像生成，可结合 n8n 实现批量 UGC 内容生产。 +- Concepts touched: [[文字生成视频]], [[提示词优化]], [[肖像权合规]], [[n8n 工作流自动化]], [[UGC内容]] +- Entities touched: [[Sora]], [[亚马逊 Bedrock]], [[n8n]] +- Source page: wiki/sources/如何利用sora接口实现视频自动化生成工作流.md +- Notes: + - 新增 1 个 Source Page + - Concept 和 Entity 均已在 Source Page 中以 wikilink 形式建立关联，暂不创建独立页面（各出现 1 次，未达 ≥2 次阈值） + - 冲突检测：无已知冲突内容 + - 已在 index.md 添加 Source 条目 + +## [2026-04-25] ingest | If You Have Multiple Interests, Do Not Waste the Next 2-3 Years +- Source file: AI/If you have multiple interests, do not waste the next 2-3 years 如果你有多项兴趣爱好，不要浪费接下来的两三年时间。.md +- Status: ✅ 成功摄入 +- Summary: 系统论证多重兴趣是AI时代超能力的个人发展指南——核心主张：工业化专业化分工使人类沦为"愚蠢而依赖"的螺丝钉，第二次文艺复兴已经到来；个人成功三要素（自学+自利+自立）自然涌现通才型人才；品牌内容系统、创意密度方法论、系统经济是具体路径 +- Concepts created: [[Generalist]], [[Self-Education]], [[Self-Interest]], [[Self-Sufficiency]], [[Second-Renaissance]], [[Idea-Density]], [[Idea-Museum]], [[Brand-Environment]], [[Content-Creator]], [[System-Economy]], [[Attention-Economy]] +- Entities created: [[AdamSmith]], [[LeonardoDaVinci]] +- Source page: wiki/sources/if-you-have-multiple-interests-do-not-waste-the-next-2-3-years-如果你有多项兴趣爱好-不要浪费接下来的两三年时间.md +- Notes: + - 新增 1 个 Source Page、5 个 Concept 页面、2 个 Entity 页面 + - Concepts 全部符合"可抽象可复用"原则，创建独立页面 + - Entities: Adam Smith（≥2次引用分工理论）、Leonardo da Vinci（文艺复兴通才典范）均符合创建条件 + - 冲突检测：与 [[Multi-Agent System Reliability]] 的 Generalist 概念高度互补（后者从系统可靠性角度） + - 已在 overview.md 个人品牌与一人公司段落添加新来源摘要 + - 已在 index.md 添加 11 个 Concept 条目、2 个 Entity 条目 + +## [2026-04-25] ingest | 我用 Gemini 3 一口气做了 10 个应用，附教程 +- Source file: AI/我用 Gemini 3 一口气做了 10 个应用，附教程.md +- Status: ✅ 成功摄入 +- Summary: 使用 Google Gemini 3 模型通过三步方法论（限定垂直场景→提示词约束结构化输出→前端SVG容器）快速构建 10 个可视化应用。核心发现：AI 生成 SVG 代码+前端渲染是快速交付 AI 应用的关键路径。 +- Concepts touched: [[SVG可视化]], [[结构化输出]], [[Vibe-Coding]], [[AI应用开发]] +- Entities touched: [[Gemini-3]]（出现1次，不满足≥2次条件，暂不创建独立Entity页） +- Source page: wiki/sources/我用-gemini-3-一口气做了-10-个应用-附教程.md +- Notes: + - 新增 1 个 Source Page + - 已在 overview.md 添加 Gemini 3 十应用实战 段落，连接到 [[Vibe-Coding]] + - 已更新 index.md 条目（日期从 2026-04-18 更新为 2026-04-23） + - Entity 检查：Gemini-3 仅在本文出现，未达"出现≥2次"阈值，暂不创建独立页面 + - Concept 检查：SVG可视化/结构化输出等均未达"可抽象可复用"独立成页条件，暂纳入 Source Page Key Concepts + - 冲突检测：无冲突内容 + +## [2026-04-25] ingest | Multi-Agent System Reliability +- Source file: AI/Multi-Agent System Reliability.md +- Status: ✅ 成功摄入 +- Summary: 介绍4种提升多智能体系统可靠性的架构模式（Hierarchy/Consensus/Adversarial Debate/Knock-out），核心主张：停止拟人化LLM，将其视为分布式系统中不可靠的组件，通过架构约束而非提示词约束强制正确性 +- Concepts created: [[Hierarchy-Agent-Pattern]], [[Consensus-Voting-Pattern]], [[Adversarial-Debate-Pattern]], [[Knock-out-Pattern]], [[Tree-of-Thoughts]], [[Genetic-Algorithm]], [[Reliability-Engineering]] +- Entities created: [[Alex Ewerlöf]] +- Entities updated: 无（Alex Ewerlöf 为新实体） +- Source page: wiki/sources/multi-agent-system-reliability.md +- Notes: + - 新增 1 个 Source Page、1 个 Entity 页面、7 个 Concept 页面 + - Alex Ewerlöf Entity 在源文件中出现 ≥2 次（作者署名+引用），符合创建条件 + - 7 个 Concept 均符合"可抽象、可复用"原则，全部创建独立页面 + - 冲突检测：与 [[Designing for Agentic AI]] 互补而非冲突；与 [[Recursive Self-Optimization]] 共享自引用结构思想；与 [[Genetic-Algorithm]] 有明确关联（Knock-out 是 GA 的精简实现） + - 已在 overview.md Key Concepts 列表添加所有 7 个新概念 + - 已在 overview.md Key Entities 列表添加 [[Alex Ewerlöf]] + +## [2026-04-24] ingest | 全网最全！Nano Banana 2 使用指南（2025年12月更新） +- Source file: AI/全网最全！Nano Banana 2 使用指南（2025年12月更新） 1.md +- Status: ✅ 成功摄入 +- Summary: 介绍 Google Nano Banana 2（Gemini 3 Pro Image）推理型图像生成模型的国内使用方法，通过 DeepSider 浏览器插件实现无 VPN 直连访问，同时支持数十款 AI 大模型 +- Concepts created: 无（本次概念不足以独立建页） +- Entities created: [[DeepSider]], [[Nano Banana 2]] +- Entities updated: [[Google]]（新增 Nano Banana 2 产品信息） +- Source page: wiki/sources/全网最全-nano-banana-2-使用指南-2025年12月更新-1.md +- Notes: + - Nano Banana 2 与 [[Nano Banana Pro]] 为不同版本，Nano Banana 2 为更新版（2025年12月发布） + - [[Nano Banana Pro]] 已在 [[Google.md]] entity 中提及，本次新增 [[Nano Banana 2.md]] entity 独立页面 + +## [2026-04-24] ingest | 2025 年 11 个神级 AI 开源平替，GitHub 杀疯了 +- Source file: AI/2025 年 11 个神级 AI 开源平替，GitHub 杀疯了。.md +- Status: ✅ 成功摄入 +- Summary: 按 8 大领域（LLM/AI生图/生视频/AI智能体/AI编码/工作流/AI搜索/AI知识库）系统盘点 GitHub 上各领域最火的开源平替项目，核心洞察：国产开源模型在多领域达到或超越国际闭源竞品水平 +- Concepts created: [[AI开源平替]] +- Entities created: [[Flux]], [[HunyuanVideo]], [[Manus]], [[OpenManus]], [[Cline]], [[Perplexica]], [[Dify]], [[Stable Diffusion]] +- Entities updated: [[DeepSeek]], [[Qwen]], [[n8n]] +- Source page: wiki/sources/2025-年-11-个神级-ai-开源平替-github-杀疯了.md +- Notes: + - DeepSeek、Qwen、n8n 已在 Wiki 中存在，本次仅追加新版本信息 + - Flux（≥2次）、HunyuanVideo（≥2次）、Manus（≥2次）、OpenManus（≥2次）、Cline（≥2次）、Perplexica（≥2次）、Dify（≥2次）、Stable Diffusion（≥2次）均出现 ≥2 次，符合创建条件 + - OpenAI、MiniMax、Kimi K2、智谱 GLM 仅出现 1 次，未达到创建阈值 + - Perplexity 作为对比对象出现，但非本文主角，不创建独立页面 + - 冲突检测：内容与现有 Wiki 中 DeepSeek、n8n 等实体描述一致，无冲突 + - Meta 收购 Manus 是 2025 年重大事件，已体现在 [[Manus]] 实体页 + +## [2026-04-23] ingest | AI 解决方案专家培训课程 +- Source file: AI/AI 解决方案专家培训课程.md +- Status: ✅ 成功摄入 +- Summary: Coze 平台多行业 AI Agent 培训课程，涵盖国内版（coze.cn）和海外版（coze.com），提供覆盖金融、医疗、教育、电商、人力资源、泛娱乐、在线客服等 7 大行业共 50+ 可体验 Agent Demo，核心技术栈为 Prompt 工程、RAG、Function Call 和 Workflow 编排。 +- Concepts created: [[Coze-Workflow]] +- Entities created: [[Coze]], [[SONY]], [[滴滴]] +- Source page: wiki/sources/ai-解决方案专家培训课程.md +- Notes: + - Coze、SONY、滴滴三个实体在源文件中均出现 ≥2 次，符合创建条件 + - FaceFusion、F5-TTS、World Labs、抖音仅出现 1 次，未达到创建阈值（≥2次） + - Prompt Engineering、Function Call、Workflow Engineering 等核心概念已存在于 Wiki，本次作为 Key Concepts 引用 + - 冲突检测：Coze 平台与其他 AI 工具（Claude Code、Ollama 本地部署）属互补关系，无内容冲突 + +- Source file: AI/RAG从入门到精通系列1：基础RAG.md +- Status: ✅ 成功摄入 +- Summary: RAG 基础原理与实战：Indexing（文档加载→切分→向量化入库）→ Retrieval（向量相似度 Top-k 检索）→ Generation（问题+上下文→LLM 生成答案），Qwen+BAAI+LangChain+Qdrant 实战工具链。 +- Concepts created: [[Indexing]], [[Retrieval]], [[Generation]], [[Split]], [[Context-Window]] +- Entities created: [[LangChain]], [[Qwen]], [[Qdrant]] +- Source page: wiki/sources/rag从入门到精通系列1-基础rag.md +- Notes: + - RAG 概念页面 [[RAG]] 已存在于 wiki/concepts/RAG.md，已在 Source Page 中正确引用 + - 冲突检测：基础 RAG（Naive RAG）与 Advanced RAG / RAG Fusion 存在优化方向差异，待后续进阶内容补充后更新 Contradictions + - [[PyTorch研习社]] 为文章来源方，raw 文档中有注明，Source Page Key Entities 已记录 + - BAAI（Embedding Model）和 LlamaIndex 在 Source Page 中作为 Key Entities 记录，暂未创建独立 Entity 页面 + +## [2026-04-23] ingest | 固定镜头短视频制作的AI全流程解析 +- Source file: AI/固定镜头短视频制作的AI全流程解析.md +- Status: ✅ 成功摄入 +- Summary: 利用 AI 技术快速制作高播放量固定机位家装类短视频的全流程方法论，涵盖分镜拆解（Google AI Studio）、九宫格图像生成（Midjourney/Nano Banana）、首尾针动画（海螺AI/KAI）、快节奏剪辑（剪映）、声音设计五大步骤，10 分钟内完成成片。 +- Concepts created: [[固定机位]], [[首尾针动画]], [[九宫格法]] +- Entities created: [[Midjourney]], [[KAI]], [[剪映]] +- Source page: wiki/sources/固定镜头短视频制作的ai全流程解析.md +- Notes: + - 冲突检测：与传统视频制作理念（复杂镜头语言+丰富转场）存在冲突，已记录至 Source Page Contradictions 部分 + - Google/Nano Banana 实体已存在于 wiki/entities/Google.md，已在 Source Page Key Entities 中正确引用 + - 海螺AI 仅为提及（非关键工具），未创建独立 Entity 页面 + - 快节奏剪辑、卡点、内容连续变化、时间压缩等为描述性术语，不满足"可抽象可复用"原则，未创建独立 Concept + +## [2026-04-25] ingest | 大模型相关术语和框架总结｜LLM、MCP、Prompt、RAG、vLLM、Token、数据蒸馏 +- Source file: AI/大模型相关术语和框架总结｜LLM、MCP、Prompt、RAG、vLLM、Token、数据蒸馏.md +- Status: ✅ 成功摄入 +- Summary: 大模型生态核心术语入门速查手册，涵盖 LLM、Prompt、MCP、Agent、RAG、Embedding、LangChain、vLLM、Token、数据蒸馏等概念，用通俗语言和可视化类比解释大模型领域关键术语 +- Concepts created: [[Model Context Protocol]], [[vLLM]], [[LangChain]] +- Concepts updated: [[Large Language Model]]（添加来源引用）, [[AI Agent]]（添加 Model Context Protocol 关联 + 来源引用）, [[RAG]]（已包含来源） +- Entities identified: 无（shenwei 仅在本文出现 1 次，不满足 ≥2 次条件；OpenAI/vLLM 社区仅为引用来源，不满足关键影响条件） +- Source page: wiki/sources/大模型相关术语和框架总结｜llm-mcp-prompt-rag-vllm-token-数据蒸馏.md +- Notes: + - 冲突检测：与 [[llms-rag-ai-agent-三个到底什么区别]] 属互补关系（术语科普 vs 三层架构梳理），已记录至 Source Page Contradictions 部分 + - 无需创建 shenwei Entity（仅出现 1 次，不满足 ≥2 次条件） + - vLLM.md 中 KV Cache/PagedAttention/Continuous Batching 等子概念不单独创建页面，因其属于 vLLM 框架的内部技术细节，不满足"可抽象、可复用"原则 + - Embedding 已存在 [[Vector-Embedding]] Concept，LangChain 为框架类概念（已有充分讨论） + +## [2026-04-25] ingest | Nano Banana Pro 提示词指南与策略（上篇） +- Source file: AI/Nano-Banana Pro Prompting Guide & Strategies 1.md +- Status: ✅ 成功摄入 +- Summary: Google Nano Banana Pro 官方提示词指南上篇，涵盖 10 条黄金法则（编辑而非重生成、使用自然语言、提供上下文等）和前 9 个能力域（文本渲染/信息图、角色一致性/身份锁定、Google Search 信息锚定、高级编辑/修复/着色、2D/3D 维度转换、高分辨率/纹理、思考推理模式、故事板/概念艺术、结构控制/布局引导），附大量可直接复制的实战提示词模板。 +- Concepts identified: 无（Nano Banana Pro 特有概念均为具体应用技术，不满足可复用抽象原则） +- Entities identified: [[Google]]（已存在于 wiki/entities/Google.md，已更新 Key Products 添加 Google AI Studio / Nano Banana Pro / Google Colab） +- Source page: wiki/sources/nano-banana-pro-prompting-guide-strategies-1.md +- Notes: + - index.md 已修复旧条目（移除 expected/missing 标注，替换为完整标题和摘要） + - overview.md 已更新「Nano Banana Pro 提示词指南」段落，明确标注本文为上篇及涵盖的 9 个能力域 + - 冲突检测：与 [[全网最全-nano-banana-2-使用指南-2025年12月更新-1]] 存在范围重叠，已记录至 Source Page Contradictions 部分，结论为互补而非冲突 + - 无需新建 Entity 页面（shenwei 作者仅在本文出现 1 次，不满足 ≥2 次条件） + - 无需新建 Concept 页面（身份锁定/对话式编辑等为 Nano Banana Pro 特有应用技术，不满足可复用抽象条件） + +- Source file: AI/我的工具集.md +- Status: ✅ 成功摄入 +- Summary: 个人 AI 工具推荐清单，按类型分类（Text-to-Speech / Image-Editor / Image-to-Video / Web-Scraper / AI-Summary），覆盖 Google AI Studio（Wavespeed 图生视频、Vidu、海螺 AI）、Brightdata（网页爬取）、Decopy（AI 摘要）等服务。与 AI图生视频工具盘点属互补关系——本文为工具索引，后者为免费工具详细评测。 +- Concepts identified: 无（工具索引类来源，各概念已在其他来源中有充分讨论） +- Entities identified: [[Google]]（已存在于 wiki/entities/Google.md） +- Source page: wiki/sources/我的工具集.md +- Notes: + - 更新 index.md Sources 部分（替换 expected 标记行） + - 更新 overview.md AI Tools & Prompt Engineering 部分（新增「我的工具集」段落） + - Google Entity 已存在，无需重复创建 + - Vidu/海螺AI/Wavespeed/Brightdata/Decopy 仅在本文中出现 1 次，不满足 Entity ≥2 次创建条件 + - 无需新建 Concept 页面（各工具类型概念在其他来源中已充分覆盖） + - 冲突检测：与 [[二创视频必不可少-2025年最热门ai工具推荐合集-ai配音-声音克隆]] 存在互补关系（工具清单 vs 详细评测），已记录至 Source Page Contradictions 部分 + +## [2026-04-24] ingest | 如何写出完美的Prompt（提示词）？ +- Source file: AI/如何写出完美的Prompt（提示词）？.md +- Status: ✅ 成功摄入 +- Summary: 系统阐述 Prompt 构建底层逻辑的职场应用指南。核心理念：Prompt 是人与 AI 的协作协议，本质是将模糊需求转化为 AI 可执行的结构化任务。四大构建要素（角色+需求+场景+目标）+ 三层技巧体系（基础：需求拆解/上下文补全/格式定义/示例引导；进阶：思维链/任务拆分/角色赋能/预填回复/不确定性管理；高阶：跨模态联动/领域知识注入/反馈循环嵌入）+ 四大业务场景实战模板（内容创作/数据分析/方案策划/客户服务）+ 六大避坑指南。核心洞察：Prompt 能力本质 = 对问题清晰界定的能力 + 结构化思维逻辑和表达能力。 +- Concepts identified: [[结构化思维]], [[精准表达]], [[思维链引导]], [[任务拆分法]], [[角色赋能法]], [[少量样本提示]], [[上下文补全]], [[AI Agent]]（本篇提供了 AI Agent 能力的底层基础） +- Entities identified: [[粒粒]]（微信公众号作者） +- Source page: wiki/sources/如何写出完美的prompt-提示词.md +- Notes: + - 该文档与 [[清华出的DeepSeek使用手册]]（DeepSeek 特定实践）和 [[系统提示词构建原则]]（Agent 系统级指令）互补，构成完整的提示词工程方法论体系 + - 冲突检测：与 [[系统提示词构建原则]] 存在视角差异（用户层 vs Agent 设计层），已在 Source 页面的 Contradictions 部分说明互补关系 + - index.md 已修复旧条目（移除 "— (expected: ... — source missing)" 标注，添加实际摘要） + - overview.md 已新增 "AI Tools & Prompt Engineering" 部分的条目 + +## [2026-04-24] ingest | 系统提示词构建原则 +- Source file: AI/系统提示词构建原则.md +- Status: ✅ 成功摄入 +- Summary: AI 编程助手的系统提示词构建原则，涵盖五大维度：核心身份与行为准则（遵守项目约定、优先技术准确性）、沟通与互动规范（专业简洁、减少冗余）、任务执行工作流（TODO规划、Search/Replace编辑）、技术编码规范（清晰命名、模块化）、安全防护准则（不泄露指令、输入验证）。来源：vibe-coding-cn 项目。 +- Concepts updated: [[Vibe Coding]]（sources 字段补充该来源） +- Entities updated: [[tukuai]]（sources 字段补充该来源） +- Source page: wiki/sources/系统提示词构建原则.md +- Notes: + - 该文档与 [[github-上-5000-人收藏的-vibe-coding-神级指南]] 同属 vibe-coding-cn 项目，是操作层指南的补充 + - 冲突检测：无已知冲突 + - overview.md 中"Vibe Coding 中文指南"段落已补充与该来源的链接 + +## [2026-04-24] ingest | GitHub 上 5000 人收藏的 Vibe Coding 神级指南 +- Source file: AI/GitHub 上 5000 人收藏的 Vibe Coding 神级指南。.md +- Status: ✅ 成功摄入 +- Summary: 介绍 vibe-coding-cn 开源项目（github.com/tukuaiai/vibe-coding-cn），为中文开发者汇集全球顶尖 AI 编程资源。核心公式：Vibe Coding = 规划驱动 + 上下文固定 + AI 结对执行。工具推荐：Cursor + Claude Opus。核心理念：规划就是一切——让 AI 写代码前必须先完成技术选型、实施规划和模块化设计。Karpathy 经典语录："我几乎不写代码了，我只负责调整氛围（Vibe），代码会自动长出来。" +- Concepts updated: [[Vibe Coding]]（补充规划驱动/上下文固定/AI 结对执行三大原则、Vibe Coding vs Claude Skills 对比表、添加 Windsurf/Trae 工具推荐） +- Entities created: [[Andrej-Karpathy]]（AI 领域知名专家，Vibe Coding 概念推广者） +- Entities updated: [[tukuai]]（补充 vibe-coding-cn 仓库贡献者身份） +- Source page: wiki/sources/github-上-5000-人收藏的-vibe-coding-神级指南.md +- Notes: + - 更新 index.md Sources 部分（在首位插入新条目，移除 expected 占位条目） + - 更新 overview.md，添加"Vibe Coding 中文指南"段落至 AI Tools & Prompt Engineering 部分 + - 更新 index.md Entities 部分（添加 Andrej-Karpathy 条目） + - Vibe Coding 概念页面已存在，本次更新 sources 字段和核心原则内容 + - 冲突检测：Vibe Coding（氛围感/直觉式）与 Claude Skills（结构化 SOP）存在视角差异，已记录至 source page Contradictions 部分 + +## [2025-12-18] ingest | 不会Gemini的产品经理真的要被淘汰了 | 附保姆级PRD生成指南 +- Source file: AI/不会Gemini的产品经理真的要被淘汰了 附保姆级PRD生成指南.md +- Status: ✅ 成功摄入 +- Summary: 产品经理Kira2red分享大模型（Gemini）辅助PRD生成的保姆级教程——三步工作流：①用FeatureList构思需求框架（大模型生成层级式功能表）、②Mermaid画逻辑图（ER图/时序图/泳道图辅助理解）、③分页面逐一描述生成PRD+HTML原型。核心方法论："人负责想，大模型负责写"，可缩短文档工作时间90%以上。深层洞察：未来可能不需要PRD文档，产品经理需进化为"超级个体"，核心能力是市场洞察而非写文档。 +- Concepts created: [[FeatureList]], [[超级个体]], [[PRD生成工作流]] +- Entities updated: [[Gemini]]（关联本文工作流） +- Source page: wiki/sources/不会gemini的产品经理真的要被淘汰了-附保姆级prd生成指南.md +- Notes: + - 更新 index.md Sources 部分（在首位插入新条目） + - 更新 overview.md AI Tools & Prompt Engineering 小节（补充AI辅助PRD生成条目） + - Vibe Coding Concept 已存在（无需新建） + - FeatureList、超级个体、PRD生成工作流为新创建 Concept + - 无内容冲突 + +## [2026-04-23] ingest | 3.2 万人收藏的 Claude Skills，才是 AI 这条路上最值得研究的一套范式！ +- Source file: AI/3.2 万人收藏的 Claude Skills，才是 AI 这条路上最值得研究的一套范式！ 1.md +- Status: ✅ 成功摄入 +- Summary: Anthropic 官方 Claude Skills 仓库（github.com/anthropics/skills，3.2 万收藏）介绍。Skills = 写给 Claude 的"说明书" + "SOP"，将反复执行的有固定流程的任务拆解为 AI 能理解、能复用、能自动执行的一套流程。官方库包含三大类：办公自动化（Word/PDF/PPT/Excel）、开发者工具箱（MCP Server/自动化测试/Artifacts 构建）、创意类 Skill。核心洞察：Claude Skills 的爆发标志着从「提示词工程」向「流程工程」的范式转变；Vibe Coding 的尽头也是 Skills。 +- Concepts created: [[Claude Skills]], [[Workflow Engineering]] +- Source page: wiki/sources/3-2-万人收藏的-claude-skills-才是-ai-这条路上最值得研究的一套范式-1.md +- Notes: + - 更新 index.md Sources 部分（修正 source missing 条目） + - 更新 overview.md AI Tools & Prompt Engineering 小节（添加 Claude Skills 范式洞察） + - 创建 Claude-Skills 和 Workflow-Engineering 两个 Concept 页面 + - 添加 Concepts 条目到 index.md（Claude-Skills、Workflow-Engineering） + - 无内容冲突 + - Entity 页面（Anthropic/skillsmp/aitmpl 等）出现次数均 <2 次，未创建 +- Source page: wiki/sources/7-ways-i-use-notebooklm-to-make-my-life-easier.md +- Notes: + - 更新 index.md Sources 部分（替换 expected 占位条目）和 Concepts 部分（新增2个条目） + - 更新 overview.md AI Tools & Prompt Engineering 小节（补充 NotebookLM 7种用法条目） + - NotebookLM Entity 页面已存在，更新 sources 字段和内容 + - Source-Grounding 和 Passive-Learning 为新建 Concept 页面 + - 冲突检测：未发现与其他 Wiki 页面存在明显内容冲突 + +## [2026-04-24] ingest | Never write another prompt +- Source file: AI/Never write another prompt.md +- Status: ✅ 成功摄入 +- Summary: 介绍一款能将简单描述自动转化为详细结构化提示词的 AI 工具，支持变量插入和自定义编辑，大幅降低提示词工程门槛。与 Claude Prompt Library（现成提示词库）和 Nano Banana 提示词框架（结构化模板）同属提示词工程的不同路径。 +- Concepts covered: [[Prompt Engineering]], [[API Key]], [[Variables in Prompts]] +- Entities referenced: [[ChatGPT]], [[Google Gemini]] +- Source page: wiki/sources/never-write-another-prompt.md +- Notes: + - 更新 index.md Sources 部分（新增条目，按日期排序） + - 更新 overview.md AI Tools & Prompt Engineering 小节 + - 冲突检测：与 useful-prompt-lib.md 存在"是否需要预制提示词"视角差异（双方 Contradictions 均已记录） + - ChatGPT/Google Gemini 已存在于 Wiki，无需新建 Entity 页面 + +## [2026-04-23] ingest | Best 7 news API data feeds - AI News +- Source file: AI/Best 7 news API data feeds - AI News.md +- Status: ✅ 成功摄入 +- Summary: 7款主流新闻API横向评测（Webz.io/GNews/The Guardian/Bloomberg/Financial Times/Opoint/Mediastack），覆盖开放网/深网/暗网数据、金融情报、舆情监控、情感分析、内容聚合、AI预测分析等应用场景，为AI应用和数据分析场景选择新闻数据接口提供选型参考。 +- Concepts covered: [[News API]], [[Financial Intelligence]], [[Media Monitoring]], [[Sentiment Analysis]], [[Risk Assessment]], [[Content Aggregation]], [[Predictive Analysis]] +- Entities referenced: [[Webz.io]], [[GNews API]], [[The Guardian API]], [[Bloomberg API]], [[Financial Times API]], [[Opoint]], [[Mediastack API]] +- Source page: wiki/sources/best-7-news-api-data-feeds-ai-news.md +- Notes: + - 更新 index.md Sources 部分 + - 7个 Entity 均仅出现1次，未创建独立 Entity 页面 + - Concept 均为通用概念，已隐式覆盖，无冲突 + +## [2026-04-23] ingest | Claude Prompt Library 汇总表 +- Source file: AI/Useful Prompt Lib.md +- Status: ✅ 成功摄入 +- Summary: Anthropic Claude 官方提示词库完整汇总，收录 64+ 款专业化提示词，覆盖开发工具、效率工具、创意工具、营销工具、教育工具等 10+ 领域。TikTok 跨境电商推荐 Babel's Broadcasts（多语言推文）、Review Classifier（评论分类）、Data Organizer（非结构化→JSON）三剑客。 +- Concepts covered: [[Anthropic Prompt Library]], [[Babel's Broadcasts]], [[Review Classifier]], [[Data Organizer]], [[Prompt Engineering]] +- Entities referenced: [[Anthropic]], [[TikTok]] +- Source page: wiki/sources/useful-prompt-lib.md +- Notes: + - 更新 index.md Sources 部分 + - 更新 overview.md AI Tools & Prompt Engineering 小节 + - Anthropic/TikTok 均仅出现1次，未创建独立 Entity 页面 + - 冲突检测：与 never-write-another-prompt.md 存在"是否需要预制提示词"的冲突（已记录至 source page Contradictions 部分） + +## [2026-04-23] ingest | 二创视频必不可少！2025年最热门AI工具推荐合集-AI配音、声音克隆 +- Source file: AI/二创视频必不可少！2025年最热门AI工具推荐合集-AI配音、声音克隆.md +- Status: ✅ 成功摄入 +- Summary: 2025年AI配音及声音克隆工具推荐合集，评测ElevenLabs、海螺AI（MiniMax）、F5-TTS、TTSMaker、剪映、魔音工坊、AnyVoice等7款主流工具。涵盖免费/付费、国际/国内、技术门槛等多维度对比，为不同用户群体提供选型建议。 +- Concepts covered: [[AI配音]], [[声音克隆]] +- Entities referenced: [[ElevenLabs]], [[海螺AI]], [[F5-TTS]], [[TTSMaker]], [[剪映]], [[魔音工坊]], [[AnyVoice]], [[MiniMax]] +- Source page: wiki/sources/二创视频必不可少-2025年最热门ai工具推荐合集-ai配音-声音克隆.md +- Notes: + - 更新 index.md Sources 部分 + - Entity/Concept 均未创建独立页面（各工具仅在本文出现一次，不满足Entity≥2次条件；AI配音/声音克隆概念在其他来源中已有相关讨论，可后续扩展） + +## [2026-04-23] ingest | The Picture They Paint of You +- Source file: AI/The Picture They Paint of You.md +- Status: ✅ 成功摄入 +- Summary: 探讨 AI 工具的市场定位如何折射对人类工作者的隐性认知。对比 10+ 款 AI SRE 产品和 8+ 款 Coding Assistant 的营销话语，发现：AI SRE 被建构为"替代者"，Coding Assistant 被建构为"合作伙伴"。这种差异映射了组织内部对不同角色真实价值的认知分裂，暗示决策者与从业者之间对工作意义理解的根本分歧。 +- Concepts created: [[Taylorism]], [[Left-over-Principle]], [[Analogy-as-Straitjacket]] +- Source page: wiki/sources/the-picture-they-paint-of-you.md +- Notes: + - 新增 Sources 条目至 index.md + - 新增 3 个 Concept 页面：Taylorism.md、Left-over-Principle.md、Analogy-as-Straitjacket.md + - 冲突检测：与 wiki/sources/what-i-know-about-cloud-service-delivery-1.md 中 SRE 角色认知存在冲突（已记录至 source page Contradictions 部分） + - Entities: Anthropic、GitHub Copilot、OpenAI Codex、Cline、AWS DevOps Agent 均未创建独立页面（属产品类 Entity，命名类 Entity 价值待定） + +## [2026-04-23] ingest | Nano Banana 提示词框架 +- Source file: AI/Nano Banana 提示词框架.md +- Status: ✅ 成功摄入 +- Summary: AI 图像生成的结构化提示词框架，提供两套 JSON Schema 模板——物件描述框架（item / materials / details / condition）和人物描述框架（age / appearance / pose）——共用 shot / environment / lighting / camera / color_grade / style / quality / negatives 参数字段。示例展示了如何将专业摄影描述语言（材质/布光/相机参数）结构化填入模板。 +- Concepts covered: [[Nano Banana Prompting Framework]], [[Structured Prompt Engineering]], [[Negative Prompting]], [[Shot Composition]], [[Photography Lighting Description]], [[Camera Parameter Specification]] +- Entities referenced: [[Google]], [[Nano Banana]] +- Source page: wiki/sources/nano-banana-提示词框架.md +- Notes: + - 新增 Sources 条目至 index.md（替换 expected 标记行） + - 更新 overview.md AI Tools & Prompt Engineering 部分 + - Google Entity 已存在于 wiki/entities/Google.md，未重复创建 + +## [2026-04-23] ingest | 谷歌深夜甩出一份【Nano Banana Pro提示词指南】，手把手教你生产专业级内容，实战案例+提示词模版 +- Source file: AI/谷歌深夜甩出一份【Nano Banana Pro提示词指南】，手把手教你生产专业级内容，实战案例+提示词模版.md +- Status: ✅ 成功摄入 +- Summary: 谷歌发布的 Nano Banana Pro 官方提示词指南（《The Complete Guide to Nano Banana Pro》），核心主题是"将 AI 从趣味性图像生成升级为功能性专业资产生产"。10 大黄金法则：编辑而非重新生成、使用自然语言完整句子、具体且具描述性、提供上下文。9 个实战章节覆盖文本渲染/信息图、角色一致性、Google 搜索信息锚定、高级编辑、2D/3D 转换、高分辨率、思考推理、故事板、结构控制。 +- Concepts created: [[提示词工程]], [[身份锁定（Identity Locking）]], [[思维推理模式（Thinking Mode）]], [[信息图生成]], [[2D/3D 转换]], [[草图转成品（Sketch to Final）]] +- Entities created: [[谷歌]] +- Source page: wiki/sources/谷歌深夜甩出一份-nano-banana-pro提示词指南-手把手教你生产专业级内容-实战案例-提示词模版.md +- Notes: + - 新增 Sources 条目至 index.md（替换 expected 标记行） + - 新增 6 个 Concept 页面 + - 新增 1 个 Entity 页面：Google.md + - 更新 overview.md，新增"Nano Banana Pro 提示词指南"段落至 AI Tools & Prompt Engineering 部分 + - 冲突检测：暂无发现与其他 Wiki 页面的内容冲突 + +## [2026-04-23] ingest | 详细！离线部署大模型：ollama+deepseek+open-webui安装使用方法及常见问题解决 1 +- Source file: AI/详细！离线部署大模型：ollama+deepseek+open-webui安装使用方法及常见问题解决 1.md +- Status: ✅ 成功摄入 +- Summary: Ollama + DeepSeek-R1 + Open WebUI 本地离线部署完整指南，覆盖硬件要求、安装方法（macOS/Windows/Linux/Docker）、模型下载加速（魔塔/HF Mirror/夸克网盘）、API 安全配置（nginx + Bearer Token）和 Open WebUI Docker Compose 部署。 +- Entities created: [[Ollama]], [[Open WebUI]] +- Concepts created: [[Local LLM Deployment]], [[Docker LLM Deployment]] +- Source page: wiki/sources/详细-离线部署大模型-ollama-deepseek-open-webui安装使用方法及常见问题解决-1.md +- Notes: + - 新增 Sources 条目至 index.md（Sources 节顶部） + - 新增 Entity 页面：Ollama.md、Open-WebUI.md + - 新增 Concept 页面：Local-LLM-Deployment.md、Docker-LLM-Deployment.md + - 更新 overview.md：Key Entities 节和 AI Tools 节 + +## [2026-04-23] ingest | OpenAI ChatGPT 个性化定义 +- Source file: AI/OpenAI ChatGPT 个性化定义.md +- Status: ✅ 成功摄入 +- Summary: ChatGPT 自定义指令（Custom Instructions）的完整配置——定义用户身份（47岁、云计算背景、跨境电商创业者）、响应风格（高度有条理、详细解释、错误零容忍）和交互偏好（主动预判需求、不道德说教、URL统一末尾引用）。核心原则：[[Expert User Assumption]]（用户为所有领域专家）、[[Proactive AI]]（主动出击而非被动等待）、[[Error Accountability]]（主动反馈配置导致的回复质量下降）。 +- Concepts created: [[Personalization]], [[Custom Instructions]], [[Proactive AI]], [[Expert User Assumption]], [[Error Accountability]] +- Entities created: [[OpenAI]], [[ChatGPT]] +- Source page: wiki/sources/openai-chatgpt-个性化定义.md +- Notes: + - 新增 Sources 条目至 index.md（替换 expected 标记行） + - 新增 5 个 Concept 页面：Personalization.md、Custom-Instructions.md、Proactive-AI.md、Expert-User-Assumption.md、Error-Accountability.md + - 新增 2 个 Entity 页面：OpenAI.md（美国 AI 研究公司）、ChatGPT.md（OpenAI 对话产品） + - 更新 overview.md，新增"ChatGPT 个性化配置"段落至 AI Tools & Prompt Engineering 部分 + - 将 5 个新 Concept 添加至 overview.md Key Concepts 列表 + - 将 OpenAI、ChatGPT 添加至 overview.md Key Entities 列表 + - 冲突检测：暂无发现与其他 Wiki 页面的内容冲突——[[designing-for-agentic-ai]] 中的 Personalization 原则与本文配置案例一致，无矛盾 + +## [2026-04-23] ingest | A Formalization of Recursive Self-Optimizing Generative Systems +- Source file: AI/A Formalization of Recursive Self-Optimizing Generative Systems.md +- Status: ✅ 成功摄入 +- Summary: 递归自我优化生成系统的形式化理论模型——定义生成器空间 $\mathcal{G}$、优化算子 $O$、元生成算子 $M$、自映射 $\Phi$，稳定生成能力 $G^*$ = $\Phi$ 的不动点；用 λ-calculus Y 组合子表达自引用结构 $G^* \equiv Y\;\text{STEP}$。核心发现：递归自我优化自然涌现不动点结构，而非终止输出；为 Self-Improving AI 提供原则性理论基础。 +- Concepts created: [[Recursive Self-Optimization]], [[Generator Space]], [[Self-Referential Computation]], [[Fixed-Point Semantics]], [[Y-Combinator]] +- Entities created: [[tukuai]] +- Source page: wiki/sources/a-formalization-of-recursive-self-optimizing-generative-systems.md +- Notes: + - 新增 Sources 条目至 index.md（替换 expected 标记行） + - 新增 5 个 Concept 页面：Recursive-Self-Optimization.md、Generator-Space.md、Self-Referential-Computation.md、Fixed-Point-Semantics.md、Y-Combinator.md + - 新增 1 个 Entity 页面：tukuai.md（独立研究者，本文作者） + - 更新 overview.md，新增"Recursive Self-Optimizing Generative Systems"段落至 Multi-Agent AI Systems 部分 + - 将 5 个新 Concept 添加至 overview.md Key Concepts 列表 + - 将 tukuai 添加至 overview.md Key Entities 列表 + - 冲突检测：暂无发现与其他 Wiki 页面的内容冲突——本文为纯理论形式化，与 Wiki 中其他 Agent 应用案例属不同层次 + +## [2026-04-23] ingest | LLMs、RAG、AI Agent 三个到底什么区别？ +- Source file: AI/LLMs、RAG、AI Agent 三个到底什么区别？.md +- Status: ✅ 成功摄入 +- Summary: LLM、RAG、AI Agent 三者的定义与关系——LLM=思考（天才大脑），RAG=认知（记忆系统），Agent=执行（行动系统）。三者非竞争技术，而是在不同层面互补。未来不在于选择其一，而在于将三者结合架构设计。 +- Concepts created: [[Large Language Model]], [[RAG]], [[AI Agent]], [[ReAct Pattern]] +- Entities created: （无新 Entity 创建） +- Source page: wiki/sources/llms-rag-ai-agent-三个到底什么区别.md +- Notes: + - 新增 Sources 条目至 index.md（置于最前，按日期排序） + - 新增 3 个 Concept 页面：Large-Language-Model.md、RAG.md、AI-Agent.md + - 更新 overview.md Key Concepts 列表，添加 Large Language Model/RAG/AI Agent/ReAct Pattern + - 更新 overview.md，新增"LLM / RAG / AI Agent 三层架构"段落至 AI Tools & Prompt Engineering 部分 + - 更新 index.md Concepts 部分，添加 3 个新 Concept 条目 + - 冲突检测：暂无发现与其他 Wiki 页面的内容冲突——本文为基础概念梳理，与 Wiki 中 Agentic AI 相关内容一致 + +## [2026-04-23] ingest | Google 神级生产力工具，所有 GitHub 开源平替都找到了 +- Source file: AI/Google 神级生产力工具，所有 GitHub 开源平替都找到了。.md +- Status: ✅ 成功摄入 +- Summary: Google NotebookLM 的 6 款 GitHub 开源平替全景盘点——OpenNotebook（14.6k Stars 全功能）、SurfSense（11.4k Stars 综合研究智能体）、Podcastfy（播客垂直聚焦）、NotebookLlama（LlamaIndex 官方学习参考）、PageLM（教育场景）、InsightsLM（低代码架构）。覆盖从"全功能替代"到"垂直聚焦"的不同需求层次。 +- Concepts created: [[文档问答]], [[播客生成]], [[语义搜索]], [[混合搜索]], [[本地化部署]] +- Entities created: [[Google]], [[NotebookLM]], [[OpenNotebook]], [[SurfSense]], [[Podcastfy]], [[NotebookLlama]], [[PageLM]], [[InsightsLM]] +- Source page: wiki/sources/google-神级生产力工具-所有-github-开源平替都找到了.md +- Notes: + - 新增 Sources 条目至 index.md（替换 expected 标记行） + - 新增 Entity 页面：Google、NotebookLM、OpenNotebook、SurfSense、Podcastfy、NotebookLlama、PageLM、InsightsLM（共8个） + - 新增 Concept 页面：文档问答、播客生成、语义搜索、混合搜索、本地化部署（共5个） + - 更新 overview.md，新增"AI Tools & Prompt Engineering"部分的"NotebookLM 开源平替生态"段落 + - 无内容冲突——与现有 RAG、知识管理工具内容互补，未发现矛盾 + +## [2026-04-23] ingest | 教學 ChatGPT 先做知識整理，再讓 Canva、 Gamma AI 輸出簡報 +- Source file: AI/教學 ChatGPT 先做知識整理，再讓 Canva、 Gamma AI 輸出簡報.md +- Status: ✅ 成功摄入 +- Summary: AI 简报自动化工作流——先用 ChatGPT 做知识整理，再用 Canva / Gamma AI 输出演示文稿。两阶段工作流（思考者→设计师）比直接用 AI 生成简报效果更好。 +- Concepts created: [[AI簡報工作流]] +- Entities created: [[Canva]], [[Gamma-AI]] +- Source page: wiki/sources/教學-chatgpt-先做知識整理-再讓-canva-gamma-ai-輸出簡報.md +- Notes: + - 新增 Sources 条目至 index.md（替换 expected 标记行） + - 新增 Entity 条目：[[Canva]], [[Gamma-AI]] + - 新增 Concept 条目：[[AI簡報工作流]] + - 更新 overview.md，新增段落至 AI Tools & Prompt Engineering 部分 + - 无内容冲突 + +## [2026-04-23] ingest | Designing for Agentic AI +- Source file: AI/Designing for Agentic AI.md +- Status: ✅ 成功摄入 +- Summary: 阐述 GenAI（创作内容）vs Agentic AI（主动行动）的核心差异，以及为 Agentic AI 设计用户体验的 TCPCA 五原则——透明度、控制感、个性化、对话、主动预判。核心洞察：观察 AI 决策过程本身就是一种参与方式，设计隐喻从"响应用户点击/滑动"转向"AI 运行时的实时反馈"。 +- Concepts updated: [[Agentic AI]]（已存在，仅补充 TCPCA 五原则维度）, [[Transparency]], [[Control]], [[Personalization]], [[Conversation]], [[Anticipation]] +- Entities updated: [[Yuri Pessa]]（已存在，仅补充身份说明） +- Source page: wiki/sources/designing-for-agentic-ai.md +- Notes: + - 新增 Sources 条目至 index.md（置于 Sources 末尾，因源文件日期 2025-03-02 早于所有现有条目） + - 新增 overview.md 段落至 AI Tools & Prompt Engineering 部分 + - 无需新建 Entity/Concept 页面（Agentic-AI entity 已存在，TCPCA 五原则暂不满足独立 Concept 页面条件） + - 与 [[Google-5个-Agent-Skill-设计模式]] 同属 AI Agent 设计方法论 + +## [2026-04-23] ingest | 养虾日记5：深夜与苏轼聊AI，他说：被浪打下去还能爬起来的才叫风流 +- Source file: 微信公众号/养虾日记5：深夜与苏轼聊AI，他说：被浪打下去还能爬起来的才叫风流.md +- Status: ✅ 成功摄入 +- Summary: 用AI蒸馏历史人物思维框架创建"数字导师"——以苏东坡为首位实践，展示如何将千年古人心智模型（六道：进退由时/此心安处/辞达而已/逆境转化/自出新意/天人合一）转化为可运行的AI Skill。女娲·Skill造人术通过6个并行Agent从6维度采集信息，产出自包含的.skill文件。 +- Concepts created: [[数字导师]], [[思维蒸馏（女娲造人术）]], [[心智模型]], [[AI-Skill]] +- Entities created: [[苏东坡]], [[女娲]] +- Source page: wiki/sources/养虾日记5-深夜与苏轼聊ai-他说-被浪打下去还能爬起来的才叫风流.md +- Notes: + - 新增 Sources 条目至 index.md（置于养虾日记4之后） + - 新增 Entity 条目：[[苏东坡]] + - 新增 Concept 条目：[[数字导师]], [[思维蒸馏（女娲造人术）]] + - 与 [[养虾日记1/2/3/4]] 和 [[养龙虾5天血泪史]] 属同一「养虾日记」系列 + +## [2026-04-23] ingest | 一语点醒梦中人 +- Source file: AI/一语点醒梦中人.md +- Status: ✅ 成功摄入 +- Summary: 收录中国传统诗词与哲学典籍中的经典名句及其释义，涵盖儒道佛三家智慧——王维"行到水穷处，坐看云起时"的佛学顿悟、曾国藩"唯忘机可以消众机"的处世哲学、庄子"知其不可奈何而安之若命"的接受智慧、《老子》"大智若愚，大巧若拙"的守拙哲学、《金刚经》"一切有为法如梦幻泡影"的空性智慧。 +- Concepts covered: [[空性智慧]], [[守拙]], [[安之若命]], [[和光同尘]], [[忘机]], [[中庸之道]], [[有为法]] +- Entities referenced: [[王维]], [[曾国藩]], [[庄子]], [[苏东坡]], [[郑板桥]] +- Source page: wiki/sources/一语点醒梦中人.md +- Notes: + - 新增 Sources 条目至 index.md + - 新增 overview.md 段落"经典智慧与人生哲学" + - Entity/Concept 均未创建独立页面（各人物/概念仅在本文出现1次，未达≥2次阈值） + - 与 [[养虾日记5]]（苏东坡数字导师）存在潜在关联，可后续扩展 + +## [2026-04-22] ingest | 不谈技术：普通人该怎么在AI时代赚钱？ + 2|- Source file: 微信公众号/不谈技术：普通人该怎么在AI时代赚钱？.md + 3|- Status: ✅ 成功摄入 + 4|- Summary: AI时代普通人如何赚钱的思维框架——三大原则：品味值钱（判断力是护城河）、做端到端的事（不当代价）、用死亡过滤器（找到真正热爱的事）。核心洞察：AI不会让普通人变富，AI会让那些知道自己要做什么、并且对品质有执念的人变得极其强大。 + 5|- Concepts created: [[品味]], [[端到端]], [[死亡过滤器]], [[工具民主化]] + 6|- Entities created: [[乔布斯]] + 7|- Source page: wiki/sources/不谈技术-普通人该怎么在ai时代赚钱.md + 8|- Notes: + 9| - 与 [[个人品牌与一人公司]] 属同一主题（AI时代个人定位与杠杆） + 10| - 与 [[Ikigai框架]] 的"热情"维度高度相关 + 11| + 12|## [2026-04-10] ingest | 养虾日记4：一次「Context Limit Exceeded」错误排查 + 13|- Source file: 微信公众号/养虾日记4： 一次「Context Limit Exceeded」错误排查：我以为是小问题，结果踩了大坑.md + 14|- Status: ✅ 成功摄入 + 15|- Summary: OpenClaw Telegram Channel「Context Limit Exceeded」错误深度排查——问题表象是 context 耗尽，实际根因是 Telegram channel 的模型被切换为 deepseek-reasoner（仅 16K context），safeguard 模式预留 16K tokens 导致实际可用为 0。解决关键：Agent 级别模型配置优先级高于全局 compaction 配置，需在路由规则层修复。 + 16|- Concepts created: [[Context-Window]], [[Model-Fallback]], [[Compaction]], [[Agent-Routing-Rules]], [[Error-Surface-vs-Root-Cause]], [[Layered-Configuration]], [[Log-Driven-Debugging]], [[Hidden-Failure-Paths]] + 17|- Entities created: （无新增；[[OpenClaw]]/[[星枢]]/[[DeepSeek]]/[[MiniMax]] 均已在现有来源中出现，不满足 ≥2 次创建条件） + 18|- Source page: wiki/sources/养虾日记4-一次「context-limit-exceeded」错误排查-我以为是小问题-结果踩了大坑.md + 19|- Notes: + 20| - 新增 Sources 条目至 index.md（置于养龙虾5天血泪史之后） + 21| - 更新 overview.md，新增 [[养虾日记4]] 段落至 Multi-Agent AI Systems 部分 + 22| - 创建 8 个 Concept 页面：Context-Window.md、Model-Fallback.md、Compaction.md、Agent-Routing-Rules.md、Error-Surface-vs-Root-Cause.md、Layered-Configuration.md、Log-Driven-Debugging.md、Hidden-Failure-Paths.md + 23| - 更新 index.md Concepts 节，新增 8 个条目（按字母顺序插入） + 24| - 与 [[养龙虾5天血泪史]] 互补（记忆写入/压缩问题 vs 模型配置错误） + 25| - 冲突检测：无与其他 Wiki 页面的实质性内容冲突 + 26| + 27|## [2026-04-23] ingest | 养虾日记3：用 Obsidian + Gitea 为 AI 助手构庺持久化笔记系统 + 28|- Source file: 微信公众号/养虾日记3：用 Obsidian + Gitea 为 AI 助手构建持久化笔记系统.md + 29|- Status: ✅ 成功摄入 + 30|- Summary: 用 Obsidian + Gitea 为 AI 助手构建持久化笔记系统——解决"AI 对话结束输出就消失"的核心问题。核心架构：Obsidian 做知识库（iCloud Drive 三端同步）+ Gitea 做版本控制（Git 历史）+ OpenClaw obsidian skill 做写入接口。核心价值：把 AI 变成"会自动整理笔记的实习生"。融合了 Karpathy 的 LLM Wiki 理念：让 AI 增量构建 Wiki，页面间互链，知识越积越厚。 + 31|- Concepts created: [[LLM Wiki]], [[Obsidian Git]], [[Graph View]], [[Obsidian Web Clipper]], [[QMD]], [[版本管理]], [[被动更新]], [[双链笔记]] + 32|- Entities created: [[Obsidian]], [[Gitea]] + 33|- Source page: wiki/sources/养虾日记3-用-obsidian-gitea-为-ai-助手构建持久化笔记系统.md + 34|- Notes: + 35| - 新增 Sources 条目至 index.md（置于最前） + 36| - 更新 overview.md，替换原 [[养虾日记1]] 段落为 [[养虾日记3]] + 37| - 创建 Entity 页面：Obsidian.md, Gitea.md + 38| - 创建 Concept 页面：LLM-Wiki.md + 39| - Gitea 已在 Entity 中存在（无需重复创建，仅更新） + 40| - 冲突：无已知冲突 + 41| + 42|## [2026-04-23] ingest | 养龙虾5天血泪史：我的AI Agent为什么总失忆？OpenClaw 记忆调试全记录 + 43|- Source file: 微信公众号/养龙虾5天血泪史：我的AI Agent为什么总失忆？OpenClaw 记忆调试全记录.md + 44|- Status: ✅ 成功摄入 + 45|- Summary: AI Agent 记忆失效问题的5天专项调试全记录——发现5类根本原因（上下文压缩、搜索后端、检索触发、压缩协同、系统配置），对应10条黄金法则。核心洞察：写入纪律比读取纪律更重要；压缩不是敌人，未写入的上下文才是；系统提示词从209,652精简到9,349令牌（减少28%）。 + 46|- Concepts created: 上下文压缩、上下文刷新、写入纪律、交接协议、启动序列 + 47|- Entities created: — + 48|- Source page: wiki/sources/养龙虾5天血泪史-我的ai-agent为什么总失忆-openclaw-记忆调试全记录.md + 49|- Notes: + 50| - 新增 Sources 条目至 index.md（置于养虾日记1、2之后） + 51| - 更新 overview.md，新增 [[养龙虾5天血泪史]] 段落至养虾日记系列部分 + 52| - 创建 5 个 Concept 页面（上下文压缩/上下文刷新/写入纪律/交接协议/启动序列） + 53| - Hybrid-Search 概念页面已存在（无需重复创建） + 54| - 冲突已记录于 source page Contradictions 部分（与 Second Brain 的 MEMORY.md 定位差异、与 personal-crm 的联系人记录方式差异） + 55| + 56|## [2026-04-23] ingest | 养虾日记1：我用 OpenClaw 管了 28 万张照片 + 57|- Source file: 微信公众号/养虾日记1：我用 OpenClaw 管了 28 万张照片：一次真实的多设备照片整理实战.md + 58|- Status: ✅ 成功摄入 + 59|- Summary: AI Agent 照片整理实战——使用 OpenClaw 成功整理了 NAS 上 28 万张、跨越 20 年的家庭照片。OpenClaw 通过「提问澄清 → 方案制定 → 批次拆分（8 批次）→ Cron 凌晨自动执行 → Telegram Summary 报告」全流程自动化。核心机制：MD5 精确去重 + 小文件清理（<100KB）+ 安全删除策略（To-Be-Deleted 目录）。核心感悟：AI Agent 的价值是思维方式升级。 + 60|- Concepts created: — + 61|- Entities created: — + 62|- Source page: wiki/sources/养虾日记1-我用-openclaw-管了-28-万张照片-一次真实的多设备照片整理实战.md + 63|- Notes: + 64| - 新增 Sources 条目至 index.md（置于最前） + 65| - 更新 overview.md，新增 [[养虾日记1]] 段落至 Self-Improving 部分，新增 [[AI-Agent思维方式]]/[[批次任务拆分]]/[[精确去重]]/[[小文件清理]]/[[安全删除策略]]/[[Telegram通知]] 至 Key Concepts + 66| - Entity 数量不足阈值（OpenClaw/Synology Photos/NAS 均已存在或仅出现 1 次），未创建新 Entity 页面 + 67| - Concept 数量不足阈值（所有概念均为本篇特定实践，不满足可抽象/可复用条件），未创建独立 Concept 页面 + 68| - 冲突已记录于 source page Contradictions 部分（与 Self-Healing-Home-Server 的规划者 vs 修复者角色差异） + 69| + 70|## [2026-04-23] ingest | X Account Analysis + 71|- Source file: Agent/usecases/x-account-analysis.md + 72|- Status: ✅ 成功摄入 + 73|- Summary: 基于 OpenClaw + Bird Skill 的 X 账号定性分析——通过 Cookie 认证读取真实账号推文，AI 分析内容质量模式（为何有时 1000+ 赞有时 <5 赞）、话题偏好与互动差异原因。免费替代 $10-$50/月订阅服务。 + 74|- Concepts created: — + 75|- Entities created: — + 76|- Source page: wiki/sources/x-account-analysis.md + 77|- Notes: + 78| - 新增 Sources 条目至 index.md（置于最前） + 79| - 更新 overview.md，新增 [[x-account-analysis]] 段落至 X/Twitter Automation 部分（补充原 x-twitter-automation 段落的互补关系描述） + 80| - 更新 wiki/sources/x-twitter-automation.md，移除"（尚未摄入）"标注 + 81| - Entity/Concept 数量不足阈值（每项仅在本文中出现 1 次），未创建新实体/概念页面；[[OpenClaw]] 已存在于 Key Entities + 82| - 新增 Key Concepts: [[Social-Media-Analytics]], [[Credential-Isolation]] + 83| + 84|## [2026-04-23] ingest | Phone Call Notifications + 85|- Source file: Agent/usecases/phone-call-notifications.md + 86|- Status: ✅ 成功摄入 + 87|- Summary: AI Agent 通过 clawr.ing 托管电话服务主动向用户拨打电话通知——Agent 评估事件优先级（股价暴跌/紧急邮件/日程提醒），自动拨叫用户真实号码，用户可实时提问，Agent 双向对话响应。与 [[phone-based-personal-assistant]] 互补（Agent 去电通知 vs 用户来电接收）。 + 88|- Concepts created: [[Voice Notification Channel]], [[Two-Way Voice Conversation]], [[Call-Worthy Threshold]] + 89|- Entities created: [[clawr.ing]], [[clawhub.ai]] (updated) + 90|- Source page: wiki/sources/phone-call-notifications.md + 91|- Notes: + 92| - 新增 Sources 条目至 index.md（置于最前） + 93| - 更新 overview.md，新增 [[phone-call-notifications]] 段落至 AI Tools & Prompt Engineering 部分，新增 [[clawr.ing]]/[[clawhub.ai]] 至 Key Entities，新增 [[Voice Notification Channel]]/[[Two-Way Voice Conversation]]/[[Call-Worthy Threshold]]/[[PSTN Calling]] 至 Key Concepts + 94| - 新增 Entity: wiki/entities/clawr.ing.md；更新 wiki/entities/ClawHub.md（添加 clawr.ing 作为托管 skill） + 95| - 新增 Concept: wiki/concepts/Voice-Notification-Channel.md、wiki/concepts/Two-Way-Voice-Conversation.md、wiki/concepts/Call-Worthy-Threshold.md + 96| - 更新 overview.md Conflict Areas，新增"Agent 去电通知 vs Agent 来电接收"冲突点 + 97| + 98|## [2026-04-23] ingest | Autonomous Educational Game Development Pipeline + 99|- Source file: Agent/usecases/autonomous-game-dev-pipeline.md + 100|- Status: ✅ 成功摄入 + 101|- Summary: AI Agent 全自动管理教育游戏开发生命周期——"Bugs First" 优先策略 + Round Robin 轮询 + 纯 HTML5/CSS3/JS 技术栈，单人实现每 7 分钟产出 1 款游戏或 1 个 bugfix，41+ 款游戏维护。 + 102|- Concepts created: [[Bugs First]], [[Round Robin Strategy]], [[Conventional Commits]], [[Feature Branch Workflow]], [[HTML5 Game Development]] + 103|- Entities created: — + 104|- Source page: wiki/sources/autonomous-game-dev-pipeline.md + 105|- Notes: + 106| - 新增 Sources 条目至 index.md（置于最前） + 107| - 更新 overview.md，新增 [[autonomous-game-dev-pipeline]] 段落至 AI Tools & Prompt Engineering 部分 + 108| - Entity/Concept 数量不足阈值，未创建新实体页面；[[OpenClaw]] 实体已存在于 index.md + 109| + 110|## [2026-04-23] ingest | arXiv Paper Reader + 111|- Source file: Agent/usecases/arxiv-paper-reader.md + 112|- Status: ✅ 成功摄入 + 113|- Summary: AI Agent 驱动的 arXiv 论文阅读助手——通过 `arxiv-reader` skill（3 工具：`arxiv_fetch`、`arxiv_sections`、`arxiv_abstract`）直接从 arXiv 下载 LaTeX 源码并自动扁平化展开，消除 PDF 下载后切换论文丢失上下文和 LaTeX 符号难以解析的痛点；支持摘要浏览、多论文对比排序、选择性细读和会话式分析；本地缓存使重复访问秒级响应；纯 Node.js 零依赖部署。 + 114|- Concepts created: [[arXiv-API]], [[LaTeX-Flattening]], [[Local-Caching]], [[Paper-Abstract-Batch-Fetching]] + 115|- Entities created: [[Prismer-AI]] + 116|- Source page: wiki/sources/arxiv-paper-reader.md + 117|- Notes: + 118| - 新增 Sources 条目至 index.md（替换 "source missing" placeholder） + 119| - 更新 overview.md，在 YouTube Automation 部分后新增 [[arXiv-Paper-Reader]] 段落，在 Key Concepts 列表新增 4 个新概念 + 120| - 创建 Entity 页面：Prismer-AI.md（GitHub 组织，`arxiv-reader` skill 维护方） + 121| - 创建 Concept 页面：arXiv-API.md（arXiv 开放 API）、LaTeX-Flattening.md（LaTeX 扁平化技术）、Local-Caching.md（本地缓存模式）、Paper-Abstract-Batch-Fetching.md（批量摘要对比模式） + 122| - 与 [[academic-historian]] 同属学术研究场景互补——前者侧重理工科论文，后者侧重人文社科 + 123| - 与 [[YouTube-Content-Pipeline]] 的 Research Agent 共享研究工作流设计模式 + 124| - 冲突检测：无已知实质冲突 + 125| + 126|## [2026-04-22] ingest | Semantic Memory Search + 127|- Source file: Agent/usecases/semantic-memory-search.md + 128|- Status: ✅ 成功摄入 + 129|- Summary: 通过 memsearch（基于 Milvus 向量数据库）为 OpenClaw Markdown 记忆添加语义搜索能力——用自然语言提问即可找到相关内容，无需精确措辞。混合搜索（稠密向量 + BM25 + RRF）兼顾语义相似性和关键词精确匹配；SHA-256 内容哈希实现增量索引节省成本；文件监视器自动重建索引；支持本地模式无需 API Key。核心理念：Markdown 是唯一真相，向量索引是派生缓存。 + 130|- Concepts created: [[Hybrid Search]], [[Reciprocal Rank Fusion]], [[Content Hashing]], [[File Watcher]] + 131|- Entities created: [[memsearch]], [[Milvus]] + 132|- Source page: wiki/sources/semantic-memory-search.md + 133|- Notes: + 134| - 新增 Sources 条目至 index.md（替换 "source missing" placeholder） + 135| - 更新 overview.md，在 Productivity & Knowledge Management 部分新增 [[semantic-memory-search]] 段落，在 Key Concepts 列表新增 6 个新概念 + 136| - 创建 Entity 页面：Memsearch.md（ZillizTech memsearch CLI/库）、Milvus.md（开源向量数据库） + 137| - 创建 Concept 页面：Hybrid-Search.md（混合搜索策略）、Reciprocal-Rank-Fusion.md（排名融合算法）、Content-Hashing.md（增量索引机制）、File-Watcher.md（自动重建索引） + 138| - 与 [[Knowledge-Base-RAG]] 同属 RAG 技术栈的不同场景——后者侧重 URL 入库，前者侧重现有 Markdown 文件的语义索引 + 139| - 冲突检测：wiki/concepts/Semantic-Search.md 已引用 [[Hybrid Search]]，与本 Source 一致；wiki/concepts/Knowledge-Base-RAG.md 有 Hybrid Search 说明，与本 Source 一致，暂无实质冲突 + 140| + 141|## [2026-04-22] ingest | OpenClaw as Desktop Cowork (AionUi) — Remote Rescue & Multi-Agent Hub + 142|- Source file: Agent/usecases/aionui-cowork-desktop.md + 143|- Status: ✅ 成功摄入 + 144|- Summary: 通过 AionUi 桌面应用将 OpenClaw 作为可视化 Cowork Agent 运行——提供文件感知工作空间（可见文件读写/命令/网页浏览），内置 OpenClaw 部署专家通过 Telegram/WebUI 远程诊断修复（`openclaw doctor`），统一 MCP 配置全局同步到 12+ Agent，支持 WebUI/Telegram/Lark/DingTalk 多渠道远程访问。 + 145|- Concepts created: [[CoworkWorkspace]], [[RemoteRescuePattern]], [[Multi-AgentHub]], [[MCPOnceAllAgents]] + 146|- Entities created: [[AionUi]] + 147|- Source page: wiki/sources/aionui-cowork-desktop.md + 148|- Notes: + 149| - 新增 Sources 条目至 index.md（替换 "source missing" placeholder） + 150| - 更新 overview.md，在 AI Tools & Prompt Engineering 部分新增 [[aionui-cowork-desktop]] 段落，在 Key Entities 部分新增 [[AionUi]]，在 Key Concepts 部分新增 4 个新概念 + 151| - 创建实体页面 wiki/entities/AionUi.md + 152| - 创建概念页面：CoworkWorkspace.md, RemoteRescuePattern.md, Multi-AgentHub.md, MCPOnceAllAgents.md + 153| + 154|## [2026-04-22] ingest | Family Calendar Aggregation & Household Assistant + 155|- Source file: Agent/usecases/family-calendar-household-assistant.md + 156|- Status: ✅ 成功摄入 + 157|- Summary: AI Agent 作为家庭日程协调中心——聚合 5+ 个分散日历（工作/个人/家庭/学校/课外）生成每日晨间简报；通过环境消息监控（Ambient Message Monitoring）自动从 iMessage 中识别预约并创建日历事件（含行车时间缓冲）；维护家庭库存 JSON，支持照片 OCR 和小票识别更新；生成购物清单。核心洞察：Ambient > Active，Mac Mini 是最优硬件。 + 158|- Concepts created: [[AmbientMessageMonitoring]], [[HouseholdInventoryTracking]] + 159|- Entities created: [[SparkryAI]] + 160|- Source page: wiki/sources/family-calendar-household-assistant.md + 161|- Notes: + 162| - 新增 Sources 条目至 index.md（替换 "source missing" placeholder） + 163| - 更新 overview.md，在 AI Tools & Prompt Engineering 部分新增 [[family-calendar-household-assistant]] 段落 + 164| - 新建 Concept 页面：AmbientMessageMonitoring.md（核心差异化机制）、HouseholdInventoryTracking.md（物资追踪模式） + 165| - 新建 Entity 页面：SparkryAI.md（牙医预约案例的来源） + 166| - 与 [[Custom Morning Brief]] 互补：同一晨间简报模式，个人场景 vs 家庭场景 + 167| - 与 [[Second Brain]] 共享 OpenClaw 持久记忆能力 + 168| - 冲突检测：暂无发现与其他 Wiki 页面的内容冲突 + 169| + 170|## [2026-04-22] ingest | Personal Knowledge Base (RAG) + 171|- Source file: Agent/usecases/knowledge-base-rag.md + 172|- Status: ✅ 成功摄入 + 173|- Summary: AI Agent 驱动的个人知识库 RAG 系统——通过 Telegram Topic 或 Slack Channel 投递任意 URL（网页/推文/YouTube 字幕/PDF），Agent 自动抓取内容并以 Embedding 向量入库；支持语义搜索，返回排名结果并附带来源；可被其他工作流（如 [[YouTube-Content-Pipeline]]）主动查询。核心理念：**捕获像发短信一样简单，检索像搜索一样容易**。 + 174|- Concepts created: [[Semantic-Search]], [[Content-Ingestion]] + 175|- Source page: wiki/sources/knowledge-base-rag.md + 176|- Notes: + 177| - 新增 Sources 条目至 index.md（替换 "source missing" placeholder） + 178| - 更新 overview.md，在 Productivity & Knowledge Management 部分新增 [[Personal Knowledge Base (RAG)]] 段落 + 179| - 与 [[Second Brain]] 互补：Second Brain 侧重对话记忆，本方案侧重结构化知识检索 + 180| - 与 [[YouTube-Content-Pipeline]] 关联：后者在工作流中主动查询知识库 + 181| - [[Knowledge-Base-RAG]] 概念页已存在（2026-04-22 youtube-content-pipeline ingest 时创建），本次补充 Semantic-Search 和 Content-Ingestion 两个子概念 + 182| - Entity 页面（OpenClaw、ClawHub、Telegram、Slack）均已在 overview.md Key Entities 中覆盖，无需新建 + 183| - Contradiction：暂无发现与其他 Wiki 页面的内容冲突 + 184|- Status: ✅ 成功摄入 + 185|- Summary: AI Agent 驱动的 YouTube 选题发现与选题自动化流水线——每小时 Cron Job 扫描 Web + X/Twitter 突发 AI 新闻，向 Telegram 推送选题；维护 90 天视频目录（播放量 + 主题分析）避免选题重复；通过 SQLite 向量嵌入实现语义去重；在 Slack 分享链接时自动研究主题、搜索 X、查询知识库并创建带大纲的 Asana 任务卡。 + 186|- Concepts created: [[Semantic-Deduplication]], [[Vector-Embedding]], [[Knowledge-Base-RAG]] + 187|- Source page: wiki/sources/youtube-content-pipeline.md + 188|- Notes: + 189| - 新增 Sources 条目至 index.md（替换 "source missing" placeholder） + 190| - 更新 overview.md，在 YouTube Automation 部分新增 [[YouTube-Content-Pipeline]] 段落 + 191| - 与 [[Daily-YouTube-Digest]] 互补：后者侧重订阅频道更新监控，前者侧重全网趋势主动发现 + 192| - 与 [[Content-Factory]] 共享并行子 Agent 执行模式 + 193| - Entity 页面（OpenClaw、Asana、Slack）均已存在，无需新建 + 194| - 新增 3 个 Concept 页面并注册至 index.md Concepts 索引 + 195| - Contradiction：暂无发现与其他 Wiki 页面的内容冲突 + 196|- Source file: Agent/usecases/polymarket-autopilot.md + 197|- Status: ✅ 成功摄入 + 198|- Summary: 基于 AI Agent 的 Polymarket 预测市场自动驾驶交易系统，实现 24/7 市场监控与自动化分析。AI Agent 自动监控 Polymarket 市场数据、智能分析预测概率变化、自动执行交易策略、定时推送市场洞察。 + 199|- Concepts created: [[Prediction Market]], [[Agentic Trading]], [[Market Monitoring]] + 200|- Entities created: [[Polymarket]] + 201|- Source page: wiki/sources/polymarket-autopilot.md + 202|- Notes: + 203| - 新增 Sources 条目至 index.md（替换 placeholder） + 204| - 更新 overview.md，在 Multi-Agent Monitoring 部分的 Dynamic Dashboard 段落中补充 polymarket-autopilot 引用 + 205| - 与 [[Dynamic Dashboard]] 存在关联（监控仪表盘的具体用例） + 206| - 与 [[earnings-tracker]] 属于同类模式（市场数据监控 + 定时推送） + 207| - Polymarket 已在 overview.md Key Entities 中提及，无需重复创建 Entity 页面 + 208| - Contradiction：暂无发现与其他 Wiki 页面的内容冲突 + 209| + 210|## [2026-04-22] ingest | Local CRM Framework with DenchClaw + 211|- Source file: Agent/usecases/local-crm-framework.md + 212|- Status: ✅ 成功摄入 + 213|- Summary: DenchClaw 将 OpenClaw 转化为本地 CRM、销售自动化和生产力平台，通过 `npx denchclaw` 一键安装完整技术栈（DuckDB + Web UI + OpenClaw Profile + 浏览器自动化）。核心创新：所有设置/视图以 YAML/Markdown 文件存储，Agent 可直接修改 UI 而无需 API 抽象层；Chrome Profile 克隆使 Agent 继承用户认证状态，可直接导入 HubSpot 等平台数据。 + 214|- Concepts created: [[File-System-First-UI]], [[DuckDB]] + 215|- Entities created: [[DenchClaw]] + 216|- Source page: wiki/sources/local-crm-framework.md + 217|- Notes: + 218| - 新增 Sources 条目至 index.md（置于首位） + 219| - 更新 overview.md，在 [[personal-crm]] 附近添加 Local CRM Framework 段落 + 220| - 创建 1 个 Entity 页面：DenchClaw.md + 221| - 创建 2 个 Concept 页面：DuckDB.md、File-System-First-UI.md + 222| - 与 [[Second Brain]] 均基于 OpenClaw 的记忆/持久化能力，属同类应用的不同垂直场景 + 223| - 与 [[personal-crm]] 同属个人 CRM 场景的不同实现方案 + 224| - 与 [[multi-channel-assistant]] 共享 Telegram/消息平台作为交互入口 + 225| - 核心设计哲学：文件系统即 Agent 原生 UI + DuckDB 嵌入式数据库 + Chrome Profile 克隆 + 226| - Contradiction：暂无发现与其他 Wiki 页面的内容冲突 + 227| + 228|## [2026-04-22] ingest | Goal-Driven Autonomous Tasks + 229|- Source file: Agent/usecases/overnight-mini-app-builder.md + 230|- Status: ✅ 成功摄入 + 231|- Summary: AI Agent 从被动执行者转变为主动规划者的目标驱动型自主任务系统。通过 Brain Dump 一次性倾倒所有目标，OpenClaw 每日清晨自动生成 4-5 个贴近目标的自主任务（研究/写作/MVP构建），通过 Next.js Kanban 看板实时追踪。核心价值：用户定义目的地，Agent 自动分解并执行每日步骤。还包含过夜惊喜 Mini-App 构建模式。核心工程实践：Git-style append-only 日志解决多 Agent 竞态条件；Token-Light Design 保持 AUTONOMOUS.md 在 50 行以内。 + 232|- Concepts created: [[Sub-Agent-Race-Condition]], [[Token-Light-Design]], [[Brain-Dump]] + 233|- Entities created: （无新增，[[OpenClaw]]/[[Alex Finn]]/[[Next.js]] 均已存在） + 234|- Source page: wiki/sources/overnight-mini-app-builder.md + 235|- Notes: + 236| - 新增 Sources 条目至 index.md（替换 placeholder，原标题为 overnight-mini-app-builder） + 237| - 更新 overview.md，将 Market Research & Product Factory 段落替换为 Goal-Driven Autonomous Tasks 段落，补充 Git-style append-only 模式和 Token-Light Design 洞察 + 238| - 更新 Alex-Finn.md，将 overnight-mini-app-builder 添加至 sources + 239| - 创建 3 个 Concept 页面：Sub-Agent-Race-Condition.md、Token-Light-Design.md、Brain-Dump.md + 240| - 与 [[Project State Management]] 的看板 vs 事件溯源存在潜在冲突（已记录于 Source Page Contradictions） + 241| - 与 [[market-research-product-factory]] 同属 Alex Finn 启发的 OpenClaw 高阶用法，前者侧重任务追踪和持续执行，后者侧重产品机会发现 + 242| + 243|## [2026-04-17] ingest | Habit Tracker & Accountability Coach + 244|- Source file: Agent/usecases/habit-tracker-accountability-coach.md + 245|- Status: ✅ 成功摄入 + 246|- Summary: AI Agent 作为主动问责伙伴，通过 Telegram/SMS 每日定时签到，替代被动习惯追踪 App。核心机制：主动问责 + 连续打卡追踪 + 自适应语气 + 每周模式分析。关键洞察：主动询问比被动记录更能驱动行为改变；保持 3-5 个习惯可避免签到疲劳；[[Adaptive Tone]] 自适应语气是关键差异化因素。 + 247|- Concepts created: [[Adaptive-Tone]], [[Active-Accountability]], [[Streak-Tracking]], [[Check-in-Fatigue]], [[Weekly-Pattern-Analysis]] + 248|- Entities created: （无新增，[[Telegram Bot API]]/[[Twilio]]/[[Google Sheets API]] 各仅出现 1 次，不满足≥2次创建条件；[[OpenClaw]] 已存在） + 249|- Source page: wiki/sources/habit-tracker-accountability-coach.md + 250|- Notes: + 251| - 新增 Sources 条目至 index.md（替换 placeholder） + 252| - 更新 overview.md，添加 Habit Tracker & Accountability Coach 段落，补充 [[Adaptive Tone]], [[Active Accountability]], [[Streak Tracking]], [[Check-in Fatigue]], [[Weekly Pattern Analysis]] 至 Key Concepts + 253| - 创建 5 个 Concept 页面：Adaptive-Tone.md、Active-Accountability.md、Streak-Tracking.md、Check-in-Fatigue.md、Weekly-Pattern-Analysis.md + 254| - 已有相关 Concept：[[Scheduled-Reminder]]（定时签到技术基础）、[[Agent-Personality]]（Adaptive Tone 的上层设计）、[[Morning Briefing]]（同一 Cron + AI 推送模式）、[[Food-Sensitivity-Tracking]]（同一框架的不同垂直场景） + 255| - 已有相关 Entity：[[OpenClaw]]（底层运行平台） + 256| - 与 [[Health & Symptom Tracker]] 属同一框架（OpenClaw + Telegram + Cron Job + 每周分析），但垂直于个人习惯养成 + 257| - Contradiction：与[[Todoist Task Manager]] 同属 OpenClaw 生产力工具集，但 Todoist 侧重任务管理，Habit Tracker 侧重个人行为改变——不冲突，属于互补关系 + 258| - 与传统习惯 App（Streaks/Habitica）的对比：传统 App 强调被动记录和视觉激励；本方案强调主动询问和个性化文字激励 + 259| + 260|## [2026-04-22] ingest | Todoist Task Manager + 261|- Source file: Agent/usecases/todoist-task-manager.md + 262|- Status: ✅ 成功摄入 + 263|- Summary: AI Agent 通过 Todoist API 实现自然语言驱动的任务管理自动化——Agent 解析自然语言指令 → Todoist REST API 创建结构化任务（含截止/项目/标签）→ Cron Job 定时扫描逾期任务主动推送提醒。核心价值：用户只需发一条消息即可完成全套操作，AI 主动追踪逾期任务。 + 264|- Concepts created: [[Todoist API]], [[AI-Driven Task Extraction]], [[Recurring Tasks]] + 265|- Entities created: （无新增，[[Todoist]]/[[OpenClaw]]/[[SuperCall]] 已存在） + 266|- Source page: wiki/sources/todoist-task-manager.md + 267|- Notes: + 268| - 新增 Sources 条目至 index.md（替换 placeholder） + 269| - 更新 overview.md，添加 Todoist Task Manager 段落，补充 [[Morning Briefing]], [[Todoist API]], [[AI-Driven Task Extraction]], [[TaskAutomation]], [[Recurring Tasks]] 至 Key Concepts + 270| - 更新 entities/Todoist.md，添加 todoist-task-manager 至 sources + 271| - 创建 3 个 Concept 页面：Todoist-API.md、AI-Driven-Task-Extraction.md、Recurring-Tasks.md + 272| - [[Project State Management]] 冲突记录：Todoist（结构化字段/API驱动）与 Markdown 事件流（完整上下文/自托管）各有适用场景 + 273| - 与 [[multi-channel-assistant]] 中 Todoist 集成属同一技术栈，侧重不同：前者侧重多渠道统一入口，后者侧重任务管理深度自动化 + 274| + 275|## [2026-04-22] ingest | Dynamic Dashboard with Sub-agent Spawning + 276|- Source file: Agent/usecases/dynamic-dashboard.md + 277|- Status: ✅ 成功摄入 + 278|- Summary: 基于子代理并行执行的多数据源实时监控仪表盘——通过子代理并行抓取 GitHub/Twitter/Polymarket/系统健康等多数据源，定时聚合结果推送 Discord，支持告警阈值和历史趋势存储。用对话式指令替代数周前端开发，立即获得实时洞察。 + 279|- Concepts created: [[Dynamic-Dashboard]], [[Alerting]] + 280|- Entities created: （无新增，[[OpenClaw]] 已存在） + 281|- Source page: wiki/sources/dynamic-dashboard.md + 282|- Notes: + 283| - 新增 Sources 条目至 index.md（插入顶部） + 284| - 更新 overview.md，添加 Multi-Agent Monitoring & Automation 段落，补充 [[Dynamic-Dashboard]] 和 [[Alerting]] 至 Key Concepts + 285| - 创建 2 个 Concept 页面：Dynamic-Dashboard.md、Alerting.md + 286| - 已有相关 Concept：[[Parallel-Agent-Execution]]（子代理并行）、[[Scheduled-Task-Flywheel]]（定时任务） + 287| - 已有相关 Entity：[[OpenClaw]]（多代理框架） + 288| - 冲突：与 [[content-factory]] 存在场景重叠（并行执行模式），但前者侧重数据监控，后者侧重内容创作 + 289| + 290|## [2026-04-22] ingest | Pre-Build Idea Validator + 291|- Source file: Agent/usecases/pre-build-idea-validator.md + 292|- Status: ✅ 成功摄入 + 293|- Summary: AI 项目启动前的竞争分析门控机制——在写代码之前通过 idea-reality-mcp 扫描 GitHub/Hacker News/npm/PyPI/Product Hunt 五个数据源，返回 reality_signal 分数（0-100）评估赛道拥挤度，防止 Agent 在已饱和赛道投入资源。 + 294|- Concepts created: [[Pre-Build Validation]], [[Reality-Signal]], [[Competition-Analysis]], [[Pivot-Strategy]], [[Agent-Build-Gate]] + 295|- Entities created: [[idea-reality-mcp]] + 296|- Source page: wiki/sources/pre-build-idea-validator.md + 297|- Notes: + 298| - 新增 Sources 条目至 index.md（插入顶部） + 299| - 更新 overview.md，添加 pre-build-idea-validator 段落并补充 4 个新概念至 Key Concepts + 300| - 创建 5 个 Concept 页面：Pre-Build-Validation.md、Reality-Signal.md、Competition-Analysis.md、Pivot-Strategy.md、Agent-Build-Gate.md + 301| - 创建 1 个 Entity 页面：idea-reality-mcp.md + 302| - Hacker-News 和 Product-Hunt 仅出现 1 次，不满足 ≥2 次的 Entity 创建阈值，未创建 + 303| - 与 market-research-product-factory 互补：后者挖痛点找方向，前者在动手前验证赛道的竞争密度 + 304| - 冲突：无 + 305| + 306|## [2026-04-22] ingest | Autonomous Project Management with Subagents + 307|- Source file: Agent/usecases/autonomous-project-management.md + 308|- Status: ✅ 成功摄入 + 309|- Summary: 去中心化多 Agent 项目协调模式——通过共享 STATE.yaml 实现并行自主执行，主会话遵循 CEO 模式（仅做策略决策），Git 作为审计日志记录所有状态变更。核心洞察：文件协调优于中心编排器，主会话越薄响应越快。 + 310|- Concepts created: [[PM Delegation Pattern]], [[CEO Pattern]], [[Shared State Coordination]], [[Git-as-Audit-Log]] + 311|- Entities created: [[Nicholas Carlini]] + 312|- Source page: wiki/sources/autonomous-project-management.md + 313|- Notes: + 314| - 新增 Sources 条目至 index.md（插入顶部） + 315| - 更新 overview.md，添加 4 个新概念至 Key Concepts + 316| - 创建 4 个 Concept 页面：PMDelegationPattern.md、CEOPattern.md、SharedStateCoordination.md、GitAsAuditLog.md + 317| - 创建 1 个 Entity 页面：NicholasCarlini.md + 318| - 冲突记录：与 [[project-state-management]] 的任务管理范式冲突（动态文件 vs 静态看板） + 319| - Nicholas Carlini 未在原 Wiki 中出现，作为启发来源创建 Entity 页面 + 320| + 321|- Source file: Agent/usecases/daily-reddit-digest.md + 322|- Status: ✅ 成功摄入 + 323|- Summary: AI Agent 驱动的 Reddit 每日精选摘要自动化——通过 OpenClaw + reddit-readonly skill，每日定时抓取多 Subreddit 热门帖子，AI 记忆偏好持续优化规则，纯读取模式无需认证。 + 324|- Concepts created: [[Daily-Digest]], [[Reddit Read-Only]], [[Preference Learning]] + 325|- Entities created: [[reddit-readonly]] + 326|- Source page: wiki/sources/daily-reddit-digest.md + 327|- Notes: + 328| - 更新 index.md，替换缺失标记为正式条目 + 329| - 更新 overview.md，添加至 YouTube Automation / Daily Digest 章节 + 330| - OpenClaw Entity 页面已存在，无需新建 + 331| - Preference Learning Concept 已在 inbox-declutter 中引用，无需新建 + 332| + 333|## [2026-04-22] ingest | Inbox De-clutter + 334|- Source file: Agent/usecases/inbox-declutter.md + 335|- Status: ✅ 成功摄入 + 336|- Summary: AI Agent 每日自动整理 Newsletter 邮件摘要——通过 Cron Job 每日 20:00 阅读过去 24 小时 Newsletter 新邮件，生成精华摘要并附链接，根据用户反馈持续学习偏好。需前置 Gmail OAuth Setup。 + 337|- Concepts created: [[Email Triage]], [[Newsletter Digest]], [[Preference Learning]] + 338|- Entities created: [[Gmail OAuth]] + 339|- Source page: wiki/sources/inbox-declutter.md + 340|- Notes: + 341| - 新增 Sources 条目至 index.md（插入顶部） + 342| - 更新 overview.md，添加 inbox-declutter 描述段落（作为 [[custom-morning-brief]] 的相似模式） + 343| - 创建 Concept 页面：Email-Triage.md、Newsletter-Digest.md、Preference-Learning.md + 344| - 创建 Entity 页面：Gmail-OAuth.md + 345| - 与 [[custom-morning-brief]] 属同一 Cron Job + AI 摘要模式的不同垂直场景 + 346| - 冲突：无 + 347| + 348|## [2026-04-22] ingest | Market Research & Product Factory + 349|- Source file: Agent/usecases/market-research-product-factory.md + 350|- Status: ✅ 成功摄入 + 351|- Summary: AI Agent 驱动的"从市场调研到产品构建"全自动化流水线——通过 Last 30 Days skill 挖掘 Reddit 和 X 近30天真实用户痛点，OpenClaw 根据痛点构建 Web 应用 MVP。核心价值：发短信即可完成"发现问题→验证需求→构建方案"全流程，无需技术背景。 + 352|- Concepts created: [[Pain Point Mining]], [[Startup MVP Pipeline]], [[Agent-Driven Market Research]], [[Last 30 Days Method]] + 353|- Source page: wiki/sources/market-research-product-factory.md + 354|- Notes: + 355| - 新增 Sources 条目至 index.md + 356| - 更新 overview.md，添加 Market Research & Product Factory 描述段落 + 357| - 添加 Pain Point Mining、Startup MVP Pipeline、Agent-Driven Market Research、Last 30 Days Method 到 Key Concepts + 358| - Alex Finn 出现2次（content-factory + market-research），但按出现频次标准不满足 Entity 创建条件，跳过 + 359| - Matt Van Horne 仅出现1次，跳过 Entity 页面创建 + 360| - 冲突：无已知冲突 + 361| + 362|## [2026-04-22] ingest | Phone-Based Personal Assistant + 363|- Source file: Agent/usecases/phone-based-personal-assistant.md + 364|- Status: ✅ 成功摄入 + 365|- Summary: 通过 ClawdTalk + Telnyx 将任意手机变成 AI 助理语音入口——拨打电话即可与 OpenClaw 对话，支持日历查询、Jira 任务更新、网络搜索，无需智能手机 App 或浏览器，覆盖驾驶、步行等双手占用场景。与 [[multi-channel-assistant]] 互补：文字入口覆盖图文交互，语音入口覆盖无屏场景。 + 366|- Concepts created: [[Voice Interface]], [[Telephony Integration]] + 367|- Entities created: [[ClawdTalk]], [[Telnyx]] + 368|- Source page: wiki/sources/phone-based-personal-assistant.md + 369|- Notes: + 370| - 新增 Sources 条目至 index.md（插入 Multi-Channel Personal Assistant 之后） + 371| - 更新 overview.md，添加 phone-based-personal-assistant 描述段落，添加 Voice Interface、Telephony Integration 到 Key Concepts + 372| - 创建 2 个 Entity 页面：ClawdTalk.md、Telnyx.md + 373| - 创建 2 个 Concept 页面：Voice-Interface.md、Telephony-Integration.md + 374| - 冲突已记录（已在 overview.md Conflict Area #10）：[[phone-based-personal-assistant]] 通用语音 Agent vs [[event-guest-confirmation]] SuperCall 沙盒 Persona + 375| + 376|## [2026-04-22] ingest | Event Guest Confirmation + 377|- Source file: Agent/usecases/event-guest-confirmation.md + 378|- Status: ✅ 成功摄入 + 379|- Summary: 基于 OpenClaw + SuperCall 的活动嘉宾自动确认方案——通过 AI 语音电话批量外呼客人，确认出席状态并收集备注（饮食禁忌、Plus-One、到达时间等），通话完成后生成出席确认/未出席/未接听三分类摘要。核心价值：真人电话比短信回复率高；SuperCall 沙盒 persona 设计确保安全隔离，无 Prompt Injection 风险；每通电话独立重置，无对话间信息混淆。 + 380|- Concepts created: [[Sandboxed Persona]] + 381|- Entities created: （无新实体；OpenClaw 已在其他来源中出现） + 382|- Source page: wiki/sources/event-guest-confirmation.md + 383|- Notes: + 384| - 新增 Sources 条目至 index.md（插入 Multi-Channel Personal Assistant 之后） + 385| - 更新 overview.md，添加 AI Tools & Productivity 小节描述 + 386| - 更新 overview.md Conflict Area #10，添加 SuperCall 沙盒 Persona vs 通用语音 Agent 对比 + 387| - 创建 1 个 Concept 页面：Sandboxed-Persona.md + 388| + 389|## [2026-04-22] ingest | Multi-Channel Personal Assistant + 390|- Source file: Agent/usecases/multi-channel-assistant.md + 391|- Status: ✅ 成功摄入 + 392|- Summary: 基于 Telegram Topic 路由 + OpenClaw 的多渠道个人助理方案——以 Telegram 为统一入口，通过 Topic 隔离不同上下文（config/updates/video-ideas/personal-crm/earnings/knowledge-base），整合 Google Workspace（gog）、Slack、Todoist、Asana，实现"说一句话完成全套工作"。核心价值：消除应用切换疲劳，AI 主动推送定时提醒。 + 393|- Concepts created: [[Topic-Based Routing]], [[Scheduled Reminder]] + 394|- Entities created: [[Asana]], [[gog]] + 395|- Source page: wiki/sources/multi-channel-assistant.md + 396|- Notes: 与 [[multi-agent-team]] 存在互补关系——Multi-Agent Team 为底层专业化分工，Multi-Channel Assistant 为用户交互层。 + 397| + 398|## [2026-04-22] ingest | Project State Management System: Event-Driven Alternative to Kanban + 399|- Source file: Agent/usecases/project-state-management.md + 400|- Status: ✅ 成功摄入 + 401|- Summary: 用事件驱动系统替代传统看板——自然语言对话自动记录项目事件（progress/blocker/decision/pivot），PostgreSQL/SQLite 存储完整事件历史，Git 提交自动关联项目，每日 Cron 生成站会报告。消灭手动拖拽卡片的摩擦，保留完整决策上下文，让项目状态查询和每日站会自动化。 + 402|- Concepts created: [[Event Sourcing]], [[Project State]] + 403|- Entities created: （无新实体；OpenClaw 已存在于多个来源中，无需独立 Entity 页面） + 404|- Source page: wiki/sources/project-state-management.md + 405|- Notes: + 406| - 新增 Sources 条目至 index.md（插入 Sources 首行） + 407| - 更新 overview.md Conflict Area #1，扩展 Kanban vs Event Sourcing 对比描述 + 408| - 创建 2 个 Concept 页面：EventSourcing.md、ProjectState.md + 409| - 冲突已记录：Event Sourcing（自动追踪+上下文保留）vs Kanban（可视化协作+团队同步） + 410|- Source file: Agent/usecases/health-symptom-tracker.md + 411|- Status: ✅ 成功摄入 + 412|- Summary: 通过 Telegram 话题 + OpenClaw AI Agent 自动追踪食物与症状，实现食物敏感性识别。每日三餐定时提醒（8AM/1PM/7PM）确保日志一致性，OpenClaw 自动解析消息并带时间戳写入 Markdown 日志，每周日分析关联模式识别潜在触发因素。无需专用 App，完全自托管。 + 413|- Concepts created: [[Food Sensitivity Tracking]], [[Automated Health Logging]] + 414|- Entities created: （无新实体；OpenClaw 实体已存在） + 415|- Source page: wiki/sources/health-symptom-tracker.md + 416|- Notes: + 417| - 新增 Sources 条目至 index.md（插入首行） + 418| - 新增健康追踪主题至 overview.md + 419| - 冲突记录：与 habit-tracker-accountability-coach 的习惯追踪 vs 健康数据追踪侧重对比 + 420| + 421| + 422|## [2026-04-22] ingest | Second Brain + 423|- Source file: Agent/usecases/second-brain.md + 424|- Status: ✅ 成功摄入 + 425|- Summary: AI Agent 作为个人第二大脑的记忆捕获与检索系统——通过短信/Telegram/Discord 零摩擦捕获任何内容，OpenClaw 永久记忆存储，Next.js 可搜索仪表盘提供全局检索。核心洞见：捕获像发短信一样简单，检索像搜索一样简单。灵感来源：Alex Finn YouTube 视频 + Tiago Forte《Building a Second Brain》。 + 426|- Concepts created: [[Zero-Friction Capture]], [[Cumulative Memory]], [[Conversational Interface]], [[Text-and-Search]] + 427|- Entities created: [[Tiago Forte]] + 428|- Entities updated: [[OpenClaw]]（追加 second-brain 到 sources）, [[Alex Finn]]（追加 second-brain 到 sources） + 429|- Source page: wiki/sources/second-brain.md + 430|- Notes: + 431| - 新增 Sources 条目至 index.md（替换 placeholder） + 432| - 更新 overview.md，添加 Second Brain 段落，补充 4 个新概念至 Key Concepts + 433| - 创建 4 个 Concept 页面：Zero-Friction-Capture.md、Cumulative-Memory.md、Conversational-Interface.md、Text-and-Search.md + 434| - 创建 1 个 Entity 页面：Tiago-Forte.md + 435| - 与 [[dataview-让我从"笔记黑洞"里逃出来的-obsidian-神器-1]] 存在冲突记录：Obsidian + Dataview（结构化查询）vs Second Brain（极简搜索）——互补而非互斥 + 436| - 与 [[custom-morning-brief]] 和 [[self-healing-home-server]] 属相似模式（零摩擦信息捕获 + AI 主动管理），已记录为 Connections + 437| - 与 [[habit-tracker-accountability-coach]] 的互补关系：Second Brain 管理想法/链接/书目，Habit Tracker 管理习惯行为——场景不同但方法论相似 + 438| - 冲突检测：无与其他已摄入来源的实质性内容冲突 + 439| + 440| + 441|- Status: ✅ 成功摄入 + 442|- Summary: AI Agent 作为家庭服务器基础设施的全天候自动驾驶代理——OpenClaw + SSH + Cron Job 系统实现自动健康监控、故障自愈（重启 Pod/扩缩容/修复配置）、邮件分拣、每日 8AM 晨报（天气/日历/系统状态/看板）、知识库录入和安全审计。核心洞察：Cron Job 是真正的产品；知识提取具有复利效应；AI 会硬编码 secrets，TruffleHog pre-push hooks 是必须配置的防线；Local-first Git 是防止 API Key 暴露的架构基础。 + 443|- Concepts created: [[Morning Briefing]], [[Email Triage]], [[Local-first Git]], [[Defense-in-Depth]] + 444|- Entities created: [[K3s]], [[Gitea]], [[TruffleHog]] + 445|- Entities updated: [[OpenClaw]]（追加 self-healing-home-server 到 sources） + 446|- Source page: wiki/sources/self-healing-home-server.md + 447|- Notes: + 448| - 新增 Sources 条目至 index.md（替换缺失条目） + 449| - 更新 overview.md，添加 "Self-Healing Infrastructure Agent" 章节 + 450| - 创建 3 个 Entity 页面：K3s.md、Gitea.md、TruffleHog.md + 451| - 创建 4 个 Concept 页面：Morning-Briefing.md、Email-Triage.md、Local-first-Git.md、Defense-in-Depth.md + 452| - 冲突已记录：Prometheus/Grafana 监控方案（人工介入）vs AI Agent 自愈方案（全自动闭环） + 453| + 454|## [2026-04-22] ingest | AI-Powered Earnings Tracker + 455|- Source file: Agent/usecases/earnings-tracker.md + 456|- Status: ✅ 成功摄入 + 457|- Summary: AI Agent 自动化追踪科技公司财报——每周日 Cron Job 扫描财报日历并通过 Telegram 推送，用户选择后为每家公司创建一次性 Cron Job，财报发布后自动搜索结果并生成结构化摘要（beat/miss、营收、EPS、AI 亮点）。 + 458|- Concepts created: （无新概念；Cron Job 已在其他来源中建立） + 459|- Entities created: （无新实体；OpenClaw 已存在；科技公司 NVDA/MSFT 等无需独立页面） + 460|- Source page: wiki/sources/earnings-tracker.md + 461|- Notes: + 462| - 新增 Sources 条目至 index.md（插入首行） + 463| - 无需更新 overview.md（与现有 OpenClaw + Cron Job 主题一致） + 464| - 无需创建 Entity/Concept 页面 + 465| - 无冲突 + 466| + 467|## [2026-04-23] ingest | Multi-Agent Specialized Team (Solo Founder Setup) + 468|- Source file: Agent/usecases/multi-agent-team.md + 469|- Status: ✅ 成功摄入 + 470|- Summary: 用多个专业化 AI Agent 组建团队，解决一人创业者（Solo Founder）身兼数职的困境——4 个专业 Agent（Milo/策略、Josh/商业、Marketing/营销、Dev/开发）通过共享记忆 + 私有上下文 + Telegram 单一控制平面协调运作，定时任务驱动主动工作流。 + 471|- Concepts created: [[Agent Personality]], [[Agent Specialization]], [[Shared Memory Architecture]], [[Private Context]], [[Single Control Plane]], [[Scheduled Task Flywheel]], [[Parallel Agent Execution]] + 472|- Entities updated: [[OpenClaw]]（追加 multi-agent-team 到 sources） + 473|- Source page: wiki/sources/multi-agent-team.md + 474|- Notes: + 475| - 新增 Sources 条目至 index.md（插入首行） + 476| - 更新 overview.md Key Concepts，添加 5 个新概念 + 477| - 创建 6 个 Concept 页面 + 478| - 更新 OpenClaw.md sources 字段 + 479| - 冲突已记录：Multi-Agent Team（并行专业化分工）vs Content Factory（链式协作） + 480| + 481|## [2026-04-23] ingest | Daily YouTube Digest + 482|- Source file: Agent/usecases/daily-youtube-digest.md + 483|- Status: ✅ 成功摄入 + 484|- Summary: AI Agent 每日 YouTube Digest 全自动流水线——通过 youtube-full skill（ClawHub）监控订阅频道新视频，用 TranscriptAPI.com 提取字幕，AI 生成要点摘要后推送。两种模式：频道列表 + 关键词搜索。`channel/latest` 免费检查，`seen-videos.txt` 避免重复付费。核心洞察：把算法推荐的"被动消费"转变为系统化的"主动学习"。 + 485|- Concepts created: [[Daily-Digest]], [[Transcript-Based Summarization]], [[Channel-Based Monitoring]], [[Keyword-Based Monitoring]], [[Credit-Efficient Processing]] + 486|- Entities updated: [[OpenClaw]]（追加 sources） + 487|- Entities created: [[TranscriptAPI.com]], [[ClawHub]], [[Recapio]] + 488|- Source page: wiki/sources/daily-youtube-digest.md + 489|- Notes: + 490| - 新增 Sources 条目至 index.md（顶部插入） + 491| - 更新 overview.md，补充 AI-Powered Daily Digest 章节到 YouTube Automation + 492| - 更新 OpenClaw.md sources + 493| - 创建 3 个 Entity 页面：TranscriptAPI.com.md、ClawHub.md、Recapio.md + 494| - 创建 5 个 Concept 页面：Daily-Digest.md、Transcript-Based-Summarization.md、Channel-Based-Monitoring.md、Keyword-Based-Monitoring.md、Credit-Efficient-Processing.md + 495| - 与 [[实战笔记-本地部署-rsshub-并获取-youtube-订阅]] 的互补关系已在 Contradictions 节记录（RSSHub 被动监控 vs AI Digest 主动学习） + 496| +- Source file: Agent/usecases/meeting-notes-action-items.md +- Status: ✅ 成功摄入 +- Summary: AI Agent 将会议转录文本（Otter.ai、Google Meet、Zoom）自动转换为结构化摘要，提取行动项并创建 Jira/Linear/Todoist/Notion 任务，发送 Slack/Discord 摘要，支持截止日提醒。核心洞察：自动任务创建比摘要本身更有价值，无法转化为追踪任务的会议记录只是"文档剧场"。 +- Concepts created: [[MeetingNotes]], [[ActionItemTracking]], [[TaskAutomation]], [[TranscriptProcessing]] + +## [2026-04-23] ingest | 14个免费的AI图生视频工具，用AI让图片动起来 +- Source file: AI/14个免费的AI图生视频工具，用AI让图片动起来 - AI视频教程 AI自动化工作流定制服务 AI培训学习平台 黑喵大叔.md +- Status: ✅ 成功摄入 +- Summary: 14个免费AI图生视频工具盘点——覆盖阿里巴巴（绘蛙、通义万相、万相营造）、字节跳动（即梦AI）、快手（可灵AI）、智谱AI（智谱清影）、MiniMax（海螺AI）、生数科技（Vidu）、爱诗科技（PixVerse）、潞晨科技（Video Ocean）、智象未来（Viva）、MewXAI（艺映AI）、Stability AI（Stable Video）等厂商。核心能力：文本提示词控制、动作模板、运镜参数、首尾帧控制、主体一致性、音效自动生成。电商/视频创作/广告三大应用场景。 +- Concepts created: [[AI图生视频]], [[AI文生视频]], [[主体一致性]], [[运镜控制]], [[首尾帧控制]], [[提示词控制]] +- Entities created: 14个工具均作为 Key Entities 记录于 Source 页面 +- Source page: wiki/sources/14个免费的ai图生视频工具-用ai让图片动起来-ai视频教程-ai自动化工作流定制服务-ai培训学习平台-黑喵大叔.md +- Notes: + - 更新 index.md，修正条目日期为 2025-12-05 并补充摘要描述 + - 更新 overview.md，新增 AI图生视频工具盘点章节 + - 创建 Concept 页面：AI图生视频.md、AI文生视频.md + - 所有14个工具作为 Key Entities 记录于 Source 页面，未创建独立 Entity 页面（每个工具仅出现1次，未达≥2阈值） + - Contradictions：无冲突 + +## [2026-04-23] ingest | 文字生成视频网站推荐 +- Source file: AI/文字生成视频网站推荐.md +- Status: ✅ 成功摄入 +- Summary: 5款文字生成视频AI工具推荐——万彩AI（完全免费，适合新手）、百度AI开放平台（大厂多模态技术）、Zeemo（多语言字幕，$79+）、Vizard（长视频自动剪辑）、快影（腾讯系模板剪辑）。总结推荐：最实惠选万彩AI，技术型选百度，多语言选Zeemo，长视频选Vizard。 +- Concepts created: [[文字生成视频]], [[AI视频生成工具]], [[数字人]] +- Source page: wiki/sources/文字生成视频网站推荐.md +- Notes: + - 新增 Sources 条目至 index.md（替换 expected 标记行） + - overview.md 中已存在与 [[AI图生视频工具盘点]] 的互补关系说明，无需更新 + - 所有工具作为 Key Entities 记录于 Source 页面，未创建独立 Entity 页面（每个工具仅出现1次，未达≥2阈值） + - Contradictions：无冲突 + +## [2026-04-23] ingest | 清华出的DeepSeek使用手册，104页，真的是太厉害了！（免费领取） +- Source file: AI/清华出的DeepSeek使用手册，104页，真的是太厉害了！（免费领取）.md +- Status: ✅ 成功摄入 +- Summary: 清华大学发布的《DeepSeek从入门到精通2025》官方使用手册（104页），由新闻与传播学院元宇宙文化实验室余梦珑博士后及团队撰写。手册核心价值在于"授人以渔"——不仅教用户"怎么问"，更教"为什么这么问"，帮助用户掌握提示词底层逻辑。涵盖 DeepSeek-R1 模型选择、提示语设计技巧、避免 AI 幻觉策略。内容实用性与理论深度兼备，适合不同层次读者。 +- Concepts created: [[DeepSeek-R1]], [[提示语设计]], [[AI幻觉]], [[通用人工智能（AGI）]], [[推理模型]] +- Entities created: [[DeepSeek]], [[余梦珑]] +- Source page: wiki/sources/清华出的deepseek使用手册-104页-真的是太厉害了-免费领取.md +- Notes: + - 新增 Sources 条目至 index.md（替换 expected 标记行） + - overview.md 新增 DeepSeek 使用手册条目，归入 AI Tools & Prompt Engineering 部分 + - 创建 Entity 页面：DeepSeek.md（公司）、余梦珑.md（作者） + - Concept 页面：RAG.md、Large-Language-Model.md、AI-Agent.md 已覆盖相关概念（幻觉、推理模型），无需新建 + - Contradictions：与 [[llms-rag-ai-agent-三个到底什么区别]] 互补而非冲突——前者聚焦 DeepSeek 特定实践，后者聚焦 LLM/RAG/Agent 三层架构宏观对比，均记录于 Contradictions 小节 + +## [2026-04-23] ingest | How to Get the RSS Feed For Any YouTube Channel +- Source file: AI/How to Get the RSS Feed For Any YouTube Channel.md +- Status: ✅ 成功摄入 +- Summary: 作者 Chuck Carroll 分享获取 YouTube 频道 RSS Feed 的简单方法——在频道页面右键选择"查看页面源代码"，搜索 `channel_id=`，提取 RSS Feed URL 格式为 `https://www.youtube.com/feeds/videos.xml?channel_id=`。无需第三方服务，适合 RSS 阅读器用户。 +- Concepts created: [[RSS Feed]], [[Channel ID]] +- Entities updated: [[YouTube]], [[Chuck Carroll]] +- Source page: wiki/sources/how-to-get-the-rss-feed-for-any-youtube-channel.md +- Notes: + - RSS Feed 和 Channel ID Concept 已存在于 overview.md 相关章节 + - YouTube Entity 已存在于 overview.md Key Entities 列表 + - 无需新建 Entity 或 Concept 页面 + - 无内容冲突 + +## [2026-04-23] ingest | codecrafters-io/build-your-own-x +- Source file: raw/AI/codecrafters-iobuild-your-own-x Master programming by recreating your favorite technologies from scratch.md +- Status: ✅ 成功摄入 +- Summary: GitHub 精选教程列表，26+ 技术领域分步骤指南，引用 Richard Feynman "What I cannot create, I do not understand" 作为核心理念，通过从零重建主流技术实现深度技术理解。 +- Entities created: CodeCrafters, DanielStefanovic, RichardFeynman +- Concepts created: Build-Your-Own-X, Learn-By-Building +- Source page: wiki/sources/codecrafters-iobuild-your-own-x-master-programming-by-recreating-your-favorite-technologies-from-scratch.md +- Notes: + - 冲突检测：BYOX vs 传统课程式学习（理论优先 vs 实践优先）已记录于 Source Page Contradictions + - index.md 和 overview.md 均已更新 + - 覆盖 26+ 领域：3D Renderer, Web Browser, Database, Docker, Git, OS, Programming Language, Neural Network 等 + - 支持 15+ 编程语言：C++, Python, Java, JavaScript, Go, Rust, Haskell, TypeScript 等 + - 与 Vibe Coding 互补：BYOX 理解原理，Vibe Coding 高效实现 + +## [2026-04-18] ingest | 电商如何选品 - 如何找到爆款选品策略 +- Source file: 跨境电商/电商如何选品 如何找到爆款 选品策略.md +- Status: ✅ 成功摄入 +- Summary: YouTube 视频摘要，20 种电商选品策略 + 情境配对 + 季节性规划 + POD 低成本测款 + 工具辅助分析（Salesmartly / Erank / Pinterest / Etsy 趋势）。核心观点：未来品牌需针对细分市场而非大众市场；情境配对产品组合提升客单价；POD 模式降低库存风险。 +- Concepts touched: [[电商选品策略]], [[爆款产品]], [[POD模式]], [[情境配对]], [[季节性选品]], [[细分市场定位]] +- Entities touched: [[Salesmartly]], [[Erank]], [[TikTok Shop]], [[Etsy]], [[Pinterest]] +- Source page: wiki/sources/电商如何选品-如何找到爆款-选品策略.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/电商如何选品-如何找到爆款-选品策略.md） + - Concepts 和 Entities 均以 wikilink 形式建立关联，暂不创建独立页面 + - 冲突检测：与 [[做TK跨境思路不对努力白费]] 的平台优先级存在差异，但两者针对产品类型不同（Etsy/POD 手工艺 vs TikTok 快消品），属互补而非冲突 + - 已在 index.md 添加 Source 条目 + - 已在 overview.md TikTok E-commerce Operations 小节新增条目，置于 [[做TK跨境思路不对努力白费]] 之前 + +## [2026-01-26] ingest | 3.2 万人收藏的 Claude Skills，才是 AI 这条路上最值得研究的一套范式！ +- Source file: AI/3.2 万人收藏的 Claude Skills，才是 AI 这条路上最值得研究的一套范式！.md +- Status: ✅ 成功摄入（重复来源，slug 不同） +- Summary: Anthropic 官方 Skills 仓库（github.com/anthropics/skills）介绍；Skills = 说明书 + SOP；标志从「提示词工程」向「流程工程」的范式转变；Vibe Coding 尽头也是 Skills；三大聚合站和 Awesome-Claude-Skills 仓库推荐 +- Concepts identified: 无（已存在于之前摄取） +- Source page: wiki/sources/3-2-万人收藏的-claude-skills-才是-ai-这条路上最值得研究的一套范式.md +- Notes: + - 同来源文章以不同 slug 重复摄取（与 wiki/sources/3-2-万人收藏的-claude-skills-才是-ai-这条路上最值得研究的一套范式-1.md 内容完全一致） + - index.md 已添加新条目 + - 无需新建 Entity 或 Concept 页面 + - 无新内容冲突 + +## [2026-04-26] ingest | Building your Quartz +- Source file: Home Office/Building your Quartz +- Status: ✅ 成功摄入 +- Summary: Quartz 静态网站的本地预览与自托管部署指南。涵盖 `npx quartz build --serve` 本地热重载预览、Nginx/Apache/Caddy 三种 Web 服务器自托管配置（处理无扩展名链接）、baseUrl 配置对 RSS Feed 和 Sitemap 的影响。Obsidian 笔记 → Quartz 构建 → 自托管构成完整个人知识发布链条。 +- Concepts touched: [[Quartz]], [[Static Site Generator]], [[npx quartz build]], [[try_files]], [[RewriteRule]], [[baseUrl]] +- Entities touched: [[Obsidian]], [[GitHub Pages]] +- Source page: wiki/sources/building-your-quartz.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/building-your-quartz.md） + - Concept 和 Entity 均以 wikilink 形式建立关联，Quartz/Nginx/Apache/Caddy 均已在 overview.md 中被提及，不创建独立页面 + - 检测到 1 处潜在冲突（自托管 vs Vercel/Netlify），已记录于 Source Page Contradictions 节 + - index.md Sources 节添加新条目 + - overview.md Productivity & Knowledge Management 部分添加 Quartz 段落 + +## [2026-04-23] ingest | 我做了个 Skill：让 AI 帮你生成 Logo 和图标 +- Source file: raw/Skills/我做了个 Skill：让 AI 帮你生成 Logo 和图标.md +- Status: ✅ 成功摄入 +- Summary: 介绍 Claude Code Skill `baoyu-imagine`（`npx baoyu-imagine` 安装），通过 Logo 专用提示词策略驱动 AI 生图工具生成专业 Logo 和图标。支持扁平化/几何/手绘/渐变等多种风格，SVG（矢量）和 PNG 格式导出。让非设计师快速产出专业品牌视觉资产。 +- Concepts created: AI-Logo-Generation +- Entities created: baoyu +- Source page: wiki/sources/我做了个-skill-让-ai-帮你生成-logo-和图标.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/我做了个-skill-让-ai-帮你生成-logo-和图标.md） + - 新增 1 个 Concept 页面（AI-Logo-Generation） + - 新增 1 个 Entity 页面（baoyu） + - index.md Sources / Entities / Concepts 三个章节均已追加条目 + - overview.md AI Tools & Prompt Engineering 部分添加 baoyu-imagine AI Logo 生成段落，Key Concepts 追加 baoyu-imagine / AI-Logo-Generation / Claude-Code-Skill + - 无内容冲突（baoyu-imagine 与通用 AI 生图工具形成互补） + +## [2026-04-16] ingest | Obsidian CLI +- Source file: raw/Skills/Obsidian CLI.md +- Status: ✅ 成功摄入 +- Summary: Obsidian v1.12+ 内置的官方命令行工具文档，覆盖 60+ 命令（日常操作/文件管理/插件管理/属性操作/开发者命令/版本管理/发布/同步等），提供 TUI 交互模式和单命令两种使用方式。开发者命令通过 Chrome DevTools Protocol 实现截图、控制台执行、插件热重载。AI Agent 可通过标准化 CLI 接口实现笔记增删改查、日程管理、搜索、任务操作等全部 GUI 功能，无需图形界面。 +- Concepts updated: [[Obsidian-CLI]]（补充 8 大能力域：日常操作/文件管理/插件管理/属性操作/开发者命令/版本管理/工作区管理/TUI 交互） +- Entities updated: [[Obsidian]]（添加 obsidian-cli 来源引用，更新 last_updated） +- Source page: wiki/sources/obsidian-cli.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/obsidian-cli.md） + - 更新 Obsidian-CLI concept 页面，补充 8 大能力域和 TUI 交互模式说明 + - 更新 Obsidian entity 页面，添加 sources 字段 + - 更新 wiki/index.md Sources 节（新增 Obsidian CLI 条目，置顶） + - 更新 wiki/overview.md Productivity & Knowledge Management 部分（补充 Obsidian-CLI 与其他 Agent 集成方案的互补关系） + - 冲突记录：与 [[obsidian-必装-skills]] 中 obsidian-cli 的描述存在"官方内置"vs"kepano 发布 Skill"的视角差异，已记录至 Source Page Contradictions，结论为两者均正确（obsidian-cli 既是 Obsidian 官方内置功能，也是 kepano Skills 项目收录整理的工具） + - 新建 Concept/Entity 页面：无（Obsidian-CLI concept 页面已于 2026-04-21 创建，本次仅更新内容；Obsidian entity 页面已存在，本次仅更新 sources 字段） + +## [2026-04-23] ingest | WSL2 启动与网络配置指南 +- Source file: raw/Home Office/WSL2 启动与网络配置指南.md +- Status: ✅ 成功摄入 +- Summary: WSL2（Windows Subsystem for Linux 2）安装启动与网络配置实操指南。核心内容：① wsl --install 快速安装 Ubuntu；② .wslconfig 启用 networkingMode=mirrored 镜像网络模式解决 localhost 代理失效问题；③ 终端环境变量手动配置代理；④ ghproxy.com 反向代理加速 GitHub 下载。关键洞察：NAT 模式是 WSL2 无法访问 Windows 宿主机代理的根本原因，镜像网络模式是推荐解决方案。 +- Concepts created: WSL2、镜像网络模式、NAT模式、ghproxy +- Entities created: WSL2、ghproxy +- Source page: wiki/sources/wsl2-启动与网络配置指南.md +- Notes: + - 新增 1 个 Source Page（wsl2-启动与网络配置指南.md） + - 更新 wiki/index.md（Sources 章节补全缺失条目） + - 更新 wiki/overview.md（Home Server Automation 部分新增 WSL2 章节段落；Key Entities 部分新增 WSL2 和 ghproxy 条目） + - 无内容冲突 + - 新建 Concept/Entity 页面：无（WSL2 和 ghproxy 作为 Entity/Concept 在 overview.md 中描述，未创建独立页面） + +## [2026-04-24] ingest | Blogwatcher Daily 技能收藏 +- Source file: Skills/blogwatcher-daily收藏.md +- Status: ✅ 成功摄入 +- Summary: Hermes Agent 自定义 Skill `blogwatcher-daily` 的收藏笔记，实现 31 个 RSS/YouTube 订阅频道的自动化监控与每日摘要生成。通过 SQLite 数据库按 URL 去重，日常扫描追加写入 `YYYY-MM-DD.md` 日报，强制回扫写入独立文件。YouTube 频道通过本地 RSSHub 代理转换为 RSS Feed。 +- Concepts created: 无（RSS Monitoring、Cron Job、RSSHub、每日日报 等均为已有或通用概念，在 overview.md Key Concepts 中已有覆盖） +- Entities created: 无（blogwatcher-daily 作为 Skill 名在 sources 中描述；feedparser 仅出现1次，不满足 ≥2 次创建条件） +- Source page: wiki/sources/blogwatcher-daily收藏.md +- Notes: + - 新增 1 个 Source Page + - 更新 wiki/index.md（Sources 章节补全缺失条目） + - 更新 wiki/overview.md（YouTube Automation 部分 RSSHub 段落新增对 blogwatcher-daily 的关联说明） + - 无内容冲突 + - 新建 Concept/Entity 页面：无 + +## [2026-04-23] ingest | CTP Topic 1 Gruntwork Landing Zone Architecture +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-1-gruntwork-landing-zone-architecture.md +- Status: ✅ 成功摄入 +- Summary: Gruntwork AWS Landing Zone 架构基础培训。核心：参考架构（Reference Architecture）是包含核心账户（Shared/Logs/Security）和工作负载账户（Prod/Stage/Dev）的最佳实践起点；Landing Zone 基于 Gruntwork 由产品团队自行定义具体服务；安全账户使用联邦用户（Federated User）通过 AD 组映射到 IAM 角色；每个 Landing Zone 配置独立 Jenkins 服务器和特性分支 Git 工作流；Terraform AWS 服务目录强调服务应具有业务上下文。 +- Concepts created: Reference-Architecture, Landing-Zone-Architecture, Federated-Access, CI-CD-Pipeline, Terraform-Modules +- Entities created: 无（Gruntwork Entity 已存在） +- Source page: wiki/sources/ctp-topic-1-gruntwork-landing-zone-architecture.md +- Notes: + - 新增 1 个 Source Page + - 更新 wiki/index.md（Sources 章节替换预期条目为实际摘要；Concepts 章节新增 5 个概念） + - 更新 wiki/overview.md（Cloud Transformation 部分新增 CTP Topic 1 段落） + - 冲突检测：与 ctp-topic-35-aws-landing-zone-design-refresher-saas-labs 在 Landing Zone 产品定义粒度上有视角差异（前者强调灵活性，后者强调标准化），已记录于 Source Page Contradictions 节，判定为视角互补而非直接冲突 + - 新建 Concept 页面：5 个（Reference-Architecture / Landing-Zone-Architecture / Federated-Access / CI-CD-Pipeline / Terraform-Modules） + - 新建 Entity 页面：无（Gruntwork Entity 已存在，无需重复创建） + +## [2026-04-14] ingest | CTP Topic 73 AWS Backup Implementation of the Cloud Transformation Programme +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program.md +- Status: ✅ 成功摄入 +- Summary: AWS Backup 在云转型计划中的企业级实施落地。SRE 团队开发 SRE Backup Model，为产品组提供预置的 AWS Backup Plans、Vaults、KMS 密钥策略等模板，支持 DRA 账户内独立备份和恢复；初始备份复制到远程 DR 账户实现即时恢复；AWS Backup Audit Manager 提供合规审计报告和控制评估。 +- Concepts created: [[SRE Model]] +- Source page: wiki/sources/ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program.md +- Notes: + - 新增 1 个 Source Page + - 新增 1 个 Concept（SRE Model） + - index.md 更新：Sources 节新增条目，附中文摘要 + - 冲突检测：与 [[ctp-topic-44-aws-backup-in-micro-focus]] 视角互补而非冲突——前者为 CTP 实施确认，后者为内部评估，AWS Backup 的局限性已在 Contradictions 节记录 + - AWS Backup / AWS Backup Audit Manager / 跨账户备份 已在 ctp-topic-72 摄入，无需重复创建 + +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-28-aws-tag-validation-tool.md +- Status: ✅ 成功摄入 +- Summary: Lewis Brown 主讲，SRE 团队开发的 AWS 标签验证工具。Checkpoint 防火墙通过读取 EC2/安全组/负载均衡器标签值配置网络访问策略，标签缺失或无效时拦截流量；SCPs 只能阻止新资源创建，无法修复存量资源。该工具通过 variables.yaml 定义每个账户合法标签值，自动扫描 EC2/SG/LB/Lambda，比对配置输出 CSV 审计报告。使用 Poetry 管理 Python 环境，存放于 SRE Tools Repository。标签还计划用于成本核算。 +- Entities created: [[Checkpoint]], [[SRE-Team]] +- Concepts created: [[AWS-Tags]], [[AWS-Tagging-Standards]], [[Tag-Validation-Tool]], [[Service-Control-Policies-SCPs]], [[Variables-YAML]] +- Source page: wiki/sources/ctp-topic-28-aws-tag-validation-tool.md +- Notes: + - 新增 1 个 Source Page + - 新增 2 个 Entity（Checkpoint / SRE-Team） + - 新增 5 个 Concept（AWS-Tags / AWS-Tagging-Standards / Tag-Validation-Tool / Service-Control-Policies-SCPs / Variables-YAML） + - overview.md 更新：新增 CTP Topic 28 摘要段落（置于 ctp-topic-17 之后，ctp-topic-47 之前），Key Concepts 节新增 6 个概念标注（AWS-Tagging-Standards / Tag-Validation-Tool / Service-Control-Policies-SCPs / Variables-YAML / Checkpoint-Firewall / SRE-Tools-Repository） + - index.md 更新：Sources 节替换预期条目为实际摘要，Entities 节新增 2 个实体，Concepts 节新增 6 个条目 + - 冲突检测：与 [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] 互补而非冲突——后者聚焦标签收集机制和安全策略上下文，前者聚焦审计发现，共同构成"制定规范 → 强制执行 → 审计发现"的标签治理闭环 + - Lewis Brown 仅出现 1 次，未创建 Entity 页面 + +## [2026-04-14] ingest | CTP Topic 10 AWS Landing Zone (LZ) Data Collection, Tagging Related Security +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md +- Status: ✅ 成功摄入 +- Summary: Steve Jarman 和 Pradeep 主讲 AWS Landing Zone 部署流程、数据收集策略与基于标签的云原生安全架构。核心：①Landing Zone 部署前需了解 BU 资产清单/IP 地址空间/数据敏感性；②DNS/Transit Gateway 等基础服务已通过 SRE 高度自动化；③基于标签的安全控制——用 AWS 标签替代传统 IP 防火墙规则；④SCP 强制执行标签规范——通过"显式拒绝"防止篡改标签绕过审计；⑤Checkpoint 防火墙有序层——按优先级执行地理屏蔽 → BU 隔离 → 产品隔离 → 环境隔离。 +- Concepts created: 无（所有概念均已在 [[ctp-topic-28-aws-tag-validation-tool]] 中创建） +- Source page: wiki/sources/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md +- Notes: + - 新增 1 个 Source Page + - 无新增 Concept（[[AWS_Landing_Zone]] / [[Tagging_Methodology]] / [[SCP_Service_Control_Policy]] / [[OU_Organizational_Unit]] / [[Checkpoint_Firewall_Ordered_Layer]] / [[Transit_Gateway]] / [[SRE_Automation]] 均已在 ctp-topic-28 中创建） + - overview.md 更新：新增 CTP Topic 10 摘要段落（置于 ctp-topic-1 之后），补充标签治理闭环描述 + - index.md 更新：Sources 节新增条目（置顶） + - 冲突检测：无冲突 + - Steve Jarman 仅出现 1 次，Pradeep 仅出现 1 次，均未创建 Entity 页面 + - 与 [[ctp-topic-1-gruntwork-landing-zone-architecture]] 互补——前者为基础架构，后者为安全层扩展 + - 与 [[ctp-topic-28-aws-tag-validation-tool]] 互补——构成"制定规范 → 强制执行 → 审计发现"的标签治理闭环 + +## [2026-04-14] ingest | CTP Topic 25 Labs Landing Zone Overview - ITOM Teams +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-25-labs-landing-zone-overview-itom-teams.md +- Status: ✅ 成功摄入 +- Summary: Labs Landing Zone 基于 Gruntwork 参考架构的多账户策略——核心账户包括 Shared（Jenkins 主节点/加固 AMI/容器仓库）、Logs（CloudTrail/Config 日志）、Security（联邦用户/跨账户访问）、Core（AD 管理 Windows 实例和 IDP/DNS 管理 Swimford.net）、Network（Transit Gateway + JetPult 防火墙/标签驱动的网络策略/Pulse VPN）；Shared Services 提供 45 Arc Site 监控和 Qualys 漏洞扫描；Product Account 通过 Terraform/Terragrunt 模块部署，需与网络团队协调 IP 范围和标签策略；Jenkins 流水线扫描 GitHub Enterprise 仓库变更，触发 Terragrunt plan/apply，并通过 pre-commit 和 Fortify 扫描提升安全。 +- Concepts created: 无（所有概念均已在其他 CTP 页面中创建：[[Landing Zone Architecture]] / [[Terraform]] / [[Terragrunt]] / [[Jenkins]] / [[Transit Gateway]] / [[Federated Access]] / [[Tag-Based Access Control]]） +- Source page: wiki/sources/ctp-topic-25-labs-landing-zone-overview-itom-teams.md +- Notes: + - 新增 1 个 Source Page + - 无新增 Concept/Entity（Gruntwork/Jenkins/JetPult/Pulse VPN/Qualys/45 Arc Site 均仅出现 1 次，不满足 ≥2 次建页条件） + - overview.md 更新：新增 CTP Topic 25 摘要段落（置于 ctp-topic-35 之前），补充 Labs LZ 运维实践描述 + - index.md 更新：Sources 节新增条目（置顶于 CTP Topic 34 之前），移除旧 "source missing" 标记 + - 冲突检测：无冲突 + - 属 [[ctp-topic-1-gruntwork-landing-zone-architecture]]（架构基础）和 [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]]（SaaS vs Labs 职责划分）共同构成完整的 AWS Landing Zone 知识体系 + +## [2026-04-24] ingest | Public Cloud Learning Sessions - Tagging Standards for All Hyperscalers - 20240123 +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-tagging-standards-for-all-hyperscalers-20240123-1.md +- Status: ✅ 成功摄入 +- Summary: OpenText 跨 AWS/Azure/GCP 的统一标签标准，目标将云浪费从 30% 降至 15%，预计年节省 2500 万美元。标准采用 OT_ 前缀标签、GCP 限制性字符集作为最低通用标准，通过 Terraform 默认标签注入和 SCP 强制执行实现合规化。 +- Concepts referenced: [[FinOps]], [[Service-Control-Policies-SCPs]], [[Tag-Based-Security]], [[Terraform-Tagging]], [[Multi-Cloud-Governance]]（均已在其他页面定义，无需新建） +- Entities referenced: [[Tom Bice]]（仅出现 1 次，不满足 ≥2 次建页条件，未创建独立页面） +- Source page: wiki/sources/public-cloud-learning-sessions-tagging-standards-for-all-hyperscalers-20240123-1.md +- Notes: + - 新增 1 个 Source Page + - 无新增 Concept/Entity 页面 + - index.md 更新：移除 "source missing" 标记，添加正式条目 + - 冲突检测：无冲突 + - 属 [[public-cloud-learning-sessions-opentext-tagging-standard-v2]]（v2 扩展 v1，覆盖 K8s 和容器镜像标签）、[[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]]（基于标签的安全控制机制）、[[ctp-topic-28-aws-tag-validation-tool]]（标签合规审计）共同构成完整的标签治理知识体系 + +## [2026-04-25] ingest | Public Cloud Learning Sessions (OpenText) - Product Hub (PHT) Overview and Q&A - 20240806 +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-opentext-product-hub-pht-overview-and-qa-20240806.md +- Status: ✅ 成功摄入 +- Summary: OpenText Product Hub（PhD/PHT）产品层次结构追踪器功能概述——三层层级（业务单元→业务线→产品）、自助服务新建流程、与 Jira/Value Edge/PSMQ/ITLS/OSS 等外部系统集成、Source Repo 和 Artifact Repo 权限管理。 +- Concepts created: [[Product Hub (PhD)]]（已引用） +- Entities created: 无（OpenText 相关 Entity 仅出现 1 次，不满足 ≥2 次建页条件） +- Source page: wiki/sources/public-cloud-learning-sessions-opentext-product-hub-pht-overview-and-qa-20240806.md +- Notes: + - 新增 1 个 Source Page + - 无新增 Concept/Entity 页面 + - index.md 更新：移除 "source missing" 标记，添加正式条目 + - 冲突检测：无冲突 + +## [2026-04-30] ingest | Learning Sessions Identity Governance VSM Replacement - 20231128 +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/02_IAM/learning-sessions-identity-governance-vsm-replacement-20231128-160326-meeting-re.md +- Status: ✅ 成功摄入 +- Summary: 身份治理（Identity Governance）框架与 VSM→Micro Focus IGA 替换计划——身份治理三问：谁当前有访问/谁该访问/如何访问；Micro Focus IGA 通过 AD 组工作流管控权限审批，配合 AWS Identity Center + IAM 提供云资源访问；VSM 将被 IGA 全面替换，保持原架构但改接 Coptum 域，POC 正在进行。 +- Concepts created: [[Identity-Governance]] +- Entities created: [[Micro-Focus-IGA]], [[DXC-VSM]] +- Source page: wiki/sources/learning-sessions-identity-governance-vsm-replacement-20231128-160326-meeting-re.md +- Notes: + - 新增 1 个 Source Page + - 新增 1 个 Concept 页面（wiki/concepts/Identity-Governance.md） + - 新增 2 个 Entity 页面（wiki/entities/Micro-Focus-IGA.md, wiki/entities/DXC-VSM.md） + - index.md 更新：移除 "source missing" 标记，添加正式条目；在 Entities 和 Concepts 节添加新页面 + - overview.md 新增条目，位于 CTP Topic 17（AD 集成）之后 + - 冲突检测：无已知冲突内容 + +## [2026-04-25] ingest | CTP Topic 60 Monitor AWS using Hyperscale Observability with Grafana +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana.md +- Status: ✅ 成功摄入 +- Summary: 使用 Grafana Enterprise + Optic DR 数据源 + Opsbridge 告警 + Terraform IaC 模块实现 AWS 超大规模可观测性监控——推荐迁移至 Enterprise License 释放完整功能；Optic DR（VaticaDB 插件）是 Grafana 从 AWS 拉取数据的关键中间件；Terraform 模块为产品团队自动化创建 Grafana Organizations、用户、文件夹和仪表盘；EC2 Inventory 仪表盘可识别运行/未运行 EC2 实例及标签合规状态。 +- Concepts identified: [[Grafana-Enterprise]], [[Observability（可观测性）]], [[Opsbridge]], [[Optic-DR]], [[Terraform-Module]], [[Resource-Tagging]] +- Entities identified: [[Grafana-Labs]], [[VaticaDB]], [[PagerDuty]], [[Slack-Manager]]（均以 wikilink 形式记录于 Source page，无需独立页面） +- Source page: wiki/sources/ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana.md） + - 无新增 Concept/Entity 页面（已识别概念均作为 wikilink 嵌入 Source page） + - index.md 更新：在 Sources 节顶部添加新条目 + - 冲突检测：与 ctp-topic-42-grafana-observability-dashboard 存在潜在张力（开源版 vs Enterprise License） + +## [2026-04-25] ingest | CTP Topic 70 EKS deployment using IAC +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-70-eks-deployment-using-iac.md +- Status: ✅ 成功摄入 +- Summary: EKS 集群通过 IaC（Terraform + Service Catalog）部署的完整方法论——两种部署路径（Terraform `tera-grant.scl` vs Service Catalog 模块）、EMI 自定义网络解决 VPC CIDR 限制、Cluster Autoscaler 自动扩缩容 Worker Node、CloudWatch Agent + FluentBit + Container Insights + OpenTelemetry + Grafana 完整监控栈。 +- Concepts created: [[Amazon EKS]], [[Cluster Autoscaler]], [[Infrastructure as Code]], [[Kubernetes]]（已有 entity，新增 source 引用） +- Entities updated: [[Kubernetes]]（添加 source 引用） +- Source page: wiki/sources/ctp-topic-70-eks-deployment-using-iac.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/ctp-topic-70-eks-deployment-using-iac.md） + - 新增 3 个 Concept 页面：Amazon EKS、Cluster Autoscaler、Infrastructure as Code + - Kubernetes entity 页面已存在，更新添加新 source 引用 + - index.md 更新：在 Sources 节顶部添加新条目；在 Concepts 节添加 3 个新条目；移除 "source missing" 标记 + - overview.md 更新：添加新条目，位于 EKS Auto Mode 条目之后 + - 冲突检测：与 ctp-topic-59-achieving-reliability-with-amazon-eks 可能存在内容重叠（侧重点不同：Topic 70 侧重部署方法，Topic 59 侧重可靠性实践） + +## [2026-04-27] ingest | Public Cloud Learning Sessions - Observability with OpenTelemetry +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113-.md +- Status: ✅ 成功摄入 +- Summary: Jay Comer（AWS 解决方案架构师）主讲 OpenTelemetry 可观测性全景——三信号模型（Metrics/Logs/Traces）、OTLP 协议 + 11 种语言 SDK + Collector 架构、AWS Distribution for OpenTelemetry（统一代理 + EKS Operator 自动注入）、Fluent Bit → OTel Collector（端口 55681）→ Amazon OpenSearch 端到端管道演示。 +- Concepts created: [[OpenTelemetry]], [[Observability（可观测性）]], [[Three Signals]], [[OTLP（OpenTelemetry Protocol）]], [[Fluent Bit]] +- Entities identified: [[Jay Comer]] +- Source page: wiki/sources/public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113.md +- Notes: + - 新增 1 个 Source Page + - index.md 更新：新增条目（日期 2024-04-02） + - overview.md 更新：新增条目于 Cloud Transformation & DevOps → EKS 知识链路；Key Concepts 新增 5 个条目 + - 新增 Entity 页面：Jay-Comer.md + - 新增 Concept 页面：OpenTelemetry.md + - 冲突检测：与 ctp-topic-54-esm-saas-log-analytics（ELK 日志）、ctp-topic-67（CTP Topic 67 OpenTelemetry）互补，无冲突 + +## [2026-04-25] ingest | CTP Topic 33 An Introduction to GitOps +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-33-an-introduction-to-gitops.md +- Status: ✅ 成功摄入 +- Summary: GitOps 方法论入门——将软件开发原则应用于部署流程；四大原则（声明式配置 + 版本控制 + CD 流程分离 + 自修复协调器）；Pull 模型优于 Push 模型；幂等平台（Kubernetes）是 CD 顺利运行的必要条件；Git 提交日志即合规审计追踪 +- Concepts created: [[GitOps]] +- Entities identified: [[Victor Etkin]] +- Source page: wiki/sources/ctp-topic-33-an-introduction-to-gitops.md +- Notes: + - 新增 1 个 Source Page + - 新增 1 个 Concept 页面：GitOps.md（覆盖四大原则、Pull vs Push 模型、与 IaC 关系） + - index.md 更新：新增条目于 CI_CD_GitOps 分类 + - overview.md 更新：新增条目于 Cloud Transformation & DevOps 章节，GitOps 知识链路 + - Key Entities 中提及的 Victor Etkin 仅出现 1 次，不满足 ≥2 次条件，以 wikilink 形式记录于 Source page + - Key Concepts 中 Kubernetes/Atlantis 已有 wikilink 指向其他 Source page + - 冲突检测：与 ctp-topic-39（Atlantis 不支持 EKS）存在 Atlantis + Kubernetes 实践约束差异，已记录于 Source page Contradictions + +## [2026-04-24] ingest | CTP Topic 56 Automated Infrastructure Testing +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-56-automated-infrastructure-testing.md +- Status: ✅ 成功摄入 +- Summary: Mark Francis 主讲自动化基础设施测试，倡导将 TerraTest（Golang 框架）应用于 Terraform IaC 的 apply → test → destroy 自动化验证循环；核心主张集成测试超越语法检查，TDD 应用于 IaC 领域，测试作为首要开发步骤；价值观："让机器做重复的事，把人脑留给复杂的人类问题" +- Concepts identified: [[Infrastructure Testing]], [[TerraTest]], [[Test-Driven Development (TDD)]], [[IaC Testing Framework]] +- Source page: wiki/sources/ctp-topic-56-automated-infrastructure-testing.md +- Notes: + - index.md 更新：新增条目于 CTP Topic 33 (GitOps) 之后 + - overview.md 更新：新增条目于 Cloud Transformation & DevOps 章节，GitOps 和 CI/CD Pipeline 质量保障层 + - Key Entities 中 Mark Francis 仅出现 1 次，不满足 ≥2 次条件，以 wikilink 形式记录于 Source page + - Key Concepts 中 Kubernetes/Atlantis 已有 wikilink 指向其他 Source page + - 冲突检测：与 ctp-topic-39（Atlantis 不支持 EKS）存在 Atlantis + Kubernetes 实践约束差异，已记录于 Source page Contradictions + +## [2026-04-24] ingest | CTP Topic 71 PCG's guide to RightSizing, why, how when +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/ctp-topic-71-pcgs-guide-to-rightsizing-why-how-when.md +- Status: ✅ 成功摄入 +- Summary: PCG 团队讲解 AWS EC2 RightSizing 系统性方法论——为何要做、何时做、如何执行。RightSizing 通过分析实例实际资源使用情况，将过度配置的实例调整为合适规格，在不影响性能前提下实现成本节省。⚠️ 视频尚未完成 Whisper 转录，完整内容待补充 +- Concepts created: RightSizing, EC2 Cost Optimization +- Source page: wiki/sources/ctp-topic-71-pcgs-guide-to-rightsizing-why-how-when.md +- Notes: + - index.md 更新：将原 expected placeholder 更新为正式条目（2026-04-14） + - overview.md 更新：新增条目于 Cloud Transformation & DevOps 章节 FinOps 知识链路 + - RightSizing/Cloud Cost Optimization 已通过 wikilink 嵌入 Source page + - Key Entities: PCG (Platform Control Group) 已在 Wiki 中存在（ctp-topic-13），无需新建 Entity 页面 + - 冲突检测：未发现内容冲突，Contradictions 暂置空占位 + +## [2026-05-06] ingest | Public Cloud Learning Sessions (OpenText) - Generative AI & Prompt Engineering - 20241112 +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111.md +- Status: ✅ 成功摄入 +- Summary: AWS 生成式 AI 服务与提示工程实践，由 OpenText 技术客户经理 Shikad Holtzman（以色列）主讲——生成式 AI 四大价值路径、企业数据差异化核心洞见、Amazon Bedrock 全托管基础模型服务（RAG/微调/Agents/Guardrails）、Amazon Q 助手（企业版/开发者版）、AWS 专用芯片（Trainium/Inferentia）、提示工程四组件（指令/上下文/用户输入/输出指示器）和基础技巧（One-shot/Few-shot、Chain of Thoughts） +- Concepts linked: [[RAG]], [[Prompt-Engineering]], [[Chain-of-Thought]], [[One-Shot-Prompting]], [[Few-Shot-Prompting]], [[Responsible-AI]], [[Guardrails-for-Amazon-Bedrock]] +- Entities linked: [[Shikad-Holtzman]], [[Amazon-Bedrock]], [[Amazon-SageMaker]], [[Amazon-Q]], [[AWS-Trainium]], [[AWS-Inferentia]], [[AWS]] +- Source page: wiki/sources/public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111.md +- Notes: + - index.md 已更新：将原 expected placeholder 更新为正式条目（2026-04-19），补充中文摘要 + - overview.md 已更新：在 Cloud Transformation & DevOps 章节的 AI/ML 入门条目后新增独立段落，与 AI/ML 入门共同构成生成式 AI 知识链路 + - Key Concepts：RAG/Prompt-Engineering/Chain-of-Thought/Few-Shot-Prompting 频次不足独立建 Concept 页阈值，以 wikilink 形式记录于 Source page + - Key Entities：Shikad Holtzman 仅出现 1 次，以 wikilink 形式记录于 Source page；Amazon Bedrock/Q/SageMaker 在同系列其他来源中提及频次不足独立建 Entity 页阈值 + - 同系列来源关联：已建立与 AI/ML 入门（public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin）和无服务器计算（public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee）的 Connections 关系 + - 冲突检测：与 ctp-topic-64-scaling-out-with-amazon-eks 在扩展方式上的差异已记录于 Source page Contradictions（EDA 事件驱动 vs EKS 容器编排，适用于不同场景可互补） + +## [2026-05-06] ingest | Learning Sessions Cloud Transformation Programme-Deploying RDS via Terraform +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform.md +- Status: ✅ 成功摄入 +- Summary: Greg（DBRE 团队）讲解通过 Terraform/Terragrunt 在 AWS 部署 RDS——IaC 六大优势（速度/灵活性/一致性/灾难恢复/文档/自动化）；代码即文档；grunt work RDS Service 推荐生产使用（预建 KMS 加密 + CloudWatch 告警），SRE 核心模块功能弱于 grunt work；Terragrunt 保持代码整洁、避免变量重复；Day 2 运维通过 GitHub PR + Atlantis 实现；CloudWatch Dashboard + Alarms 监控告警，注意突发性能实例 CPU credits +- Concepts linked: [[Infrastructure-as-Code]], [[DRY Principle]], [[GitOps]], [[CloudWatch-Alarms]], [[KMS-Encryption]] +- Entities linked: [[Gruntwork]], [[Atlantis]], [[Terraform]], [[Terragrunt]], [[DBRE]], [[CloudWatch]] +- Source page: wiki/sources/learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform.md +## [2026-04-25] ingest | Paid Media Tracking & Measurement Specialist Agent +- Source file: Agent/agency-agents/paid-media/paid-media-tracking-specialist.md +- Status: ✅ 成功摄入 +- Summary: 付费媒体追踪与归因专家 Agent——由 John Williams（@itallstartedwithaidea）设计，负责构建跨平台（GTM、GA4、Google Ads、Meta CAPI、LinkedIn Insight Tag）的事件追踪架构，确保每一次转化都被正确计数，每一分广告投入都可衡量。核心理念：错误追踪比无追踪更糟糕，错误计数的转化会主动误导出价算法向错误方向优化。 +- Concepts linked: [[GoogleTagManager]], [[GoogleAnalytics4]], [[MetaConversionsAPI]], [[ServerSideTagging]], [[ConversionTracking]], [[AttributionModeling]], [[ConsentModeV2]], [[DataLayerArchitecture]] +- Entities linked: [[JohnWilliams]], [[TheAgency]] +- Source page: wiki/sources/paid-media-tracking-specialist.md +- Notes: 该 Agent 为其他所有 Paid Media Agent 提供数据基础设施；与 paid-media-creative-strategist/paid-social-strategist/ppc-strategist/programmatic-buyer/search-query-analyst/auditor 均存在 depends_on 关系（协同关系已记录于 Connections）；index.md 已插入于 paid-media-programmatic-buyer 之后；Concepts 均为工具/框架类概念，当前仅出现 1 次，不足独立建页阈值，以 wikilink 形式记录于 Source page + +## [2026-04-25] ingest | XR Cockpit Interaction Specialist Agent +- Source file: Agent/agency-agents/spatial-computing/xr-cockpit-interaction-specialist.md +- Status: ✅ 成功摄入 +- Summary: XR Cockpit Interaction Specialist Agent——XR 座舱交互专家 Agent，专注于设计和实现沉浸式座舱式交互环境。核心理念：固定视角（fixed-perspective）+ 高存在感交互区（high-presence interaction zones），将真实感与用户舒适度结合。核心设计原则：约束驱动控制机制（constraint-driven control mechanics）通过 3D meshes 和输入约束将控制物理化，消除自由漂浮运动；座舱人体工学对齐自然眼-手-头协调流动；多模态交互集成（手势/语音/注视/物理道具）；固定视角设计降低运动病阈值。典型应用：模拟指挥中心、航天器座舱、XR 载具界面、训练模拟器。核心工具：A-Frame / Three.js 原型开发。 +- Concepts created: [[Constraint-Driven-Control-Mechanics]], [[Cockpit-Ergonomics]], [[Motion-Sickness-Threshold]], [[Spatial-Computing]] +- Entities linked: [[XR-Interface-Architect]], [[XR-Immersive-Developer]], [[Terminal-Integration-Specialist]] +- Source page: wiki/sources/xr-cockpit-interaction-specialist.md +- Notes: 4 个新 Concept 页面已创建；overview.md 新增 xr-cockpit-interaction-specialist 独立段落；index.md 修复 "source missing" 条目；Entity 层面，XR-Interface-Architect / XR-Immersive-Developer / Terminal-Integration-Specialist 在源文档中提及但尚未建立独立 Entity 页面，当前以 wikilink 形式记录于 Sources 页面；与 [[XR-Immersive-Developer]] 在运动自由度上存在设计张力（固定约束 vs 开放沉浸），已记录于 Contradictions 部分 + +## [2026-04-25] ingest | macOS Spatial/Metal Engineer Agent Personality +- Source file: Agent/agency-agents/spatial-computing/macos-spatial-metal-engineer.md +- Status: ✅ 成功摄入 +- Summary: macOS Spatial/Metal Engineer Agent——Apple 平台专用 Metal 渲染与空间计算专家 Agent，专注于 Swift + Metal 高性能 3D 渲染和 visionOS 空间计算体验。核心能力：实例化 Metal 渲染（10k-100k 节点 @ 90fps 立体渲染）；RemoteImmersiveSpace + LayerRenderer 实现 macOS → Vision Pro 帧流；Metal Compute Shader GPU 力导向图布局；注视（Gaze）+ 捏合（Pinch）空间交互。性能约束：GPU 利用率 < 80%、每帧 < 100 draw calls、内存 < 1GB。 +- Concepts linked: [[Instanced Rendering]], [[RemoteImmersiveSpace]], [[Compositor Services]], [[LayerRenderer]], [[Force-Directed Graph Layout]], [[Metal System Trace]], [[Stereoscopic Rendering]], [[GPU-Driven Rendering]], [[Triple Buffering]], [[Frustum Culling & LOD]] +- Entities linked: [[Apple]], [[Vision Pro]], [[Metal]], [[Xcode Instruments]], [[RealityKit]], [[ARKit]] +- Source page: wiki/sources/macos-spatial-metal-engineer.md +- Notes: Entity 层面 Apple/Vision Pro/Metal/Xcode Instruments/RealityKit/ARKit 在源文档中提及但均不足独立建页阈值，通过 Sources 页面的 Key Entities 部分建立链接；与 [[visionos-spatial-engineer]] 存在职责重叠（Vision Pro 开发），已记录于 Contradictions 部分——前者侧重 macOS 渲染侧 + Vision Pro 流式输出，后者倾向 visionOS 原生交互开发，两者可协同；与 [[xr-immersive-developer]] 互补——浏览器端 WebXR vs Apple 原生 Metal 渲染管线，共同构成 XR 产品矩阵 + +## [2026-04-25] ingest | Recruitment Specialist Agent +- Source file: Agent/agency-agents/specialized/recruitment-specialist.md +- Status: ✅ 成功摄入 +- Summary: RecruitmentSpecialist 是一个专注于中国人力资源市场的招聘运营与人才获取专家 Agent，覆盖从人才吸引、入职到留任的全周期招聘引擎。涵盖中国招聘平台运营（BOSS直聘、拉勾、猎聘、智联、前程无忧、脉脉、LinkedIn）、JD 优化、简历筛选、面试流程设计（STAR、结构化面试）、校园招聘、猎头管理、劳动法合规（劳动合同法、PIPL、五险一金、N+1）、雇主品牌建设、入职 SOP、招聘数据分析全链路。 +- Concepts created: [[STAR Framework]], [[Structured Interview]], [[China Labor Law Compliance]], [[Recruitment Funnel Analyzer]] +- Entities created: [[Boss Zhipin]] +- Source page: wiki/sources/recruitment-specialist.md +- Notes: 无已知冲突。Key Entities 中 Lagou/Liepin/Beisen/Moka/Feishu/STAR 等在源文档出现但出现次数不足以触发独立建页，通过 Sources 页面的 Key Entities 部分建立 wikilinks。 + +## [2026-04-25] ingest | Government Digital Presales Consultant +- Source file: Agent/agency-agents/specialized/government-digital-presales-consultant.md +- Status: ✅ 成功摄入 +- Summary: Government Digital Presales Consultant 是面向中国ToG（政府）市场的全生命周期售前专家Agent，涵盖政策解读、等保2.0三级/商用密码评估/信创适配、数字政府/智慧城市/城市大脑方案设计、招投标全流程（POC→标书→述标→交接）。核心原则：业务场景驱动方案、技术价值需翻译为政府语言、等保/密评/信创是强制项非加分项。 +- Concepts created: [[Dengbao-2.0]], [[Miping]], [[Xinchuang]] +- Source page: wiki/sources/government-digital-presales-consultant.md +- Notes: 无已知冲突。Key Entities（Digital China Master Plan、Kunpeng、Phytium、UnionTech UOS、DM Database等）在源文档中属于背景知识，未创建独立Entity页面，通过Source页面Key Entities部分建立wikilinks。Entities页面已添加Dengbao 2.0、Miping、Xinchuang三条概念索引。 + +## [2026-04-25] ingest | Healthcare Marketing Compliance Specialist +- Source file: Agent/agency-agents/specialized/healthcare-marketing-compliance.md +- Status: ✅ 成功摄入 +- Summary: Healthcare Marketing Compliance Specialist——The Agency Specialized 部门的医疗营销合规专家，覆盖中国医疗健康全品类（药品/医疗器械/医美/保健食品/互联网医疗）营销合规。核心方法：广告法/医疗广告管理办法/互联网广告管理办法核心法规体系 + 企业内部三级审查机制（法务初审→合规复审→终审发布）+ 合规风险分级矩阵（Critical/High/Medium/Low）+ 违规应急响应（2小时下架→24小时报告→72小时审计）。关键原则：合规不是"堵营销"，而是"保护品牌"。 +- Concepts created: [[Healthcare-Marketing-Compliance]]（总框架）、[[Medical-Advertisement-Review]]（医疗广告审查制度）、[[Three-Tier-Review-Mechanism]]（三级审查机制）、[[Blue-Hat-Logo]]（蓝帽子标识）、[[Appearance-Anxiety]]（容貌焦虑红线）、[[Patient-Privacy-PIPL]]（患者隐私合规）、[[Compliance-Risk-Matrix]]（合规风险分级矩阵） +- Entities created: [[NMPA]]（国家药品监督管理局）、[[SAMR]]（国家市场监督管理总局）、[[DXY]]（丁香园）、[[Douyin]]（抖音）、[[Xiaohongshu]]（小红书） +- Source page: wiki/sources/healthcare-marketing-compliance.md +- Notes: index.md 中原有"source missing"条目，本次摄入后已更新为完整条目并修正标题。overview.md Specialized 部门新增 Healthcare Marketing Compliance Specialist 条目。Conflict Areas 新增第11条（与通用法律合规 Agent 的职责边界冲突）。Entities 页面中 Haodf/WeDoctor/JD-Health/WeChat 在源文档中出现频次<2，暂未创建独立页面，通过 Source 页面 Key Entities 部分建立 wikilinks。 + +## [2026-04-25] ingest | Sales Data Extraction Agent +- Source file: Agent/agency-agents/specialized/sales-data-extraction-agent.md +- Status: ✅ 成功摄入 +- Summary: Sales Data Extraction Agent——销售数据提取 AI Agent，专门监控 Excel 文件并提取关键销售指标（MTD/YTD/Year End）。核心能力：文件系统监控、灵活列名映射、PostgreSQL 事务持久化、完整审计跟踪。成功指标：100% 自动化处理、<2% 行级失败率、<5 秒单文件处理时间。 +- Concepts created: 无（FilesystemWatcher/FuzzyColumnMapping/MetricExtraction/TransactionalDatabase/AuditTrail 等概念均通过 Source Page 内 wikilinks 形式表达，未单独建 Concept 页面） +- Entities created: 无（PostgreSQL/SalesRepresentative/ExcelWorkbook 在源文档中出现频次<2，暂未创建独立 Entity 页面，通过 Source 页面 Key Entities 建立 wikilinks） +- Source page: wiki/sources/sales-data-extraction-agent.md +- Notes: index.md 中原有 "source missing" 占位条目（2026-04-20）已替换为完整条目；overview.md Specialized 部门新增 Sales Data Extraction Agent 条目；与 DataConsolidationAgent 的关系已记录于 Contradictions 部分（数据提取 vs 数据整合，互补关系）。 + +## [2026-04-25] ingest | Study Abroad Advisor +- Source file: Agent/agency-agents/specialized/study-abroad-advisor.md +- Status: ✅ 成功摄入 +- Summary: Study Abroad Advisor——The Agency Specialized 部门的全链路留学申请规划专家，面向中国学生，覆盖美/英/加/澳/欧/港/新七大目的地，本科/硕士/博士全学位层次。核心理念：数据驱动、零焦虑贩卖；四步工作流（全面诊断→策略制定→材料打磨→提交跟进）；诚信原则（不代写文书、不承诺录取结果、区分确认信息与经验估算）。标准化交付模板：选校报告、多国申请时间线、文书诊断框架、Offer 比较矩阵。 +- Concepts created: [[Holistic-Admissions]]（全面评估录取模式）、[[UCAS-System]]（英国本科统一申请系统）、[[IANG-Visa]]（非本地毕业生留港就业安排）、[[Grandes-Ecoles]]（法国精英大学体系） +- Entities created: [[The-Agency]]（The Agency 多智能体系统组织，147 个 Agent 跨 12 部门） +- Source page: wiki/sources/study-abroad-advisor.md +- Notes: index.md 中原有 "source missing" 占位条目（2026-04-20）已替换为完整条目；overview.md Specialized 部门新增 Study Abroad Advisor 条目置于 lsp-index-engineer 之后；与 corporate-training-designer 同属服务型 Agent 已在 overview.md 建立关联。4 个 Concept 页面（Holistic-Admissions/UCAS-System/IANG-Visa/Grandes-Ecoles）和 1 个 Entity 页面（The-Agency）创建前均已做去重检查，确认均不存在。 + +## [2026-04-26] ingest | Backend Architect with Memory +- Source file: Agent/agency-agents/integrations/mcp-memory/backend-architect-with-memory.md +- Status: ✅ 成功摄入 +- Summary: 具备持久记忆能力的后端架构师 AI Agent 设计规范——专注于可扩展系统设计（微服务/Serverless）、数据库架构（PostgreSQL/索引/CQRS）、API 开发（REST/GraphQL/gRPC）与云基础设施。核心价值：MCP Memory 集成实现跨会话记忆召回，防止重复讨论已做决策；架构决策以标签化快照持久化；交付物完成后主动标记接收方供下游 Agent 查找；QA 失败时自动回滚到上一个良好检查点。 +- Entities created: BackendArchitect（The Agency 工程部门资深后端架构师 Agent，满足 ≥2 次阈值） +- Concepts created: 无（MicroservicesArchitecture/CQRS/EventSourcing/ServerlessArchitecture/DatabaseIndexing/CircuitBreaker/DefenseInDepth 均仅出现 1 次，均不满足 ≥2 次阈值，均以 wikilink 形式记录于 Source page） +- Source page: wiki/sources/backend-architect-with-memory.md +## [2026-04-25] ingest | GitHub Copilot Integration +- Source file: Agent/agency-agents/integrations/github-copilot/README.md +- Status: ✅ 成功摄入 +- Summary: The Agency 与 GitHub Copilot 的开箱即用集成——无需转换，`.md` + YAML frontmatter 格式原生兼容。一键安装 `./scripts/install.sh --tool copilot`，或手动复制到 `~/.github/agents/` 或 `~/.copilot/agents/`。用户可在 Copilot 会话中通过名称激活特定 agent。 +- Concepts created: AgentFileFormat +- Entities created: GitHubCopilot +- Source page: wiki/sources/github-copilot.md +- Notes: 无内容冲突。index.md（Sources + Concepts + Entities）、overview.md（替换 Cursor Integration 段落为 GitHub Copilot Integration）、log.md 均已更新。Concept AgentFileFormat.md 已创建于 wiki/concepts/，Entity GitHubCopilot.md 已创建于 wiki/entities/。 + +## [2026-04-25] ingest | Finance Tracker Agent Personality +- Source file: Agent/agency-agents/support/support-finance-tracker.md +- Status: ✅ 成功摄入 +- Summary: Finance Tracker——The Agency Support 部门的企业财务规划与分析专家 Agent，核心理念"Keeps the books clean, the cash flowing, and the forecasts honest"，通过 SQL 预算差异分析、Python 现金流预测（含季节性因子）、NPV/IRR 投资评估框架驱动财务决策，覆盖数据验证→预算编制→绩效监控→战略规划→合规审计全链路。关键指标：预算准确率 95%+、现金流预测准确率 90%+、平均投资回报 25%+、合规率 100%。 +- Concepts created: 无（Key Concepts 均为单来源特定财务概念如 BudgetVarianceAnalysis/CashFlowForecasting/NPV_IRR_Analysis/PaybackPeriod/RiskAssessment/FinancialCompliance，不满足可独立复用阈值，均以 wikilink 形式记录于 Source Page Key Concepts 节） +- Entities created: 无（AgentsOrchestrator 已存在于 index；其余 Key Entities 均为单来源特定名称，不满足 ≥2 次出现阈值，均以 wikilink 形式记录于 Source Page Key Entities 节） +- Source page: wiki/sources/support-finance-tracker.md +- Notes: index.md 原占位条目（2026-04-21 source missing）已替换为完整摘要；overview.md 新增第 16 条（企业财务 Agent 全链路能力），位于第 15 条（Agent 去电通知 vs 来电接收）之后；冲突检测：未发现与现有 Wiki 页面的内容冲突；Entities/Concepts 无需新建独立页面。 + +## [2026-04-25] ingest | Support Executive Summary Generator Agent Personality +- Source file: Agent/agency-agents/support/support-executive-summary-generator.md +- Status: ✅ 成功摄入 +- Summary: Executive Summary Generator——The Agency Support 部门的咨询级执行摘要生成 Agent，融合麦肯锡 SCQA、BCG 金字塔原理、贝恩行动导向三大顶级咨询框架，将复杂商业输入转化为 325-475 词的高管级执行摘要，确保 C-suite 3 分钟内做出决策。每个发现必须量化，建议按 Critical/High/Medium 排序含负责人+时间线+预期结果。 +- Concepts created: 无（SCQA/Pyramid Principle/Action-Oriented Recommendations 均仅在本来源中出现，不满足 ≥ 2 次创建阈值，均以 wikilink 形式记录于 Source Page Key Concepts 节） +- Entities created: 无（McKinsey/BCG/Bain 均仅在本来源中出现，不满足 ≥ 2 次创建阈值，均以 wikilink 形式记录于 Source Page Key Entities 节） +- Contradictions detected: 无冲突。与 [[report-distribution-agent]] 存在协同关系（执行摘要生成后可由 Report Distribution Agent 分发），已在 Source Page Connections 节记录 +- Source page: wiki/sources/support-executive-summary-generator.md +- Notes: index.md 原占位条目（2026-04-21 expected）已替换为完整摘要；overview.md Support 部门新增 [[support-executive-summary-generator]] 独立段落，位于 [[support-infrastructure-maintainer]] 之后，完善了 Support 部门数据→洞察→决策→分发的完整链路描述；Entities/Concepts 无需新建独立页面 + +## [2026-05-05] ingest | Workflow Example: Book Chapter Development +- Source file: Agent/agency-agents/examples/workflow-book-chapter.md +- Status: ✅ 成功摄入 +- Summary: Book Chapter Development——The Agency 的单 Agent 工作流示例，用于将录音、碎片化笔记或战略要点等原始素材转化为结构化的第一人称章节草稿，包含明确的编辑注释和修订循环。核心 Agent 为 Book Co-Author，输出五部分结构：目标、章节草稿、编辑注释、反馈循环、下一步。质量标准：保持第一人称声音、论点依附来源材料、删除泛化激励语言、以明确修订问题结尾。 +- Concepts created: 无（BookCoAuthor/EditorialRevisionLoop 等 Key Concepts 均为单来源框架性概念，不满足 ≥ 2 次创建阈值，均以 wikilink 形式记录于 Source Page Key Concepts 节） +- Entities created: 无（Book Co-Author Agent 仅为本工作流的核心执行角色，未在其他来源出现 ≥ 2 次，无需新建独立 Entity 页面） +- Contradictions detected: 与泛化 ghostwriting 服务的定位差异已记录于 Source Page Contradictions 节 +- Source page: wiki/sources/workflow-book-chapter.md +- Notes: index.md 原占位条目（2026-04-21 expected）已替换为完整摘要；overview.md 无需修订（该来源属于 The Agency 内部框架文档，不涉及与其他 Agent/工作流的实质冲突）；Entities/Concepts 无需新建独立页面，均以 wikilink 形式记录于 Source Page 相应节 + +## [2026-05-05] ingest | Multi-Agent Workflow: Startup MVP +- Source file: Agent/agency-agents/examples/workflow-startup-mvp.md +- Status: ✅ 成功摄入 +- Summary: 多 Agent 协作从创意到 MVP 的 4 周 7 步工作流示例（[[workflow-startup-mvp]]）。展示了 RetroBoard（远程团队回顾工具）4 周 MVP 开发的完整流水线：7 种专业 Agent（Sprint Prioritizer、UX Researcher、Backend Architect、Frontend Developer、Rapid Prototyper、Growth Hacker、Reality Checker）按顺序与并行方式协作。核心 4 大模式：Sequential Handoff（顺序交接）、Parallel Agent Work（并行工作）、Quality Gate（质量门控）、Context Passing（上下文传递）。 +- Entities created: RetroBoard、OrchestratorAgent、Sprint-Prioritizer、UX-Researcher、Backend-Architect、Frontend-Developer、Rapid-Prototyper、Growth-Hacker、Reality-Checker（共 9 个） +- Concepts created: Sequential-Handoff、Parallel-Agent-Work、Quality-Gate、Context-Passing、Multi-Agent-Orchestration（共 5 个） +- Source page: wiki/sources/workflow-startup-mvp.md +- Notes: 无内容冲突；index.md 原占位条目（2026-04-21 expected）已替换为完整摘要；overview.md 已追加第 17 条综合摘要；所有 Entities 和 Concepts 均系首次出现，新建独立页面 + +## [2026-05-05] ingest | Nexus Spatial: Full Agency Discovery Exercise +- Source file: Agent/agency-agents/examples/nexus-spatial-discovery.md +- Status: ✅ 成功摄入 +- Summary: 8个 The Agency 专业 Agent 并行协作，完成 AI 空间指挥中心产品 Nexus Spatial 的完整规划（10分钟 wall-clock time）。涵盖：市场验证（AI 编排 $13.5B + 空间计算 $170-220B 交叉空白）、技术架构（8服务 Rust 编排引擎）、品牌策略（定义 [[SpatialAIOps]] 新品类）、GTM 计划（3阶段渐进：2D→WebXR→VisionOS）、UX 研究（调试为杀手级用例）、空间界面架构（命令剧院 + 7态节点系统）、项目执行（35周，5团队）。跨 Agent 独立共识：2D-first / WebXR 优先 / 调试 killer use case。 +- Concepts created: [[SpatialAIOps]]（空间AI运营新品类）、[[Command-Theater-Interface]]（命令剧院界面范式）、[[Debugging-Visualization]]（调试可视化杀手级用例）、[[Semantic-Zoom]]（4级语义缩放导航）、[[Growth-Loop]]（增长飞轮） +- Entities created: [[Nexus-Spatial]]（AI Agent 沉浸式3D命令中心产品）、[[CrewAI]]（竞争产品；CLI-first，可视化能力有限） +- Source page: wiki/sources/nexus-spatial-discovery.md +- Notes: index.md 原占位条目（2026-04-21 expected）已替换为完整摘要；overview.md 已追加 nexus-spatial-discovery 综合摘要条目；与 [[Multi-Agent-System-Reliability]] 在协调机制设计上的张力已记录于 Source Page Contradictions 节——Nexus Spatial 采用 Yjs CRDT 去中心化协作（面向人类协作者），Multi-Agent-System-Reliability 侧重自主 Agent 间显式协调（面向任务协调），场景不同但技术选择有潜在关联待研究。 + + +- Source file: Agent/agency-agents/examples/workflow-landing-page.md +- Status: ✅ 成功摄入 +- Summary: 展示多 Agent 协作在一天内完成高转化率 landing page 的完整工作流，核心价值为 4 个可复用的设计模式：Parallel-Kickoff（并行启动）、Merge-Point（合并点）、Feedback-Loop（反馈循环）、Time-Boxing（时间盒）。4 个 Agent 角色：Content Creator（文案）、UI Designer（设计）、Frontend Developer（构建）、Growth Hacker（转化优化）。 +- Concepts created: Parallel-Kickoff, Merge-Point, Feedback-Loop, Time-Boxing +- Entities created: Content-Creator, UI-Designer +- Source page: wiki/sources/workflow-landing-page.md +- Notes: index.md 原占位条目（2026-04-21 source missing）已替换为完整摘要；overview.md 新增 workflow-landing-page 段落，位于 The Agency 贡献指南之后、GitHub Copilot Integration 之前；冲突检测：与 workflow-startup-mvp 在时间粒度上互补（天 vs 周），无实质性冲突。 + +## [2026-04-26] ingest | Multi-Agent Workflow: Startup MVP with Persistent Memory +- Source file: Agent/agency-agents/examples/workflow-with-memory.md +- Status: ✅ 成功摄入 +- Summary: workflow-startup-mvp 的增强版——通过 MCP Memory Server 将手动复制粘贴交接升级为自动召回。核心机制：remember 存储 Agent 交付物（带项目名 + 接收方标签）、recall 自动召回上下文（无需人工粘贴）、rollback 回滚到上一个检查点（替代手动撤销）。Before/After 对比：会话超时丢失 / 多 Agent 需重复编译上下文 / QA 失败需手动描述问题 / 跨多天项目需重建上下文 → 跨会话持久 / 按标签共享 / 自动回滚 / 每次 pick up 继续。 +- Concepts created: Memory-Based-Handoff（基于记忆的交接模式，可抽象复用，已建独立 Concept 页面） +- Entities created: 无（所有参与 Agent 和 RetroBoard 均已在 wiki 中存在，均以 wikilink 形式记录于 Source Page Key Entities 节） +- Source page: wiki/sources/workflow-with-memory.md +- Notes: index.md 原占位条目（2026-04-21 source missing）已替换为完整摘要；overview.md 新增 workflow-with-memory 段落，位于 Backend Architect with Memory 之后、multi-channel-assistant 之前；冲突检测：与 workflow-startup-mvp 在"是否需要人工复制粘贴"上存在表面冲突（实质为增强关系），已记录于 Source Page Contradictions 节——Memory 模式是原始工作流的增强层，Memory Server 可用时自动召回，不可使用时沿用手工粘贴策略。 + +## [2026-05-05] ingest | Marketing Douyin Strategist +- Source file: Agent/agency-agents/marketing/marketing-douyin-strategist.md +- Status: ✅ 成功摄入 +- Summary: The Agency Marketing 部门的抖音短视频营销与直播带货策略专家 Agent 个性文档。核心能力：推荐算法（完播率 > 点赞率 > 评论率 > 分享率）、爆款视频策划（黄金3秒钩子）、流量运营（DOU+/矩阵账号）、直播带货（引流款/利润款/形象款/秒杀款结构）。交付物模板：短视频脚本结构（1-3秒黄金钩子 + 4-20秒核心内容 + 21-30秒收尾钩子）、直播产品结构表、2小时直播节奏规划。 +- Concepts created: [[Content-Matrix-Strategy]]（内容矩阵策略）、[[Golden-3-Second-Hook]]（黄金3秒钩子） +- Entities created: [[OceanEngine]]（巨量引擎/千川广告平台）；[[Douyin]]（抖音平台）已更新，新增 Marketing & Short-Video Strategy 节 +- Source page: wiki/sources/marketing-douyin-strategist.md +- Notes: index.md 原占位条目（2026-04-21 expected）已替换；overview.md 新增 Douyin Short-Video & Livestream Commerce 段落（TikTok E-commerce Product Management 之后）；Douyin.md 实体已更新（增加 Marketing & Short-Video Strategy 节）；冲突检测：与 [[MarketingTiktokStrategist]] 在算法权重优先级上存在差异——抖音以完播率为首要指标，TikTok 需平衡分享率与互动率，已记录于 Source Page Contradictions 节。 + +## [2026-05-06] ingest | Marketing Zhihu Strategist +- Source file: Agent/agency-agents/marketing/marketing-zhihu-strategist.md +- Status: ✅ 成功摄入 +- Summary: Marketing Zhihu Strategist——The Agency Marketing 部门的知乎营销专家 Agent，将品牌打造为知乎思想领袖，通过六阶段工作流（话题定位→问题识别→高质量内容创作→专栏开发→关系建设→性能分析）建立信誉驱动权威。核心理念：信誉优先——权威和真实专业度比粉丝数重要得多；仅回答真正有可辩护专业知识的问答；每条主张必须有数据/研究/案例支撑。关键交付物：专题权威映射、问题选择策略、高质量答案模板（300+ 词）、6 个月专栏内容日历、影响力者关系列表、线索生成漏斗。成功指标：答案平均 100+ 点赞、每月 50-200 条精准线索、专栏每月 500-2000 新订阅者。与 [[Marketing Douyin Strategist]] 同属中国平台矩阵——知乎侧重信誉驱动深度内容，抖音侧重娱乐驱动视觉内容，两者互补。 +- Concepts created: [[Thought-Leadership]]（思想领导力）、[[Community-Credibility]]（社区信誉）、[[Strategic-Question-Answer]]（战略问答策略）、[[Content-Pillar]]（内容支柱）、[[Lead-Generation-Funnel]]（线索生成漏斗） +- Entities created: [[Zhihu]]（知乎，中国最大知识分享平台） +- Source page: wiki/sources/marketing-zhihu-strategist.md +- Notes: index.md 原占位条目（2026-04-21 expected）已替换为完整摘要；overview.md Douyin 段落后新增 marketing-zhihu-strategist 完整条目（含与 Douyin 的互补关系）；5 个 Concept 页面和 1 个 Entity 页面已创建并添加到 index.md；冲突检测：与 [[marketing-douyin-strategist]] 在"内容深度 vs 视觉爆款"策略差异已在双方 Source Page Contradictions 节记录，已在 overview.md Conflict Areas #14 标注为互补关系。 + +## [2026-04-26] ingest | Marketing Cross-Border E-Commerce Specialist +- Source file: Agent/agency-agents/marketing/marketing-cross-border-ecommerce.md +- Status: ✅ 成功摄入 +- Summary: 跨境电商多平台运营与品牌全球化策略 Agent，覆盖 Amazon、Shopee、Lazada、AliExpress、Temu、TikTok Shop 等主流平台。五步工作流：市场调研→合规准备→Listing 发布→广告引流→数据迭代。核心原则：合规优先（CE/FCC/FDA/VAT）、本地化制胜（母语级 Listing）、供应链成本控制（ACOS 硬性底线 < 毛利率）。 +- Concepts created: 无新 Concept 页面（ACOS/TACOS/IPI/VAT/Localization 等核心概念为具体运营指标，非抽象框架；已记录于 Source Page 的 Key Concepts 节） +- Source page: wiki/sources/marketing-cross-border-ecommerce.md +- Notes: index.md 原占位条目（2026-04-21 expected）已替换为完整摘要；overview.md 已包含跨境电商相关内容，无需额外更新；Entity/Concept 页面检查：Amazon/Shopee/Temu 等平台实体在该 Agent 文档中为背景引用，非核心分析对象，跳过创建；冲突检测：TikTok Shop 相关连接与现有 Wiki 一致，与 Supply Chain Strategist Agent 无冲突；与 [[Marketing Douyin Strategist]] 的内容平台流量逻辑差异已在 Source Page Contradictions 节记录。 + +## [2026-04-26] ingest | Marketing Carousel Growth Engine +- Source file: Agent/agency-agents/marketing/marketing-carousel-growth-engine.md +- Status: ✅ 成功摄入 +- Summary: 全自动 TikTok/Instagram 轮播图增长引擎 Agent——将任意网站 URL 转化为病毒式 6 张轮播图并每日自主发布。核心理念：把每次发布变成数据，每次数据驱动下次改进，让内容质量随时间指数级提升。核心架构：Playwright 网站分析（提取品牌/内容/竞品）→ Gemini 图像生成（第一张幻灯片定义视觉 DNA，后续图生图保持连贯）→ Upload-Post API 双平台发布（TikTok+Instagram，同步自动添加热门音乐）→ Analytics Feedback Loop（learn-from-analytics.js 提取洞察到 learnings.json，驱动下一条内容）。关键规范：6-Slide Narrative Arc（Hook → Problem → Agitation → Solution → Feature → CTA）；零确认自主运行；仅生成 JPG；底部 20% 不放文字。 +- Concepts created: [[6-Slide Narrative Arc]]（标准化 6 张幻灯片轮播叙事结构）、[[Visual Coherence Engine]]（AI 图生图视觉一致性引擎）、[[Analytics Feedback Loop]]（数据分析驱动的内容自我优化闭环） +- Entities created: [[Gemini]]（Google AI 图像生成模型）、[[Upload-Post]]（多平台内容发布与数据分析 API）、[[Playwright]]（浏览器自动化框架） +- Source page: wiki/sources/marketing-carousel-growth-engine.md +- Notes: index.md 新增完整摘要（替换原 2026-04-21 expected 占位条目）；overview.md Marketing Douyin 段落后新增 marketing-carousel-growth-engine 完整条目；3 个 Concept 页面和 3 个 Entity 页面已创建并添加到 index.md；冲突检测：与 [[Marketing Kuaishou Strategist]] 在平台差异已在 Source Page Contradictions 节记录（面向不同市场，无直接矛盾）；与 [[Behavioral Nudge Engine]] 的行为引导机制关联已在 overview.md 标注。 + +## [2026-04-26] ingest | Marketing Weibo Strategist +- Source file: Agent/agency-agents/marketing/marketing-weibo-strategist.md +- Status: ✅ 成功摄入 +- Summary: 新浪微博全栈运营与品牌传播战略专家 Agent——帮助品牌在微博平台实现热搜霸榜与持续增长。核心能力：企业蓝V账号运营、热搜话题策划（争议性×低门槛×情感共鸣=病毒扩散）、超级话题社区管理、粉丝经济、KOL金字塔合作、微博广告（粉丝头条/信息流/开屏/超级粉丝头条）、舆情监控（蓝/黄/橙/红四色分级+黄金4小时响应）与危机公关。核心理念：微博是公共舆论场，追求话语权份额而非私域积累；热搜生命周期4-8小时，时效性>互动量>账号权威>内容质量。 +- Concepts created: [[Trending-Topic-Operations]]（热搜话题运营——围绕品牌事件/节日/时事设计低门槛高分享性 hashtag，实时监测热搜30分钟内联动）、[[舆情监控]]（舆情监控与危机公关——蓝/黄/橙/红四色分级+黄金4小时响应规则） +- Entities created: [[Weibo]]（新浪微博——中国领先的微博客平台，公共舆论场核心阵地） +- Source page: wiki/sources/marketing-weibo-strategist.md +- Notes: index.md 原占位条目（2026-04-21 expected）已替换为完整摘要；overview.md 新增 marketing-weibo-strategist 完整条目（置于 Douyin Short-Video 段落与 New Linux/DevOps Concepts 之间）；Entity 去重检查：Weibo.md 未在 Wiki 中存在同名页面，新建 Weibo.md；Concept 去重检查：Trending-Topic-Operations、舆情监控均未在 Wiki 中存在同名页面；冲突检测：与 [[Marketing-Private-Domain-Operator]] 的框架张力已在 Source Page Contradictions 节记录——微博追求公域话语权（声量），私域追求私有用户资产（深度），两者互补而非竞争，协调方案：公域引爆话题→私域沉淀转化形成完整漏斗。 + +## [2026-04-26] ingest | Marketing Podcast Strategist +- Source file: Agent/agency-agents/marketing/marketing-podcast-strategist.md +- Status: ✅ 成功摄入 +- Summary: 中国播客市场内容战略与全漏斗运营专家 Agent——覆盖节目定位、音频制作、多平台分发与商业化变现完整方法论。核心理念：播客是"慢媒介"，核心竞争力是主播人格深度和听众陪伴感，完成率比播放量更能反映内容质量。平台策略：小宇宙（中国播客用户最集中）为主阵地，喜马拉雅（用户规模最大）适合付费知识变现；RSS 为分发核心基础设施。内容规划四象限（常青/热点/系列/实验）；制作标准（-16 LUFS 响度归一化、WAV 录制）；增长飞轮（社区运营→跨平台引流→嘉宾互推）；变现路径（品牌赞助→口播广告→付费订阅→私域导流）。关键原则：音频质量是底线、固定节奏比频繁更新更重要。 +- Concepts created: [[Podcast-Positioning]]（播客定位四象限——垂直知识/对话访谈/叙事故事/闲聊日常）、[[Completion-Rate]]（完成率——比播放量更重要的内容质量指标，>50% 为优秀标准） +- Entities created: [[Xiaoyuzhou]]（小宇宙——中国播客用户最集中平台）、[[Ximalaya]]（喜马拉雅——中国用户规模最大音频平台）、[[Chinese-Podcast-Platforms]]（中国播客音频平台矩阵，含荔枝FM/蜻蜓FM/网易云音乐/Apple Podcasts/Spotify） +- Source page: wiki/sources/marketing-podcast-strategist.md +- Notes: index.md 新增条目（Sources 第485行，2026-04-26）；index.md Entities 新增 Xiaoyuzhou/Ximalaya/Chinese-Podcast-Platforms；index.md Concepts 新增 Podcast-Positioning/Completion-Rate；overview.md 新增第19条 Contradiction（播客"慢媒介" vs 短视频"快媒介"），补充播客策略与短视频策略的互补协调关系；Entity 去重检查：Xiaoyuzhou/Ximalaya/ChinesePodcastPlatforms 均未在 Wiki 中存在同名 Entity 页面，新建；Concept 去重检查：PodcastPositioning/CompletionRate 均未在 Wiki 中存在同名 Concept 页面，新建；冲突检测：与 [[Marketing-Short-Video-Editing-Coach]] 存在"快慢媒介"节奏策略冲突——已在 Source Page Contradictions 节和 overview.md 第19条记录，协调方案：两者并行运营但节奏管理分开。 + +## [2026-04-26] ingest | Technical Artist +- Source file: Agent/agency-agents/game-development/technical-artist.md +- Status: ✅ 成功摄入 +- Summary: Technical Artist Agent——技术美术 Agent 个性规范，连接艺术视野与引擎实现的桥梁角色。核心职责：在硬性能预算内最大化视觉质量，涵盖着色器编写（移动端安全变体/HLSL/ShaderLab）、VFX 系统构建（粒子数上限/Overdraw 审计）、资产管线标准定义（多边形预算/纹理压缩/导入预设自动化）和渲染性能分析（GPU Profiling）。核心原则：预算优先（生产前定义资产上限）、移动端优先（Overdraw/LOD 强制执行）、着色器标准（移动端安全变体或平台限制标注）。高级能力：实时光线追踪（RT reflections + DLSS/XeSS/FSR）、AI 辅助美术管线（纹理超分/AI 法线图）、模块化后处理栈（LUT 调色/TAA+锐化）。属 The Agency Game Dev 部门。 +- Concepts created: [[Shader]]（GPU 可编程着色器，HLSL/GLSL/ShaderLab，含 Vertex/Fragment/Compute 类型及移动端安全规范）、[[VFX]]（实时视觉特效，粒子数上限 Mobile 500/PC 2000，Overdraw 上限 Mobile 3层/PC 6层）、[[LOD-Pipeline]]（多细节层次管线，强制 LOD0–LOD3，含 Validation Script 和详细预算表）、[[Asset-Pipeline]]（资产管线标准，含纹理压缩规范 BC7/ASTC/Mipmap 规则）、[[Performance-Budget]]（性能预算，含帧时间/GPU/VFX Particle/Draw Call 各类预算及沟通语言范式）、[[Post-Processing]]（模块化后处理栈，含 Bloom/色差/晕影/LUT/TAA+锐化及平台差异化配置） +- Entities created: 无（UnrealTechnicalArtist/UnityShaderGraphArtist/UnrealWorldBuilder/UnityArchitect 各在源文档中仅出现 1 次，未达 Entity 建页阈值 ≥2 次） +- Source page: wiki/sources/technical-artist.md +- Notes: index.md Sources 新增条目（2026-04-26，第7行）；index.md Concepts 新增 6 个条目（Asset-Pipeline/LOD-Pipeline/Performance-Budget/Post-Processing/Shader/VFX）；overview.md Game Development section 新增 Technical Artist 完整 entry；Entity 去重：UnrealTechnicalArtist/UnityShaderGraphArtist/UnrealWorldBuilder/UnityArchitect 各仅出现 1 次，未达 Entity 建页阈值，不建页；冲突检测：无已知冲突（Source Page Contradictions 节为空）；wikilinks 命名一致性：创建过程中统一使用 hyphenated-name 格式（LOD-Pipeline/Performance-Budget/Post-Processing/Asset-Pipeline），与 wiki 中现有 naming convention 一致。 + +## [2026-04-26] ingest | Godot Multiplayer Engineer Agent Personality +- Source file: Agent/agency-agents/game-development/godot/godot-multiplayer-engineer.md +- Status: ✅ 成功摄入（source page 已存在，仅修复 index.md broken entry） +- Summary: Godot 4 网络多人游戏专家 Agent，基于 MultiplayerAPI、MultiplayerSpawner、MultiplayerSynchronizer 和 RPC 机制实现实时多人游戏网络同步。涵盖服务器权威模型设计、RPC 安全性、场景复制、延迟模拟测试、NAT 穿透与 WebRTC 集成。 +- Concepts created/updated: [[MultiplayerAPI]]、[[Server-Authoritative Model]]、[[RPC（Remote Procedure Call）]]、[[MultiplayerSynchronizer]]、[[MultiplayerSpawner]]、[[ENet]]、[[WebRTC]]、[[Authority Model]]、[[RPC Security Pattern]] +- Source page: wiki/sources/godot-multiplayer-engineer.md +- Notes: index.md Sources 第3行已存在正确条目；index.md line 507 原有 broken lint marker entry（expected source missing）已移除；Entity 建页判断：Godot 4 和 Nakama 在源文档中仅出现 1-2 次，未达 Entity 建页阈值 ≥2 次，仅在 source page Key Entities 节记录；冲突记录：与 [[unity-multiplayer-engineer]] 在权威模型实现上有差异，已在 source page Contradictions 节记录（Godot 显式 vs Unity 隐式权威模型） diff --git a/wiki/overview.md b/wiki/overview.md index 62b818dc..4caa165f 100644 --- a/wiki/overview.md +++ b/wiki/overview.md @@ -1,802 +1,1017 @@ -# Overview - -This wiki is a living synthesis of curated sources spanning AI agents, cloud infrastructure, DevOps, productivity tools, and home server automation. - -## Major Themes - -### Multi-Agent AI Systems -The wiki covers two major multi-agent frameworks: **The Agency** (agency-agents) and **OpenClaw**. The Agency provides 147 specialized agents across 12 business divisions (Engineering, Design, Finance, Game Dev, Marketing, Paid Media, Product, Project Management, Testing, Support, Spatial Computing, Specialized). OpenClaw focuses on autonomous agents with persistent memory and workflow orchestration via n8n. - -**The Agency 贡献指南**（[[contributing_zh-cn]] + [[contributing]] 英文原版）：The Agency 项目贡献者指南——核心贡献方式：①创建全新智能体（8大分类：engineering/design/marketing/product/project-management/testing/support/spatial-computing/specialized）；②优化现有智能体；③分享成功案例；④反馈问题。智能体设计五原则：**鲜明性格**（拒绝通用人设）、**明确交付物**（真实代码/模板）、**可量化指标**、**经过验证的工作流**、**学习记忆机制**。PR 流程包含提交前检查（真实场景测试、遵循模板、补充示例）、社区评审与迭代优化。属 [[Multi-Agent-System-Reliability]] 的智能体设计规范层，为 [[Multi-Agent-Team]] 提供标准化的智能体创建框架。 - -**GitHub Copilot Integration**（[[github-copilot]]）：The Agency 与 GitHub Copilot 的开箱即用集成——无需转换，Agency 的 `.md` + YAML frontmatter 格式与 GitHub Copilot 原生兼容。通过 `./scripts/install.sh --tool copilot` 一键安装，或手动复制到 `~/.github/agents/` 或 `~/.copilot/agents/` 目录。用户可在任意 Copilot 会话中通过名称激活特定 agent，如 `"Activate Frontend Developer and help me build a React component."`。与 [[readme|Cursor Integration]] 互补——后者项目级别生效，Copilot Integration 用户级别全局生效，共同构成 [[The Agency]] 的多 IDE 集成生态。 - -**Windsurf Integration**（[[windsurf-integration]]）：The Agency Agent roster 与 Windsurf 编辑器的集成方案——通过 `.windsurfrules` 文件将全部 Agent roster 聚合为单一规则文件，install.sh 脚本从项目根目录安装，项目级生效。Windsurf 中在 prompt 里按名称引用 Agent 即可激活（如 "Use the Frontend Developer agent to build this component."）。与 [[Cursor Integration]]（.mdc 规则）和 [[Aider Integration]]（CONVENTIONS.md）同为项目级 IDE 集成，机制相似，共同构成 The Agency 的多 IDE 覆盖体系。[[integrations-readme]] 已覆盖所有 11 种集成工具的概览。 - -**Antigravity Integration**（[[antigravity-integration]]）：The Agency Agent roster 与 Antigravity/Gemini 的集成方案——通过 `./scripts/install.sh --tool antigravity` 将全部 Agent roster 转换为 Antigravity SKILL.md 文件，复制到 `~/.gemini/antigravity/skills/` 目录。所有 skill slug 统一使用 `agency-` 前缀（如 `agency-frontend-developer`）以避免与 Antigravity 原生 skills 冲突。用户可通过 `"Use the agency-frontend-developer skill to review this component."` 激活对应 agent。与 [[Cursor Integration]]（.mdc 规则）和 [[Windsurf Integration]]（.windsurfrules）同属多 IDE/平台集成，共同构成 The Agency 的完整集成生态，覆盖 Cursor（VS Code 兼容）、Windsurf、Copilot（用户级）和 Antigravity（Gemini）四大平台。 - -**Kimi Code CLI Integration**（[[kimi]]）：The Agency 与 Kimi Code CLI 的集成方案——通过 `./scripts/convert.sh --tool kimi` 将所有 agent 转换为 `agent.yaml`（规范定义）+ `system.md`（系统提示词）的目录结构，再通过 `./scripts/install.sh --tool kimi` 安装到 `~/.config/kimi/agents/`。使用 `--agent-file` 标志激活特定 agent，支持 `extend: default` 继承 Kimi 内置 default agent 的工具集。与 [[readme|Cursor Integration]] 和 [[github-copilot]] 同属 The Agency 的多 IDE/CLI 集成生态，Kimi Code CLI 由 Moonshot AI 出品，与 Claude Code 形成竞争。 - -**OpenCode Integration**（[[readme|OpenCode Integration]]）：The Agency Agent roster 与 OpenCode 编辑器的子 Agent 集成方案——通过 `./scripts/install.sh --tool opencode` 安装，将 The Agency 的 .md 文件格式 Agent 转换为 OpenCode 的 `.opencode/agents/` 目录格式。核心机制：在 YAML frontmatter 中添加 `mode: subagent` 使 Agent 仅在 `@agent-name` 触发时出现，不会在 Tab 循环列表中占位；颜色通过命名颜色到十六进制的自动映射实现。支持两种安装范围：项目级（`.opencode/agents/`）和全局级（`~/.config/opencode/agents/`）。与 [[readme|Cursor Integration]]（.mdc 规则）、[[github-copilot]]（用户级 Copilot）、[[windsurf-integration]]（.windsurfrules）同属 The Agency 的多 IDE 集成生态，[[integrations-readme]] 已覆盖所有集成工具概览。 - -**MCP Memory Integration**（[[mcp-memory-integration]]）：The Agency 的 MCP Memory 集成方案——通过在 Agent 提示词中加入标准化的 Memory Integration 段落，为任意 Agent 赋予跨会话持久记忆能力，无需修改 Agent 代码。MCP Memory Server 提供四个核心工具：`remember`（存储决策/交付物快照）、`recall`（跨会话检索）、`rollback`（失败时回滚到上一个检查点）、`search`（跨 Agent 搜索记忆）。**Rollback 是杀手级功能**——当 QA 检查失败或架构决策出错时，直接恢复到已知良好状态而非从头重建。标签一致性是关键：每个记忆使用 Agent 名称和项目名称作为标签，确保 recall 可靠。与 [[specialized-mcp-builder]]（构建 MCP Server）和 [[ai-memory-tools-two-camps]]（AI 记忆工具全景分类）同属 The Agency MCP 生态的核心组成部分。 - -**Backend Architect with Memory**（[[backend-architect-with-memory]]）：The Agency 中具备持久记忆能力的后端架构师 Agent——专门负责可扩展系统设计、数据库架构、API 开发与云基础设施。核心记忆机制：会话启动时检索 `backend-architect` + 项目名标签的历史记忆，防止重复讨论已做决策；架构决策（选型数据库/定义 API 契约/选择通信模式）以标签化快照持久化；交付物（Schema/API 规范/架构文档）完成后主动标记接收方（如 `frontend-developer` + `api-spec`）供下游 Agent 查找；QA 失败时检索最近良好检查点回滚。作为 [[agents-orchestrator]] 调度的具体执行 Agent，通过 MCP Memory 实现多 Agent 协作中的上下文连续性。 - -**[[multi-channel-assistant]]**：基于 [[OpenClaw]] 的多渠道个人助理方案——以 Telegram Topic 路由为统一入口，整合 Google Workspace（gog）、Slack、Todoist、Asana，实现"说一句话完成全套工作"。核心价值：消除应用切换疲劳，AI 主动推送定时提醒（如每周垃圾清理、公司周报）。 - -**[[phone-based-personal-assistant]]**：通过 ClawdTalk + Telnyx 将任意手机变成 AI 助理语音入口——拨打电话即可与 [[OpenClaw]] 对话，支持日历查询、Jira 任务更新、网络搜索等技能，无需智能手机 App 或浏览器，覆盖驾驶、步行等双手占用场景。与 [[multi-channel-assistant]] 互补：文字入口覆盖图文交互，语音入口覆盖无屏场景。 - -**[[phone-call-notifications]]**：AI Agent 通过 [[clawr.ing]] 托管电话服务主动向用户拨打电话通知——Agent 评估事件优先级（股价暴跌/紧急邮件/日程提醒），自动拨叫用户真实号码，用户接听后可实时提问，Agent 双向对话响应。与 [[phone-based-personal-assistant]] 互补：后者为用户→Agent 的来电接收（用户主动呼叫），前者为 Agent→用户的去电通知（Agent 主动呼叫），共同构成完整语音双向通信能力。覆盖 100+ 国家 PSTN 电话，不存储录音，加密传输后即时销毁。 - -**[[multi-channel-customer-service]]**：基于 [[OpenClaw]] 的企业级多渠道 AI 客服统一收件箱——整合 WhatsApp Business、Instagram DMs、Gmail 和 Google Reviews 至单一 AI 驱动的收件箱，AI 自动识别消息意图（FAQ/Appointment/Complaint/Review）并匹配对应处理策略，语言自动检测匹配客户语言（ES/EN/UA），支持 Test Mode 演示而不影响真实客户。餐厅实测响应时间从 4+ 小时降至 2 分钟以内，80% 咨询自动处理。与 [[multi-channel-assistant]] 互补——后者面向个人助理多渠道入口，前者面向企业客服场景。 - -**Inbox De-clutter**：基于 [[OpenClaw]] 的 Newsletter 自动整理方案——每天 20:00 通过 Cron Job 阅读过去 24 小时的新邮件，生成精华摘要并附原文链接，根据用户反馈持续学习偏好。需前置 Gmail OAuth Setup。与 [[custom-morning-brief]] 属同一 Cron Job + AI 摘要模式的 Newsletter 垂直场景。与 [[email-triage]] 属同一方法论的不同实现。 - -**[[Second Brain]]**：基于 [[OpenClaw]] 的个人第二大脑记忆捕获系统——通过短信/Telegram/Discord 零摩擦捕获任何内容（\"Remind me to read a book...\"），OpenClaw 永久记忆存储所有对话，Next.js 可搜索仪表盘提供全局检索，Cmd+K 跨所有记忆/文档/任务全局搜索。核心价值：**捕获像发短信一样简单，检索像搜索一样简单**。无需文件夹、无需标签、无需复杂组织——文本加搜索足矣。OpenClaw 的累积记忆系统使 AI 随时间变得越来越强大，用户从手机发消息就能在电脑端构建内容。灵感来源：Alex Finn 的 YouTube 视频、Tiago Forte 的《Building a Second Brain》。 - -**Self-Improving 自改进系统**（[[养虾日记2]]）：解决 AI Agent"每次对话都是白纸"的核心问题——三层记忆架构（短期文件 + 长期向量数据库 + self-improving 复盘）配合每日 23:00 定时复盘，实现"错误只犯一次"的 Agent 学习闭环。Pattern-Key 重复是系统性问题的信号；Recurrence-Count 是区分一次性错误与重复问题的关键指标。[[Self-Improving-Skill]] 的 Suggested Action 必须具体到可直接执行（如 `--to 5038825565`），而非泛泛建议。 - -**[[养虾日记3]]**：用 Obsidian + Gitea 为 AI 助手构建持久化笔记系统——解决"AI 对话结束输出就消失"的核心问题。核心架构：**Obsidian 做知识库**（iCloud Drive 三端同步）、**Gitea 做版本控制**（完整保留所有历史版本）、**OpenClaw obsidian skill 做写入接口**。三个 Agent（星枢/星辉/星曜）分别向各自 Obsidian 目录写入，knowledgebase/ 存放跨 Agent 共用知识，/ 存放单一 Agent 私有笔记。核心价值：把 AI 变成"会自动整理笔记的实习生"——做完事顺手更新记录。与 [[Second Brain]]（对话记忆）、[[Personal Knowledge Base (RAG)]]（知识检索）同属持久化记忆能力的不同实现。与 [[self-healing-home-server]] 的 Morning Briefing 共享同一笔记更新机制。融合了 Karpathy 的 LLM Wiki 理念：让 AI 增量构建 Wiki，页面间互链，知识越积越厚。与 [[养虾日记1]]（照片整理）、[[养虾日记2]]（Self-Improving）、**[[养龙虾5天血泪史]]**（记忆调试）属同一「养虾日记」系列。 - -**[[养龙虾5天血泪史]]**：AI Agent 记忆失效问题的专项调试全记录——作者（比利哥）花费 5 天时间系统修复 OpenClaw 助理"星辉"的失忆问题。发现 5 类根本原因：①上下文压缩导致细节丢失（姓名/数字/决定）→ 配置 `memoryFlush` 在压缩前写入磁盘；②纯语义搜索在专有名词上失败 → 切换到 QMD 混合搜索（BM25+向量+重排）；③Agent 找到但不自动使用信息 → 启动序列强制触发检索；④多次压缩后上下文仍丢失 → 配置 `contextPruning` 协同工作；⑤系统提示词膨胀 28% → 全面清理未使用技能和无效文件。**10 条黄金法则**：只有 7 个自动加载文件（AGENTS/SOUL/TOOLS/IDENTITY/USER/HEARTBEAT/MEMORY）；启动序列必须放在 AGENTS.md 最顶部；**写入纪律比读取纪律更重要**；交接协议是模型切换修复的关键；定期运行 `/context detail` 检测 token 消耗。核心洞察：**压缩不是敌人，未写入的上下文才是**；系统提示词中每个令牌都是代理携带的开销。最终将系统提示词从 209,652 精简到 9,349 令牌，减少 28%。与 [[养虾日记1]]（照片整理）、[[养虾日记2]]（Self-Improving）属同一「养虾日记」系列，从不同角度解决 OpenClaw 的记忆与持久化问题。 - -**[[养虾日记5]]**：用AI蒸馏历史人物思维框架创建"数字导师"——以苏东坡为首位实践，展示如何将千年前古人的心智模型（六道：进退由时/此心安处/辞达而已/逆境转化/自出新意/天人合一）转化为可运行的AI Skill。女娲·Skill造人术通过6个并行Agent从6个维度（著作/对话/表达DNA/他者视角/决策/时间线）采集信息，提炼心智模型、决策启发式和表达DNA，产出自包含的.skill文件。核心洞察：AI时代用AI放大人类历史上最强大的脑子——学投资蒸馏芒格，学物理思维蒸馏费曼，逆境中保持风骨蒸馏苏东坡。与 [[养虾日记1/2/3/4]] 和 [[养龙虾5天血泪史]] 属同一「养虾日记」系列，从"AI数字导师"新角度扩展了 OpenClaw 的使用场景。与 [[Second Brain]]（对话记忆捕获）、[[思维蒸馏（女娲造人术）]] 同属用AI构建外部认知能力的不同路径。 - -**Recursive Self-Optimizing Generative Systems**（[[a-formalization-of-recursive-self-optimizing-generative-systems]]）：递归自我优化生成系统的形式化理论模型——将 [[养虾日记2]] 中 Self-Improving 的实践经验抽象为严格数学框架：系统目标不是直接产出最优输出，而是通过迭代自我修改构建稳定的生成能力 $G^*$。定义生成器空间 $\mathcal{G}$ → 优化算子 $O$ → 元生成算子 $M$ → 自映射 $\Phi$ → 稳定不动点 $G^*$，最终用 λ-calculus Y 组合子表达自引用结构 $G^* \equiv Y\;\text{STEP}$。核心发现：**递归自我优化自然涌现不动点结构**——当 $\Phi$ 满足收缩性条件时，$G^* = \lim_{n \to \infty} \Phi^n(G_0)$。该框架为 [[Self-Improving-Skill]] 和所有自我改进 AI 架构提供了原则性理论基础。 - -**[[design-ui-designer]]**（UI Designer）：The Agency 设计部门的视觉界面设计专家智能体——专注于视觉设计系统、组件库和像素级界面交付。核心交付物：设计令牌系统（CSS 变量管理颜色/字体/间距/阴影/过渡）、响应式设计框架（Mobile-first，4个断点）、可访问性标准（WCAG AA，色彩对比度 4.5:1）、组件文档与设计 QA 流程。核心原则：**Design System First**——在创建单个界面之前先建立组件基础和视觉规范；**Accessibility Built-In**——从架构层面内置可访问性，而非后期添加；**Developer Handoff**——提供详细测量规格、组件文档和使用指南，实现 90%+ 实现准确率。与 [[design-brand-guardian]] 互补（品牌身份 vs 视觉执行），与 [[[[Project/fonrey/prompt/Role/design-ui-designer]]]] 存在张力——前者追求 95%+ 视觉一致性，后者在规范内注入趣味元素，两者通过预定义可配置槽位协调。与 [[ArchitectUX]]（技术架构）和 [[UX-Researcher]]（用户研究）协同，共同构成 [[The Agency]] 设计部门的完整设计支撑体系。 - -**[[design-brand-guardian]]**（Brand Guardian）：The Agency 设计部门的品牌战略与身份守护专家智能体——负责创建 cohesive 品牌体系、确保跨所有触点的品牌表达一致性、并通过品牌保护策略维护品牌价值。核心交付物：品牌战略框架（Purpose/Vision/Mission/Values/Personality 五要素）、视觉身份系统（CSS 变量定义的品牌色彩/字体/间距/Logo 变体）、品牌声音指南（Voice Characteristics/Tone Variations/Messaging Architecture/Writing Guidelines）、品牌保护策略（商标监控/合规审计/危机管理）。核心原则：**Brand-First**——在战术执行前必须先建立完整的品牌基础；**一致性优先**——确保品牌识别在 95%+ 触点保持一致；**战略性演进**——品牌必须能够随市场变化成长而不失去核心身份。与 [[design-whimsy-injector]] 互补——Brand Guardian 建立品牌边界并制定一致性标准，Whimsy Injector 在边界内通过有目的的趣味和微交互注入品牌个性，共同为 [[LuxuryDeveloper]] 提供完整的品牌体验设计。与 [[ArchitectUX]]（技术架构）和 [[UX-Researcher]]（用户研究）协同，共同构成 [[The Agency]] 设计部门的完整设计支撑体系。 - -**[[design-ux-researcher]]**（UX Researcher）：The Agency 设计部门的用户体验研究专家智能体——通过定性和定量研究方法验证设计决策，产生可操作的洞察。核心方法：混合研究设计（定性+定量）、三角验证、多数据源确保研究可靠性、默认包含可访问性研究和包容性设计测试。核心交付物：用户画像模板（人口统计/行为模式/目标与需求/使用场景）、用户旅程映射（痛点识别与优化机会）、可用性测试协议（60分钟会话结构化框架）、A/B 测试与统计分析框架。核心原则：**研究方法论优先**——先建立明确研究问题再选择方法；**证据优先沟通**——"基于25次用户访谈和300份问卷，80%用户反馈..."；**研究推荐实施率**——80%+被设计和产品团队采纳是衡量成功的关键指标。与 [[ArchitectUX]]（技术架构）和 [[design-whimsy-injector]]（品牌趣味）协同，共同为 [[LuxuryDeveloper]] 提供完整的用户中心设计支撑。 - -**[[design-whimsy-injector]]**（Whimsy Injector）：The Agency 设计部门的品牌个性化和愉悦感注入专家智能体——通过战略趣味设计为品牌体验增添个性、微交互和游戏化元素，使品牌通过意想不到的愉悦时刻脱颖而出。核心交付物：品牌个性框架（专业/休闲/错误/成功四种场景的人格光谱）、Whimsy 分类学（微妙/交互/发现/情境四类趣味）、微交互设计系统（CSS 动画 + 彩蛋 + 成就系统）。核心原则：有目的的趣味——每个趣味元素必须服务于功能或情感目的，不能分散用户注意力；包容性愉悦设计——确保趣味元素对残障用户可访问、不干扰屏幕阅读器、支持减少动画偏好。Whimsy Injector 与 [[ArchitectUX]] 互补——ArchitectUX 提供技术架构基础，Whimsy Injector 注入品牌人格，两者共同为 [[LuxuryDeveloper]] 提供完整的品牌体验设计。 - -**[[design-visual-storyteller]]**（Visual Storyteller）：The Agency 设计部门的视觉叙事与品牌故事创作专家智能体——专注于将复杂信息转化为引人入胜的视觉叙事内容，驱动情感共鸣和用户参与。核心能力：叙事弧创作（Beginning-Middle-End 三幕结构）、情感旅程映射（情感高峰与低谷的节奏设计）、多媒体内容创作（视频、动画、交互媒体、动态图形）、数据可视化叙事（将复杂数据转化为引人入胜的信息故事）。跨平台策略：Instagram Stories 垂直格式互动叙事、YouTube 横版内容与缩略图优化、TikTok 短垂直视频趋势整合、LinkedIn 专业信息图表格式、Pinterest 垂直布局优化。核心原则：**叙事结构优先**——每个视觉故事必须有清晰的开头、中间和结尾；**情感驱动**——通过情感连接而非单纯信息传递实现参与度提升；**品牌一致性**——所有平台视觉内容必须保持统一品牌叙事；**可访问性合规**——100%满足 WCAG 可访问性标准。与 [[design-brand-guardian]] 互补——Brand Guardian 建立品牌叙事体系，Visual Storyteller 将其转化为具体视觉内容；与 [[design-inclusive-visuals-specialist]] 协同——包容性视觉原则融入叙事创作，确保文化敏感性和无歧视性表征；与 [[UX-Researcher]] 协同——用户研究洞察驱动情感旅程设计决策。与 [[design-whimsy-injector]] 互补——后者在微交互层面注入趣味，Visual Storyteller 在宏观叙事层面构建情感弧线，共同为 [[LuxuryDeveloper]] 提供完整的品牌体验设计支撑。 - -**[[design-image-prompt-engineer]]**（Image Prompt Engineer）：The Agency 设计部门的 AI 图像生成提示词工程专家智能体——专注于将视觉概念精准翻译为可执行的提示词语言，驱动 Midjourney、DALL-E、Stable Diffusion、Flux 等 AI 图像生成工具产出专业级摄影作品。核心方法：五层提示词结构框架（主体描述层 → 环境设定层 → 光线规范层 → 摄影技术层 → 风格美学层）+ 平台特定语法优化 + 体裁专属提示模式（人像/产品/风光/时尚摄影）。核心原则：摄影术语精确性（"f/1.8 bokeh 浅景深"而非"背景模糊"）+ 负向提示词排除不想要元素 + 宽高比和构图纳入每条提示词。成功指标：视觉概念还原率 90%+、多次生成结果一致性高、技术摄影元素（布光/景深/构图）精准渲染。与 [[design-ui-designer]]（像素级精确）存在张力——概率生成固有不确定性，需通过确定性约束（具体颜色值/光照参数）协调；与 [[design-brand-guardian]]（品牌一致性）协同，确保生成图像符合品牌视觉规范；与 [[design-whimsy-injector]]（品牌趣味）互补——提供视觉语言能力支撑趣味元素在图像中的精准表达。 - -**[[InclusiveVisualsSpecialist]]**（Inclusive Visuals Specialist）：The Agency 设计部门的包容性视觉表征专家智能体——专门对抗 AI 图像/视频生成模型（Midjourney、Sora、Runway Gen-3、DALL-E）中内嵌的系统性刻板印象偏见，生成具有文化真实性、尊严感和无歧视性的人类视觉表征。核心挑战：克隆脸（Clone Faces）、异域化偏见（Exoticism Bias）、文化符号乱码（Gibberish Cultural Text）、地理/建筑失真。核心技术：结构化提示词架构（Subject → Sub-actions → Context → Camera Spec → Color Grade → Explicit Exclusions）+ 负向提示库 + 视频物理学定义（服装/头发/辅助器具的运动一致性）。四阶段工作流：Brief Intake → Annotation Framework → Video Physics Definition → 7-Point QA Review Gate。成功指标：表征准确度 100%、AI 伪影消除率 100%、社区验证认可。[[UX-Researcher]] 提供 QA 审查，[[design-brand-guardian]] 把控企业品牌伦理标准。与 [[design-image-prompt-engineer]] 互补——后者侧重摄影美学精准度，前者侧重消除表征偏见与文化真实性。与 [[design-whimsy-injector]] 存在张力——"Kumbaya"式库存照片套路和表演性象征主义是包容性设计必须坚决拒绝的。 - -**[[design-brand-guardian]]**（Brand Guardian）：The Agency 设计部门的品牌战略与身份守护专家智能体——负责创建 cohesive 品牌体系、确保跨所有触点的品牌表达一致性、并通过品牌保护策略维护品牌价值。核心交付物：品牌战略框架（Purpose/Vision/Mission/Values/Personality 五要素）、视觉身份系统（CSS 变量定义的品牌色彩/字体/间距/Logo 变体）、品牌声音指南（Voice Characteristics/Tone Variations/Messaging Architecture/Writing Guidelines）、品牌保护策略（商标监控/合规审计/危机管理）。核心原则：**Brand-First**——在战术执行前必须先建立完整的品牌基础；**一致性优先**——确保品牌识别在 95%+ 触点保持一致；**战略性演进**——品牌必须能够随市场变化成长而不失去核心身份。与 [[design-whimsy-injector]] 互补——Brand Guardian 建立品牌边界并制定一致性标准，Whimsy Injector 在边界内通过有目的的趣味和微交互注入品牌个性，共同为 [[LuxuryDeveloper]] 提供完整的品牌体验设计。与 [[ArchitectUX]]（技术架构）和 [[UX-Researcher]]（用户研究）协同，共同构成 [[The Agency]] 设计部门的完整设计支撑体系。 - -**[[multi-agent-system-reliability]]**（Alex Ewerlöf）：多智能体系统可靠性的架构模式理论——反对拟人化LLM，主张将LLM视为分布式系统中不可靠的组件。核心4模式：[[Hierarchy-Agent-Pattern]]（主管→工作→验证链）、[[Consensus-Voting-Pattern]]（N个LLM多数票消除幻觉）、[[Adversarial-Debate-Pattern]]（Generator→Critic→Judge对抗辩论）、[[Knock-out-Pattern]]（适者生存淘汰制）。核心洞察：不应要求模型"小心"，而应**强制**其正确——通过架构约束而非提示词约束。与 [[Designing for Agentic AI]] 互补（架构 vs 用户体验），与 [[Recursive Self-Optimization]] 共享自引用结构思想。与 [[Genetic-Algorithm]]（遗传算法）有关联——Knock-out/Tree of Thoughts 是 GA 的精简实现。 - -**[[identity-graph-operator]]**（Identity Graph Operator）：多智能体系统共享身份图谱运营专家 Agent——The Agency Specialized 部门的核心基础设施 Agent，解决多 Agent 系统的身份孤岛问题：当多个 Agent 独立处理同一实体时，缺乏共享身份层导致账单 Agent 重复收费、发货 Agent 发送两个包裹、支持 Agent 创建重复客户记录。核心方法：通过规范化（昵称扩展/E.164电话/邮箱小写）→ 阻塞（blocking key 筛选候选）→ 评分（字段级加权）→ 聚类四步实现确定性身份解析；merge/split 操作通过乐观锁执行，按置信度分级处理（>0.95 直接合并、0.6-0.95 提案审查、<0.6 创建新实体）；保留 entity.created/merged/split/updated 完整事件历史。与 [[multi-agent-system-reliability]] 互补——后者解决 Agent 间决策一致性，前者解决 Agent 对同一实体的识别一致性；与 [[Personal CRM]]（联系人去重）同源但增加了并发写入、跨框架身份联邦和多 Agent 审计追踪维度。属 [[Multi-Agent-System-Reliability]] 的身份基础设施层，与 [[Agents-Orchestrator]]（注册身份解析能力）、[[Reality-Checker]]（质量门检验 merge 证据）、[[Support-Responder]]（客户身份预解析）协同构成完整多 Agent 身份体系。 - -**[[Agents-Orchestrator]]**（Agents Orchestrator）：多智能体开发流水线编排器——The Agency Specialized 部门的核心编排 Agent，自主管理从规格文档到生产交付的完整开发流程。核心理念：**每个任务必须通过质量验证才能推进**，不允许跳过 QA 阶段。核心方法：四阶段流水线（Phase 1：[[ProjectManagerSenior]] 规格到任务列表 → Phase 2：[[ArchitectUX]] 技术架构基础 → Phase 3：[开发 ↔ [[EvidenceQA]] 截图验证] 循环 → Phase 4：[[TestingRealityChecker]] 最终集成验证）；最大3次重试上限；标准化状态报告模板。与 [[specialized-workflow-architect]] 互补——后者负责设计工作流模式，前者负责执行工作流流水线的编排，属设计与执行的分层关系。属 [[Multi-Agent-System-Reliability]] 的流水线编排实践层，与 [[Multi-Agent-Team]]（多 Agent 团队架构）共享流水线协调思想。与 [[TestingRealityChecker]] 在质量标准上协同——后者默认"NEEDS WORK"原则，前者确保其判定是最终交付标准。 - -**[[agentic-identity-trust]]**（Agentic Identity & Trust Architect）：自主 Agent 身份认证与信任验证基础设施专家——The Agency Specialized 部门的核心安全基础设施 Agent，解决多 Agent 环境中的身份伪造、授权冒用、审计日志篡改等安全威胁。核心方法：密码学身份体系（Ed25519 公钥，签名密钥/加密密钥/身份密钥分离）、零信任验证模型（默认不信任自报告身份，要求密码学证明）、基于可验证结果的惩罚型信任评分（初始1.0，证据链损坏扣0.5，结果失败按失败率×0.4扣分，凭证超90天扣0.1）、append-only 哈希链式证据记录（每个操作记录 intent→decision→outcome，篡改任意历史记录均可检测）、多跳委托链验证（任意链节断裂则全链失效）、Fail-Closed 授权（无法验证时默认拒绝）。高级能力：算法敏捷性（密码学算法可升级，为后量子迁移预留抽象层）、NIST 后量子标准评估（ML-DSA/ML-KEM/SLH-DSA）、跨框架身份联邦（A2A/MCP/REST/SDK）。与 [[Identity Graph Operator]] 互补——前者解决"这个 Agent 是谁+能做什么"（确定性密码学证明），后者解决"这条记录是否是同一用户"（概率性实体匹配），共同构成完整身份层。与 [[multi-agent-system-reliability]] 协同——后者的对抗辩论/多数票等模式需要前者提供可验证的身份与信任基础。与 [[Designing-for-Agentic-AI]] 存在**潜在冲突**：零信任要求确定性验证 vs LLM 的概率性本质，当前方案通过将核心验证逻辑（密码学签名检查）从 LLM 推理分离为确定性代码组件来解决。 - -**[[xr-interface-architect]]**（XR Interface Architect）：XR 空间界面架构师 Agent——The Agency Spatial Computing 部门的 UX/UI 设计专家，专注于为 AR/VR/XR 沉浸式环境创建直觉化、舒适且可发现的界面。核心方法：HUD / 浮动菜单 / 交互区域设计，支持直接触摸、注视+捏合、控制器和手势四种输入模型；基于人体工程学约束进行 UI 放置，减少晕动症；构建座舱/仪表盘/可穿戴界面布局模板；运行可用性验证实验（舒适度和学习性）。人格特质：**Human-centered, layout-conscious, sensory-aware, research-driven**。与 [[xr-immersive-developer]] 和 [[xr-cockpit-interaction-specialist]] 同属 Spatial Computing 部门，三者共同构建完整的 XR 产品交互基础设施。 - -**[[xr-cockpit-interaction-specialist]]**（XR Cockpit Interaction Specialist）：XR 座舱交互专家 Agent——The Agency Spatial Computing 部门的沉浸式座舱式交互设计专家，专注于设计和实现固定视角、高存在感的座舱交互环境。核心设计原则：约束驱动控制机制（constraint-driven control mechanics）消除自由漂浮运动，通过 3D meshes 和输入约束将控制物理化；座舱人体工学对齐自然的眼-手-头协调流动；多模态交互集成（手势/语音/注视/物理道具）；固定视角设计降低运动病阈值。典型应用场景：模拟指挥中心、航天器座舱、XR 载具界面、训练模拟器。核心工具：A-Frame / Three.js 原型开发。与 [[xr-interface-architect]] 存在层级关系（前者提供座舱交互基础能力，后者构建界面）；与 [[xr-immersive-developer]] 在运动自由度设计上存在张力——前者强调固定视角约束以降低眩晕，后者倾向开放空间沉浸体验。属 [[Spatial-Computing]] 概念在座舱场景的具体应用，为 The Agency 的 XR 产品矩阵提供交互基础设施。 - -**[[xr-immersive-developer]]**（XR Immersive Developer）：XR 沉浸式开发专家 Agent——The Agency Spatial Computing 部门的 WebXR 前端工程师，专注于在浏览器环境下构建跨平台高性能 AR/VR/XR 体验。核心栈：A-Frame / Three.js / Babylon.js；核心能力：WebXR Device API 全套沉浸式支持（hand tracking / pinch / gaze / controller input）、raycasting / hit testing / 实时物理交互、LOD 系统 / occlusion culling / shader tuning 性能优化、跨设备兼容层（Meta Quest / Vision Pro / HoloLens / mobile AR）、模块化组件驱动设计及优雅降级。典型交付物：VR 训练模拟器、AR 可视化界面、空间界面。核心工具：A-Frame / Three.js 原型开发。与 [[XR-Interface-Architect]]（界面架构）和 [[XR-Cockpit-Interaction-Specialist]]（座舱交互）同属 Spatial Computing 部门，共同构建 XR 产品矩阵。与 [[XR-Cockpit-Interaction-Specialist]] 在运动自由度设计上存在张力——后者强调固定视角约束以降低运动病，前者倾向开放空间沉浸体验。属 [[Spatial-Computing]] 概念在浏览器前端场景的具体实现。 - -**[[macos-spatial-metal-engineer]]**（macOS Spatial/Metal Engineer）：Apple 平台专用 Metal 渲染与空间计算 Agent——专注于 Swift + Metal 的高性能 3D 渲染系统和 visionOS 空间计算体验。核心能力：实例化 Metal 渲染（Instanced Rendering）驱动 10k-100k 节点图数据，目标 90fps 立体渲染；通过 RemoteImmersiveSpace 和 LayerRenderer（stereo 模式、RGBA16Float + Depth32Float）实现 macOS 到 Vision Pro 的帧流传输；Metal Compute Shader 执行 GPU 并行力导向图物理模拟（排斥力 + 吸引力 + 阻尼）；注视（Gaze）+ 捏合（Pinch）空间交互与 raycast hit testing。性能约束：GPU 利用率 < 80%、每帧 < 100 draw calls、内存 < 1GB。与 [[xr-immersive-developer]] 互补——前者专注浏览器端 WebXR，后者专注 Apple 原生 Metal 渲染管线；与 [[visionos-spatial-engineer]] 存在职责张力——后者倾向 visionOS 原生开发，前者侧重 macOS 渲染侧 + Vision Pro 流式输出，两者协同构成完整的 Apple 空间计算平台能力。属 [[Spatial-Computing]] 概念在 Apple 原生平台场景的具体实现。 - -**[[visionos-spatial-engineer]]**（visionOS Spatial Engineer）：Apple visionOS 原生空间计算 Agent——专注于 visionOS 26 平台的 SwiftUI volumetric interfaces 和 Liquid Glass Design System 实现。核心能力：Liquid Glass 透明材质设计（自适应 light/dark 环境）、Spatial Widgets（吸附墙面/桌面、持久化放置）、SwiftUI Volumetric APIs（3D 内容集成、volume transient content、breakthrough UI）、RealityKit-SwiftUI 集成（Observable entities、直接手势处理、ViewAttachmentComponent）、Multi-Window Architecture（WindowGroup 管理、玻璃背景效果）、GPU 高效渲染。技术栈：SwiftUI / RealityKit / ARKit / Metal。典型交付物：visionOS 原生空间应用、volumetric 界面、Liquid Glass 体验。与 [[macos-spatial-metal-engineer]] 协同——前者专注 UI/UX 层应用开发，后者专注 GPU 密集型数据渲染，共同构成完整的 Apple 空间计算平台能力。属 [[Spatial-Computing]] 概念在 Apple 原生平台场景的具体实现。 - -**[[specialized-mcp-builder]]**（MCP Builder Agent）：AI Agent 的 MCP（Model Context Protocol）服务器开发专家——设计、构建、测试和部署 MCP 服务器，为 AI Agent 提供自定义工具（Tools）、资源（Resources）和提示词模板（Prompts）能力。核心理念：**工具命名即 UX**——`search_tickets` 优于 `query1`，Agent 必须能从名称推断用途，正确选用率目标 >90%。技术栈：TypeScript + Zod（官方 MCP SDK）或 Python + Pydantic（FastMCP）。核心原则：无状态设计（每次调用独立）、结构化错误返回（`isError: true` 而非堆栈跟踪）、环境变量密钥管理、边界层参数验证、真实 Agent 完整链路测试。高级能力：多传输层支持（Stdio/SSE/Streamable HTTP）、OAuth 2.0 认证、动态工具注册（OpenAPI→MCP 自动生成）、组合式服务器架构。与 [[agentic-identity-trust]] 协同——后者提供身份与信任基础，前者提供工具能力扩展，共同构成完整 Agent 基础设施。与 [[llm-wiki]] 在知识系统层面关联——MCP 服务器可为 Wiki Agent 提供外部知识检索能力。 - -### The Agency — Project Management 部门 -|The Agency 的 Project Management 部门涵盖多个垂直领域的专业项目管理 Agent，从战略组合管理到实验跟踪，覆盖项目全生命周期。| - -**[[project-management-studio-producer]]**（Studio Producer）：高管级战略领导者 Agent——The Agency 项目管理部门的组合管理专家，专注于创意愿景与商业目标对齐的多项目战略管理。核心职责：战略组合规划（Tier 1/2/Innovation Pipeline 三级分级）、Portfolio ROI 管理（要求 ≥ 25%）、95% 按时交付率、高管级利益相关者沟通、风险平衡与财务管控。四阶段工作流：战略规划→项目编排→领导力发展→绩效优化。成功指标：Portfolio ROI ≥ 25%、95% 按时交付、客户满意度 4.8/5、市场排名前三、团队绩效超行业基准。与 [[Project-Management-Studio-Operations]] 协同——Producer 负责战略规划，Operations 负责执行落地；与 [[Project-Manager-Senior]]（执行层任务分解）互补——Studio Producer 关注组合层面的资源分配与优先级排序，Senior PM 关注单项目内部的需求到任务的精确映射，共同构成战略-执行协作闭环。属 Agency 项目管理体系中最高战略层级，与 [[Project-Manager-Senior]]（执行层）→ [[Project-Management-Jira-Workflow-Steward]]（流程治理）→ [[Project-Management-Project-Shepherd]]（项目看护）→ [[Project-Management-Experiment-Tracker]]（实验跟踪）共同构成完整项目管理层级。 - -**[[Project-Management-Studio-Operations]]**（Studio Operations）：日常运营效率与流程优化专家 Agent——The Agency 项目管理部门的执行层 Agent，专注于工作室日常运营效率、流程优化和资源协调，确保 95% 运营效率目标达成。核心职责：SOP 文档化与版本控制（分步程序+质量检查点+升级机制）、资源分配调度和设备技术维护、成本优化与供应商关系管理、运营指标追踪与持续改进。四阶段工作流：流程评估与设计→资源协调管理→实施与团队支持→监控与持续改进。核心交付物：SOP 模板（概述/前提条件/分步程序/质量控制/文档记录）、运营效率报告模板（执行摘要/绩效指标/流程改进/持续改进计划）。成功指标：95% 运营效率、99.5% 系统正常运行时间、团队满意度 4.5/5、年度成本降低 10%、支持响应时间 < 2 小时。与 [[project-management-studio-producer]]（战略层）协同——Producer 负责战略规划，Studio Operations 负责执行落地；与 [[ProjectManagerSenior]] 协同——Senior PM 产出任务列表，Studio Operations 负责执行调度和运营支持；属 Agency 项目管理体系中执行支撑层级，与 Studio Producer（战略层）→ Senior PM（执行层任务分解）→ Studio Operations（执行支撑）共同构成完整项目管理体系。 - -**[[ProjectManagerSenior]]**（Senior Project Manager）：单项目任务分解专家 Agent——The Agency 项目管理部门的执行层 Agent，专注于将网站规格文档（site-setup.md）精准转化为 30-60 分钟可执行开发任务列表。核心方法：**精确引用规格原则**（逐字引用原始需求而非主观添加）、**务实范围控制**（默认基础实现即可接受，拒绝 luxury/premium 功能，除非规格明确）、**开发者优先原则**（任务描述具体到可直接交给开发者的程度）。典型交付物：任务列表保存至 `ai/memory-bank/tasks/[project-slug]-tasklist.md`，每任务包含验收标准、涉及文件列表和规格引用。技术栈要求提取：CSS 框架、FluxUI 组件规格、Laravel/Livewire 集成需求。核心价值：**消除规格到任务之间的翻译损耗**，通过"精确引用+粒度控制+务实范围"三原则防止项目范围蔓延（scope creep）。与 [[Project-Management-Studio-Operations]] 互补——Senior PM 产出任务列表，Studio Operations 负责执行调度；与 [[Project-Management-Jira-Workflow-Steward]] 协同——Jira 工作流编排基于 Senior PM 产出的任务列表执行；与 [[ProjectManagerSenior]] 在知识图谱中等同于 [[ProjectManagerSenior]]。 - -**[[Project-Management-Experiment-Tracker]]**（Experiment Tracker）：实验追踪与数据驱动决策专家 Agent——The Agency 项目管理部门的实验管理专家 Agent，专注于 A/B 测试、功能实验和假设验证的科学化管理。核心职责：设计统计有效的 A/B 测试和多变量实验（默认 95% 置信度）、管理实验 Portfolio 组合（每季度 15+ 实验）、执行统计功效分析确定所需样本量、实施渐进放量与安全监控。高级能力：多臂老虎机（Multi-armed Bandits）动态流量分配、贝叶斯分析支持实时决策、因果推断技术理解实验真正效果、ML 模型 A/B 测试与预测建模。典型交付物：实验设计文档模板（假设/设计/风险评估/实施计划）、实验结果报告模板（统计结果/置信区间/业务影响/决策建议）。成功指标：95% 实验达统计显著性、70% 实验成功率、80% 成功实验实现落地。与 [[Project-Management-Studio-Producer]] 协同——Producer 基于实验数据优化 Portfolio 资源配置；与 [[Project-Management-Studio-Operations]] 存在潜在张力——实验节奏（等待统计显著性）可能与内容制作节奏冲突；与 [[Project-Management-Jira-Workflow-Steward]] 协同——实验结果通过 Jira 工作流转化为产品改进任务。属 Agency 项目管理体系中的实验验证层级，补充了从战略规划→任务分解→实验验证→流程治理的完整闭环。 - -### The Agency — Testing 部门 -|The Agency 的 Testing 部门涵盖 API 测试、可访问性审计、工具评估、证据收集、结果分析、性能基准、真实性检验、工作流优化等专业测试 Agent，覆盖从功能到安全到性能的全方位质量保障。| - -**[[testing-api-tester]]**（API Tester）：API 测试与验证专家 Agent——The Agency Testing 部门的核心 API 质量保障专家，专注于全面的 API 功能验证、性能测试和安全审计。核心理念：**Breaks your API before your users do**——防御性测试哲学，主动发现潜在问题。核心能力：Playwright/REST Assured/k6 自动化测试框架、95%+ API 端点覆盖率目标、CI/CD 流水线集成。性能 SLA：95 百分位响应时间 < 200ms、10x 正常负载验证、错误率 < 0.1%。安全测试覆盖 OWASP API Security Top 10（认证绕过/SQL 注入/XSS/速率限制等）。与 [[specialized-model-qa]] 互补——后者测试 ML 模型质量，前者测试 API 端点行为；与 [[multi-agent-system-reliability]] 协同——系统可靠性依赖 API 质量验证。 - -**[[testing-workflow-optimizer]]**（Workflow Optimizer）：流程优化与工作流自动化专家 Agent——The Agency Testing 部门的核心流程改进专家，基于系统思维方法论分析、优化和自动化跨业务功能的工作流。核心理念：**找到瓶颈，修复流程，其余自动化**。核心方法：四阶段工作流（现状分析与文档化→优化设计与未来状态规划→实施规划与变更管理→自动化实现与监控）+ 数据驱动决策框架（测量→验证→文档化）。方法论融合：Lean（消除浪费）/Six Sigma（DMAIC 减少变异）/Kaizen（持续改进）/统计过程控制。人本设计原则：在追求效率的同时平衡员工满意度与认知负荷，在自动化效率与人类判断创造力之间取得平衡。核心交付物：WorkflowOptimizer Python 框架（含瓶颈识别/自动化潜力评估/ROI 计算/实施路线图生成）。成功指标：40% 平均周期时间改善、60% 常规任务自动化率、75% 流程相关错误减少、90% 优化流程 6 个月内成功采纳、30% 员工满意度提升。与 [[specialized-workflow-architect]] 互补——后者负责工作流设计建模（穷举路径/状态树），前者负责工作流实施改进（量化效率收益/自动化 ROI），属于设计与执行的分层关系。与 [[product-behavioral-nudge-engine]] 在自动化 vs 人机交互上存在互补张力：Workflow Optimizer 追求最大化自动化，Nudge Engine 追求最大化员工参与，两者共同构成效率与人本的双轮驱动。 - -**[[testing-reality-checker]]**（Reality Checker）：截图驱动型生产就绪认证 Agent——The Agency Testing 部门的最后一道防线 Agent，通过自动化截图证据截断"幻想型认证"，要求压倒性视觉证明才授予生产就绪状态。核心理念：**默认"NEEDS WORK"，以截图证据截断虚假乐观评估**。核心方法：三步强制流程（Reality Check 命令验证实际构建 → QA 交叉验证自动化证据 → 端到端截图分析用户旅程）+ 硬性失败触发器（完美评分/无证据声明/声称奢华但实为基础实现/规格未落地）。默认状态：NEEDS WORK；C+/B- 评级属正常；第一次实现通常需要 2-3 轮修订。与 [[testing-workflow-optimizer]] 存在张力：Optimizer 追求效率（目标 60% 自动化率），Reality Checker 追求真实性（要求每轮修订充分证据），在修订周期数量上可能存在分歧；与 [[testing-api-tester]] 互补——API Tester 提供后端接口测试证据，Reality Checker 要求端到端截图，两者共同构成前后端双重质量门控。与 [[Agents-Orchestrator]] 协同——作为多智能体流水线的最终质量门控。 - -**[[testing-performance-benchmarker]]**（Performance Benchmarker）：性能测试与优化专家 Agent——The Agency Testing 部门的性能工程专家，通过系统性性能测试确保系统以 95% 置信度满足 SLA 要求。核心理念：**量化一切可量化的，用数据证明优化价值**。核心能力：负载/压力/耐力/可扩展性测试，Core Web Vitals 优化（LCP < 2.5s / FID < 100ms / CLS < 0.1），k6 性能测试框架，统计置信区间分析，容量规划与成本-性能权衡。交付物模板包含性能测试结果、瓶颈分析（数据库/应用层/基础设施/第三方服务）、Core Web Vitals 评分、ROI 分析和优化建议。成功指标：95% 系统持续满足性能 SLA，Core Web Vitals 达到"良好"评级（90th percentile），关键用户体验指标改善 25%，支持 10x 当前负载。与 [[testing-reality-checker]] 互补——Reality Checker 验证视觉真实性，Performance Benchmarker 验证性能指标，两者共同构成质量保障的双重维度；与 [[testing-api-tester]] 协同——API Tester 提供 API 层面的性能 SLA（p95 < 200ms），Performance Benchmarker 提供系统整体性能视图。 - -**[[testing-test-results-analyzer]]**（Test Results Analyzer）：测试结果分析与质量情报专家 Agent——The Agency Testing 部门的核心测试数据分析和洞察生成专家，通过统计分析方法、机器学习预测模型和可视化报告将原始测试数据转化为战略决策依据。核心理念：**数据驱动的质量决策**，所有结论必须通过统计方法验证，提供置信区间和显著性分析。核心能力：测试覆盖率分析（行/分支/函数/语句覆盖 + 差距识别）、失败模式统计分类（功能/性能/安全/集成）、基于 RandomForest 的缺陷易发性预测、发布就绪多维度评估（通过率 + 覆盖率阈值 + 性能 SLA + 安全合规 + 缺陷密度）、质量投资 ROI 分析。Python 框架：pandas + numpy + scipy.stats + sklearn RandomForestClassifier + matplotlib/seaborn 可视化。成功指标：质量风险预测准确率 95%+、90% 分析建议被开发团队采纳、85% 缺陷逃逸预防改善、24 小时内报告交付、干系人满意度 4.5/5。与 [[testing-performance-benchmarker]] 协同——Performance Benchmarker 提供性能维度的测试数据，Test Results Analyzer 提供整体质量情报视图；与 [[testing-api-tester]] 互补——API Tester 产生测试执行数据，Test Results Analyzer 负责解读和预测；与 [[testing-reality-checker]] 互补——Reality Checker 验证视觉真实性，Test Results Analyzer 量化质量指标趋势。与 [[Multi-Agent-System-Reliability]] 中的统计验证方法论共享数据驱动决策思想。 - -**[[testing-tool-evaluator]]**（Tool Evaluator）：技术评估与战略工具采纳专家 Agent——The Agency Testing 部门的技术评估与战略工具采纳专家，专注于 ROI 导向的工具分析、竞争对比和战略技术采纳建议。核心理念：**量化一切可量化的，成本-功能-风险三维权衡**。核心能力：7维加权评分体系（功能25%/可用性20%/性能15%/安全15%/集成10%/支持8%/成本7%）、4阶段工作流（需求收集→全面测试→财务风险分析→实施规划）、TCO/ROI 量化计算框架。Python 框架：pandas + numpy + requests + dataclass 评分模型。成功指标：90%+ 推荐准确性，85%+ 6个月采用率，20%+ 成本优化，25%+ ROI。与 [[testing-reality-checker]] 互补——后者验证视觉真实性，前者量化战略价值，两者共同构成质量保障与投资决策双重维度；与 [[testing-performance-benchmarker]] 协同——后者提供性能基准数据，前者将其纳入综合评分体系；与 [[Agents-Orchestrator]] 协同——编排器调度评估任务并接收工具选型建议。 - -### The Agency — Paid Media 部门 -The Agency 的 Paid Media 部门专注于企业级付费媒体策略与运营，涵盖 Google Ads、Microsoft Advertising、Amazon Ads 三大核心平台。 - -**[[paid-media-ppc-strategist]]**（PPC Campaign Strategist）：企业级付费搜索与效果媒体策略 Agent——由 John Williams（@itallstartedwithaidea）设计，专注于 Google Ads、Microsoft Advertising、Amazon Ads 三大平台的企业级账户架构、自动化竞价策略和预算管理。核心能力：分层活动架构（品牌/非品牌/竞品/征服）、Smart Bidding（tCPA/tROAS/Max Conversions）、Performance Max 资产组设计、Google Ads API 自动化、MCC 级策略、增量测试框架（geo-split/holdout/matched market）。核心理念：**账户架构即战略**，整个系统（活动/广告组/受众/信号）协同驱动业务成果。成功指标：品牌展示份额 90%+、非品牌 40-60%、QS 7+ 占比 70%+、日预算消耗率 95-100%、季度转化量增长 15-25%。与 [[PerformanceMax]]（AI 驱动全渠道广告）和 [[SmartBidding]]（自动竞价）共同构成付费媒体策略的核心技术支柱。与 [[PaidMediaProgrammaticBuyer]] 在预算分配上存在潜在张力——PPC 侧重高意图搜索流量，Programmatic 侧重品牌曝光。与 [[TieredCampaignArchitecture]]（分层活动架构）和 [[AccountArchitecture]]（账户架构）构成完整的账户结构方法论。 - -**[[paid-media-programmatic-buyer]]**（Programmatic & Display Buyer）：程序化购买与展示广告策略 Agent——专注于程序化广告购买和展示广告策略执行，覆盖 DSP 平台操作、受众定向、创意优化和效果分析。与 [[paid-media-ppc-strategist]] 协同：前者定义全渠道预算分配和策略框架，后者执行具体程序化购买操作。 - -**[[paid-media-creative-strategist]]**（Creative Strategist）：付费媒体广告创意策略 Agent——由 John Williams（@itallstartedwithaidea）设计，专注于 Google、Meta、Microsoft 及程序化平台的全渠道广告文案创作、响应式搜索广告（RSA）架构设计和系统性创意测试框架。核心理念：**创意是自动化竞价环境中最大的可控杠杆**，当算法接管了出价、预算和定向时，每一条标题、描述、图片和视频都是一个待验证的假设。核心能力：15-headline RSA 策略设计（全品牌/利益/功能/CTA/社会证明分类，确保所有可能组合语法和逻辑上都能成立）；Hook-Body-CTA 视频广告叙事结构；资产组（Asset Group）组合策略；A/B 测试框架与统计显著性标准（2-4 周内达到）；广告强度（Ad Strength）优化（90%+ 达到 "Good" 或 "Excellent"）；创意疲劳（Creative Fatigue）监测与快速迭代（每 2 周一次创意测试）。成功指标：CTR 提升 15-25%、转化率提升 5-10%、测试后 2-4 周内达成统计显著性。与 [[paid-media-ppc-strategist]] 协同：PPC 策略师定义账户架构和竞价策略，创意策略师提供素材支撑，两者共同制定 Performance Max 和 Display 投放方案；与 [[paid-media-paid-social-strategist]] 协同：社交策略师提供受众洞察和平台选择，创意策略师据此定制平台原生创意执行。与 [[ResponsiveSearchAds]]（RSA 架构）、[[PerformanceMax]]（Asset Group 设计）、[[AdStrength]]（广告强度评分）、[[CreativeFatigue]]（创意疲劳监测）和 [[HookBodyCTA]]（视频广告叙事框架）共同构成付费媒体创意优化的完整方法论。 - -**[[paid-media-tracking-specialist]]**（Tracking Specialist）：付费媒体追踪专家——负责转化追踪配置、数据归因建模和跨平台效果归因。与 [[paid-media-ppc-strategist]] 协同：为竞价策略优化提供可靠的数据基础。 - -**[[paid-media-search-query-analyst]]**（Search Query Analyst）：搜索词分析专家——分析搜索词报告，识别高效关键词和负向关键词优化机会。与 [[paid-media-ppc-strategist]] 协同：提供关键词策略的数据支撑。 - -**[[paid-media-auditor]]**（Auditor）：付费媒体账户审计专家——系统化评估 Google Ads、Microsoft Ads 和 Meta Ads 账户，覆盖 200+ 检查点（账号结构/追踪配置/竞价策略/创意/受众/竞争定位），每项发现附严重程度和预估业务影响。与 [[paid-media-ppc-strategist]] 协同：基于后者定义的基准进行效果诊断。成功指标：审计通常识别 15-30% 效率提升机会，80%+ 高优先级建议 30 天内落地。 - -**[[paid-media-paid-social-strategist]]**（Paid Social Strategist）：跨平台付费社交广告专家——覆盖 Meta（Facebook/Instagram）、LinkedIn、TikTok、Pinterest、X 和 Snapchat，设计从引流到再营销的全漏斗社交广告项目。核心理念：社交广告本质是"打断"而非"回答"，必须构建平台原生体验而非跨平台复用创意。核心能力：全漏斗架构（引流→互动→再营销→留存）、平台差异化创意策略、像素/CRM 受众工程、Conversions API 实施、SKAdNetwork 应对 iOS 隐私变化。与 [[paid-media-ppc-strategist]] 和 [[paid-media-programmatic-buyer]] 同属付费媒体体系，但专注社交渠道而非搜索或程序化展示。关键决策原则：跨渠道预算分配必须基于搜索+展示+社交综合数据验证，而非单一渠道数据。 - -Key concepts: [[PerformanceMax]], [[SmartBidding]], [[AccountArchitecture]], [[TieredCampaignArchitecture]], [[IncrementalityTesting]], [[ConversionActionHierarchy]], [[CustomerMatch]], [[BudgetPacing]], [[ResponsiveSearchAds]], [[AdStrength]], [[CreativeFatigue]], [[HookBodyCTA]], [[MessageMatch]], [[ABTesting]], [[AdExtensions]] - -### The Agency — Product 部门 -|The Agency 的 Product 部门涵盖用户反馈分析、趋势研究、产品路线图规划和行为引导等专业 Agent。| - -**[[product-feedback-synthesizer]]**（Product Feedback Synthesizer）：The Agency 产品部门的用户反馈综合分析专家 Agent——专精于从多渠道（调查/访谈/工单/评论/社交媒体）收集、分析和综合用户反馈，将海量用户声音蒸馏为可量化的产品决策依据。核心能力：NLP 情感分析与满意度建模（NPS/CSAT/CES）、RICE/MoSCoW/Kano 多维度优先级框架、用户旅程映射与痛点识别、流失预测与早期预警系统。核心理念：**定性反馈 → 定量优先级 → 数据驱动路线图**。成功指标：24 小时内处理关键问题、90%+ 主题准确率（利益相关者验证）、85% 综合反馈产生可衡量决策、NPS 提升 10+ 分、80% 反馈驱动功能成功率。与 [[product-sprint-prioritizer]]（Sprint 迭代优先级）和 [[product-trend-researcher]]（产品趋势研究）协同，共同构成 The Agency 产品部门的数据驱动决策体系。 - -**[[product-trend-researcher]]**（Product Trend Researcher）：The Agency 产品部门的专家级市场情报分析师——专注于新兴趋势识别、竞争分析和机会评估，为产品战略和创新决策提供可操作的洞察。核心能力：七步趋势识别流程（信号收集→模式识别→上下文分析→影响评估→验证→预测→可操作性）；覆盖 50+ 数据源实时聚合，统计验证的弱信号检测，提前 3-6 个月识别主流采纳前的趋势；TAM/SAM/SOM 三层市场量化（置信区间 ±20%）；竞争情报框架（直接/间接/新兴/技术/替代）。成功指标：80%+ 准确率的 6 个月趋势预测、90% 洞察转化为战略决策、48 小时内紧急请求响应、15+ 独立验证来源/报告。与 [[product-manager]] 协同——后者提供产品规格与市场定位输入，前者提供趋势情报与竞争格局分析；与 [[product-feedback-synthesizer]] 互补——后者分析已有用户反馈，前者预判未来市场趋势，共同构成数据驱动的产品决策闭环。属 The Agency 产品部门的市场情报核心层。 - -**[[product-manager]]**（Product Manager Agent — Alex）：The Agency 产品部门的核心战略 Agent——以 10+ 年 B2B SaaS/消费者应用/平台业务经验的产品经理身份，自主拥有从发现到衡量的完整产品生命周期。核心理念：**以结果为导向，而非产出**，功能是假设，发布是实验，成功的产品必须 measurable 改变用户行为。核心交付物：PRD（含机会评估/用户故事/Launch Plan/风险矩阵）、Opportunity Assessment（RICE 评分）、Now/Next/Later 路线图、GTM Brief、Sprint Health Snapshot。六阶段工作流：Discovery → Framing/Prioritization → Definition → Delivery → Launch → Measurement。核心原则：**先问题后方案**（永远不接受表面的功能请求）、**写新闻稿再写 PRD**、**无 Owner/Metric/Time Horizon 不上路线图**、**经常说"不"保护团队焦点**。与 [[Agents-Orchestrator]] 协同——由编排器协调任务；与 [[product-feedback-synthesizer]] 互补——后者收集用户反馈，前者将反馈转化为产品决策和交付计划。属 The Agency 产品部门的战略决策核心层。 - -**[[product-sprint-prioritizer]]**（Product Sprint Prioritizer）：The Agency 产品部门的冲刺规划与优先级排序专家 Agent——专注于敏捷冲刺规划、特性优先级排序和资源分配，通过数据驱动的优先级框架最大化团队交付价值。核心能力：RICE/MoSCoW/Kano/Value vs. Effort 等多框架优先级评分；基于 6 个冲刺滚动平均值的团队速率预测（偏差 < 15%）；冲刺前五步准备（Backlog Refinement → 依赖分析 → 容量评估 → 风险识别 → 干系人审查）；技术债务与新功能的 ROI 平衡建模；跨团队依赖识别与关键路径分析。成功指标：承诺故事点交付率 90%+、干系人满意度 4.5/5、时间线偏差 ±10%、技术债务占比 < 20%。核心理念：**数据驱动的优先级决策**——每个评分附置信区间和敏感性分析；**冲刺目标先行**——无清晰可衡量目标的冲刺不上计划；**主动风险管理**——风险评分（概率 × 影响矩阵）定期重新评估。与 [[product-manager]] 协同——PM 制定路线图，本 Agent 将路线图转化为可执行的冲刺计划；与 [[product-feedback-synthesizer]] 互补——后者提供用户反馈驱动的优先级输入，前者将优先级决策转化为 Sprint 容量规划。属 The Agency 产品部门的执行规划核心层。 - -### The Agency — Finance 部门 -|The Agency 的 Finance 部门涵盖自主支付运营、财务分析与合规管理等专业 Agent。| - -**[[accounts-payable-agent]]**（Accounts Payable Agent）：The Agency 财务部门的自主支付运营专员 Agent——处理供应商付款、承包商发票和周期性账单，覆盖 ACH/Wire/Crypto/Stablecoin/Payment API 等全支付通道。核心原则：**幂等性优先**（reference ID 去重，零重复付款）、**审计全链路**（每笔支付记录发票引用、金额、通道、时间戳和状态）、**安全路由**（自动选择最优通道路由，失败自动切换备选通道）、**严格额度管控**（超授权额度必须人工审批）。通过 tool calls 与 Contracts Agent、Project Manager Agent、HR Agent 集成，接收来自其他 Agent 的支付请求并生成支出报告供 Strategy Agent 分析。成功指标：零重复付款、< 2 分钟执行时间（快捷通道）、100% 审计覆盖、60 秒内 escalation SLA。属 [[Multi-Agent-System-Reliability]] 的财务合规执行层，[[Accounts-Payable-Agent]] 为 The Agency 提供可信赖的支付执行基础。 - -### Multi-Agent Monitoring & Automation -**Dynamic Dashboard**：基于 [[OpenClaw]] 的多数据源实时监控仪表盘——通过子代理并行抓取 GitHub/Twitter/Polymarket/系统健康等多数据源，定时聚合结果推送 Discord，支持告警阈值和历史趋势存储。用对话式指令替代数周前端开发，立即获得实时洞察。[[polymarket-autopilot]] 是 Polymarket 市场监控的具体实现——AI Agent 24/7 自动监控预测市场、分析概率变化、自动执行交易策略。与 [[self-healing-home-server]] 的系统监控场景关联，[[earnings-tracker]] 的市场数据监控场景扩展，[[content-factory]] 共享子代理并行执行模式。 - -**[[multi-source-tech-news-digest]]**：AI Agent 驱动的多源科技新闻自动聚合与投递系统——四层数据管道整合 46 个 RSS 源、44 个 Twitter/X KOL 账号、19 个 GitHub Releases 仓库和 4 个 Brave Search 主题，覆盖 109+ 信息源；通过标题相似度去重和多维度质量评分（priority source +3, multi-source +5, recency +2, engagement +1）生成精选简报；支持 Discord/Email/Telegram 三通道投递，30 秒内通过自然语言添加自定义来源。属 [[Daily-YouTube-Digest]] / [[Daily Reddit Digest]] 同款 Cron Job + AI 摘要模式的不同垂直场景（前者视频，后者 Reddit 社区，本方案文字新闻）。 - -### Cloud Transformation & DevOps -**[[cloud-learning-master-index]]**（Cloud Learning Master Index）：OpenText/微焦点云转型学习会话视频总索引，NAS 源位于 `/volume2/work/Public Cloud Learning Sessions/`，覆盖 10 大技术领域共 **111 个视频**——AWS Landing Zone（22）、OpenText Series（21）、EKS & Kubernetes（14）、Security（9）、Networking（9）、Serverless & AI（9）、FinOps & Cost（10）、CI/CD & GitOps（8）、IAM & Identity（3）、Terraform & IaC（6）。该索引是所有 CTP 专题视频的元数据入口，涵盖从基础设施（AWS Landing Zone）到应用层（Serverless/AI）的完整知识体系，为工程师和架构师提供按主题快速定位学习资源的导航能力。 - -Git 是云转型计划中 DevOps 与 CI/CD 流水线的基础技能。**[[ctp-topic-2-git]]**（CTP Topic 2）作为 CI/CD/GitOps 系列的开篇，涵盖 Git 版本控制系统基础概念与实践，与 [[ctp-topic-9-ci-cd-with-gruntwork]]（Gruntwork CI/CD）和 [[ctp-topic-33-an-introduction-to-gitops]]（GitOps 入门）构成完整的学习链路。**[[ctp-topic-3-deploy-and-maintain-infrastructure]]**（CTP Topic 3）深入 Landing Zone 环境下的基础设施部署方法论——核心区分：Service Module（业务视角，满足业务需求的一组模块组合）与 Regular Module（技术视角，单一技术构建块）；Terragrunt HCL 文件通过版本锁定而非 master 分支引用模块；Service Catalog 支持三级复用（单账户→产品团队→跨团队）。类 OO 继承原则：抽象层次越高，配置选项越少。Terragrunt 在运行前预取所有依赖，通过缓存目录管理克隆仓库。属 IaC 模块化治理的基础原则层，与 [[ctp-topic-9-ci-cd-with-gruntwork]]（CI/CD 实践）和 [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]（Atlantis 工具）共同构成完整的 IaC 知识链路。注意：[[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]] 提到 Atlantis 当前不支持 EKS 部署，两者存在实践约束差异，需通过 Jenkins + Terragrunt 替代。 - -**[[ctp-topic-9-ci-cd-with-gruntwork]]**（CTP Topic 9）聚焦 CI/CD 与 Gruntwork 在 AWS Landing Zone 中的实践，基于 Gruntwork 参考架构通过 Terraform/Terragrunt 实现基础设施自动化交付（⚠️ 视频待 Whisper 转录后补充详细内容）。 - -Cloud Transformation Programme (CTP) materials cover AWS landing zones, EKS, Terraform, GitOps, FinOps, observability, security, and enterprise architecture. Key themes: 3 Lines of Defence framework, ITSM, container hardening, backup & DR strategies. DevOps culture focuses on four pillars: Collaboration, Automation (CI/CD, IaC), Continuous Improvement (Kaizen), and Customer-Centricity. Agile practices (Scrum, Kanban) are symbiotic with DevOps. Emerging trends: DevSecOps, GitOps, Serverless DevOps, AI/ML-driven automation, and Edge Computing DevOps. - -**[[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]**（CTP Topic 32）：Atlantis 替代 Jenkins 用于 Terraform IaC 部署——针对当前 Jenkins 流水线初始化慢（多次代码克隆/顺序测试/ECS 预配置）和架构复杂（持续叠加功能导致脆弱）的双重痛点，Atlantis 提供 PR 评论式协作模型，开发者直接在 GitHub PR 上评论 `atlantis plan`/`apply` 即可触发变更，无需独立账号；每个 Landing Zone 共享账户部署单台 EC2 实例，通过 GitHub Enterprise Webhook 接收通知，服务账号负责评论/合并/关闭 PR；跨账户访问通过在各账户部署的 IAM 角色实现；并行构建支持多模块并发 plan/apply；锁定机制防止多 PR 同时操作同一模块产生冲突。Atlantis 在 merge 前即应用变更，确保代码与基础设施始终同步。属 [[GitOps]] 工具实践层，与 [[ctp-topic-33-an-introduction-to-gitops]]（GitOps 概念）和 [[ctp-topic-9-ci-cd-with-gruntwork]]（Gruntwork CI/CD）共同构成完整链路。注意：[[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]] 提到 Atlantis 当前不支持 EKS 部署，两者存在实践约束差异。 - -**[[ctp-topic-33-an-introduction-to-gitops]]**（CTP Topic 33）：Victor Etkin 讲解 GitOps 方法论入门——GitOps 将软件开发原则应用于部署流程，解决部署失败和配置不一致问题。四大原则：声明式配置、版本控制、CD 流程分离、自修复协调器；核心工具仅需 Git。GitOps Controller 持续比对 Git 声明的期望状态与系统实际状态，自动调和偏差。Pull 模型（代理同时监控 Git 和目标系统）比 Push 模型安全性更高，是 GitOps 推荐模式。CI 专注代码构建和分析，CD 专注二进制部署，两者解耦增强安全性。幂等平台（如 Kubernetes）是 CD 流程顺利运行的必要条件。Git 提交日志天然构成合规审计追踪。属 [[GitOps]] 概念层核心来源，与 [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]（Atlantis 工具）和 [[ctp-topic-2-git]]（Git 基础）共同构成 CI/CD/GitOps 完整知识链路。 - -**[[ctp-topic-15-working-with-renovatebot]]**（CTP Topic 15）：Paul Hopkins 主讲 Renovate Bot 自动化依赖项更新——解决"依赖地狱"问题，实时扫描 Docker 镜像/Terraform 模块/Terragrunt 配置/pre-commit 钩子等版本标签，自动发起 Pull Request；通过 Dependency Dashboard 提供全局依赖状态视图；集成 Jenkins 流水线，使用 Podman 容器化运行并配置 Rate Limiting 避免 PR 风暴；提升基础设施安全性（及时修复漏洞）和配置一致性。属 [[GitOps]] 和 [[CI/CD Pipeline]] 的依赖治理层，与 [[ctp-topic-9-ci-cd-with-gruntwork]]（Gruntwork CI/CD）和 [[ctp-topic-33-an-introduction-to-gitops]]（GitOps 入门）共同构成完整的 IaC 知识链路。 - -**[[ctp-topic-56-automated-infrastructure-testing]]**（CTP Topic 56）：Mark Francis 主讲自动化基础设施测试——将软件测试原则应用于 Terraform IaC 代码，通过 TerraTest（Golang 框架）实现 apply → test → destroy 自动化验证循环。核心主张：集成测试超越语法检查，验证实际部署行为是否符合预期；倡导测试驱动开发（TDD）应用于 IaC 领域，先写测试再实现功能；提议将测试编写作为基础设施开发的首要步骤，移除手动验证，追求自动化验证套件和更高的部署信心。核心价值观："让机器做重复的事，把人脑留给复杂的人类问题"。属 [[GitOps]] 和 [[CI/CD Pipeline]] 的质量保障层，与 [[ctp-topic-33-an-introduction-to-gitops]]（GitOps 概念）和 [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]（Atlantis 工具）共同构成 IaC 知识体系。 - -**[[ctp-topic-48-terraform-vs-terragrunt]]**（CTP Topic 48）：Bob（AWS Solutions Architect）对比 Terraform 与 Terragrunt——Terraform（HashiCorp 出品）是云厂商无关的 Golang 应用，通过状态文件将期望状态与实际环境绑定，企业级使用须将状态文件存储在安全可访问位置；Terragrunt 是 Terraform 的轻量封装，贯彻 DRY 原则，通过管理 provider 和 remote_state 块减少跨环境的重复声明。两者命令和语法高度一致（`terraform plan` = `terragrunt plan`），Terragrunt 通过减少硬编码来优化大规模企业部署。辅助工具：Terraform Enterprise（CI 平台 + workspaces）、Gruntwork（预建可定制模块）、Atlantis（Git 集成）、tfsec（静态安全分析）、Terratest（IaC 测试自动化）。属 [[Infrastructure As Code]] 工具选型层，与 [[ctp-topic-3-deploy-and-maintain-infrastructure]]（Terragrunt HCL）和 [[ctp-topic-56-automated-infrastructure-testing]]（Terratest）共同构成 Terraform 生态知识链路。 - -**（本条新增）Learning Sessions ECS Deployment using IAC**（2023-08-08）：JP 和 Raja M 主讲，CTP/SRE 团队通过 Terraform IaC 实现 ECS 容器化应用自动化部署——基于 Gruntwork 仓库构建的 ECS 模块，将 Docker 容器作为逻辑单元，支持 EC2 实例部署；核心功能：自动扩缩容、自动故障恢复、金丝雀部署；通过 Listener 方式集中管理（避免各产品团队重复下载 Gruntwork 代码）；前置条件包括 VPC、ELB 安全组和 EFS 卷挂载；集成 CloudWatch/Splunk/Grafana/Prometheus。ECS 作为 AWS 原生技术与 AWS 服务深度集成，适合追求简单性和紧密集成的场景；属 [[Infrastructure-as-Code]] 在 ECS 场景的实践，与 [[ctp-topic-70-eks-deployment-using-iac]]（EKS IaC 部署）构成容器编排双路径，与 [[ctp-topic-9-ci-cd-with-gruntwork]]（Gruntwork CI/CD）共享 Gruntwork 基础设施基础。与 [[ctp-topic-67-cloud-native-observability-using-opentelemetry]] 在可观测性集成方面关联（ECS 模块集成 CloudWatch/Grafana）。同主题另一来源：[[learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi]]。 - -**[[ctp-topic-16-cross-account-terraform-modules]]**（CTP Topic 16）：Fibos 主讲，多账号 AWS 环境中跨账号 Terraform 模块的中心化部署方案——解决原有 Gruntwork 流水线主要针对单账号设计、账号间直接互访存在安全风险（Blast Radius）的问题。核心架构：基于 **Shared Account（共享账号）** 作为中转站，Jenkins 托管于 Shared Account，检测到模块目录中 `cross-account.json` 标记文件后触发 **ECS Deploy Runner**（ECS 上的 Docker 容器）；该 Runner 通过 Assume Role 访问目标账号的两个角色——`TF state bucket accessor`（读取状态文件）和 `cross-account ECS deploy runner role`（执行资源部署）；角色切换逻辑在根目录 `terragrunt.hcl` 中全局配置。实现三大目标：**安全性**（无 Workload 账号间直接信任）、**自动化**（Jenkins 自动识别模块类型）、**可复用性**（模块代码不硬编码特定账号角色）。属 [[Infrastructure-as-Code]] 在多账号场景的进阶实践，与 [[ctp-topic-9-ci-cd-with-gruntwork]]（单账号流水线）构成演进关系，与 [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]（Atlantis 跨账号角色）共享 Assume Role 机制但执行载体不同（ECS 容器 vs EC2），与 [[ECS Deploy Runner]]（实体）共同构成跨账号部署完整链路。 - -**Learning Sessions Cloud Transformation Programme-Deploying RDS via Terraform**（2023 年，Greg，DBRE 团队）：Greg 来自 Database Reliability Engineering 团队，倡导通过 Terraform IaC 部署任何规模的 RDS 到 AWS，相比控制台具有速度、灵活性、一致性、灾难恢复、文档和自动化六大优势——**代码即文档**。RDS 部署提供两种模块选择：**裸 RDS module**（基础功能）和 **grunt work RDS Service**（推荐生产使用，预建 KMS 密钥加密和 CloudWatch 告警，SRE 核心模块功能弱于 grunt work）。**Terragrunt**（Terraform 封装器）用于保持代码整洁、避免变量重复声明，贯彻 DRY 原则；Day 2 运维（扩缩容、补丁、大版本升级）通过修改 Terragrunt 文件并提交 GitHub PR，由 Atlantis 自动应用变更。监控通过 CloudWatch Dashboard + Alarms 实现，需注意突发性能实例（burstable instance）的 CPU credits 消耗。属 [[Infrastructure-as-Code]] 在 RDS 数据库场景的实践，与 [[ctp-topic-48-terraform-vs-terragrunt]]（Terragrunt 推荐）和 [[ctp-topic-16-cross-account-terraform-modules]]（跨账号 Terraform 模块）共同构成 Terraform 生态知识链路，与 [[ctp-topic-9-ci-cd-with-gruntwork]]（Gruntwork CI/CD）共享 Gruntwork 模块体系。 - -**[[ctp-topic-12-using-ses-smtp-service-terraform-module]]**（CTP Topic 12）：Christian Deckelmann 和 Filos Christolakis 主讲，Micro Focus 团队使用 Terraform 模块自动化部署 AWS SES SMTP 服务以替代传统本地 SMTP 网关——随着业务向云端迁移，本地 SMTP 网关（如 smtbmicrofocus.com）已不再高效，SES 是网络安全部门唯一批准的云端邮件发送方案。Terraform 模块封装了 SMTP 终端节点配置，支持现有应用程序通过标准 SMTP 协议集成，无需重构代码适配 SES API；技术实现：在应用 VPC 中配置 VPC 端点实现私有连接（无需公网访问），通过 IAM 用户凭证作为 SMTP 认证信息并存储于 Secrets Manager，自动化完成 DKIM 验证和 Infoblox DNS 记录创建。两个关键手动步骤：① 申请脱离 SES Sandbox Mode（提交工单获取生产访问权限）以提升发送限额并允许向外部地址发信；② 手动更新 DNS TXT 记录以验证域名所有权（Terraform 难以处理多账号共享域名时对同一 TXT 记录值的追加操作）。未来计划：引入收件人地址限制和凭证滚动更新增强安全功能。与 [[ctp-topic-36-sendgrid-as-an-email-service]] 构成云邮件服务双路径——SendGrid 面向新标准，SES 服务现有应用平滑迁移。属 [[Infrastructure-as-Code]] 在邮件服务场景的实践，与 [[VPC-Endpoint]]、[[Secrets-Manager]] 概念关联。 - -**[[ctp-topic-21-supply-chain-security-in-micro-focus]]**（CTP Topic 21）： - -**[[ctp-topic-24-micro-focus-product-privacy-framework]]**（CTP Topic 24）：Micro Focus 产品隐私框架在云转型中的应用——PSAC（产品安全顾问委员会）与法律顾问合作，将 GDPR/CCPA 等晦涩法律条款翻译为约 110 项低级别技术要求；隐私框架是 STLC（安全开发生命周期）中 13 个安全与隐私轨道之一；通过五类需求（架构类/文档类/法律类/实现类/SAS 运营类）和成熟度模型（0-4 级）评估产品隐私合规状态；通过"蜘蛛图"直观展示产品在安全去标识化、被遗忘权、数据可移植性等 KPI 上的合规现状；最终产出标准化《产品隐私设置文档》，确保客户获得一致的隐私信息参考。属 [[Product Privacy Framework（产品隐私框架）]] 在 [[Micro Focus]] 云转型场景的核心实践，与 [[Micro Focus Security Development Life Cycle (STLC) Overview]]（STLC 整体架构）直接关联。 - -**[[ctp-topic-49-container-lifecycle-hardening-standards]]**（CTP Topic 49）： - -**[[public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w]]**（Public Cloud Learning Sessions，EKS 计算优化专题 Part 2）：Bottlerocket OS（火箭瓶）深度解析——AWS 专为容器工作负载优化的最小化开源 Linux 发行版，核心设计理念：最小化（去除包管理器/Shell/SSH，仅打包必要内核组件）、安全更新（分区镜像 A/B 切换确保原子性）、安全加固（dm-verity 根文件系统加密验证 + SE Linux enforcing 模式 + 根文件系统默认只读）。Variant 机制通过平台+架构+工作负载组件组合在构建时定制功能，支持 Bottlerocket for EKS AMI（自管理节点组）、托管节点组（Managed Node Groups）和 Carpenter 节点池三种集成方式。属 [[Bottlerocket]] 在 [[Amazon EKS]] 场景的核心实践，与 Part 1（Karpenter 计算优化）和 Part 3（EKS Auto Mode）共同构成 EKS 优化三专题完整链路；Part 3 的 EKS Auto Mode 默认使用 Bottlerocket 作为节点操作系统。 - -**[[ctp-topic-67-cloud-native-observability-using-opentelemetry]]**（CTP Topic 67）：AWS 解决方案架构师 Surav 分享的 EKS/ECS 云原生可观测性深度实践——核心主题：可观测性三信号模型（Traces/Metrics/Logs）、OpenTelemetry Collector 架构（Receivers → Processors → Exporters）、ADOT（AWS Distro for OpenTelemetry）的多种 EKS/ECS 部署模式（Sidecar/独立任务/DaemonSet/HA Replicas）。核心观点：**构建可观测的应用是开发者的责任**——开发者需主动在代码中植入观测能力；Trace 捕获应用调用栈各层的处理耗时，是性能瓶颈定位的核心手段；Correlation ID（如 X-Ray Trace ID）使日志事件可深度链接至 Trace 视图。ADOT 在标准 OTEL Collector 基础上封装 AWS 专用组件，包含 SIGV4 Auth Extension 实现 AWS 服务无缝集成，支持 CloudWatch/X-Ray/Prometheus/Grafana 等多种后端。与 [[public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113]]（Jay Comer 概述版）同属 OpenTelemetry 专题，属 Surav 主讲的深度实践版；与 [[ctp-topic-42-grafana-observability-dashboard]]（Grafana 仪表盘）互补，后者为 ADOT 推荐的可视化后端；与 [[ctp-topic-54-esm-saas-log-analytics]]（ELK 日志方案）共同构成企业级可观测性知识体系。 - -**[[public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113]]**（Public Cloud Learning Sessions，Jay Comer 主讲）：AWS OpenTelemetry 可观测性全景介绍——涵盖可观测性定义（通过外部输出推断内部状态）、三信号模型（Metrics/Logs/Traces）、OpenTelemetry 核心架构（OTLP 协议 + 11 种语言 SDK + Collector 组件）、AWS Distribution for OpenTelemetry（统一代理 + EKS Operator 自动注入）、最新发布动态（安全合规/规模化/集中管理面板/日志支持）。Demo 展示 EKS 环境完整链路：Fluent Bit 采集容器日志 → OpenTelemetry Collector（端口 55681）→ Amazon OpenSearch Service，OpenSearch Dashboard 可按 trace group 展示延迟并通过应用组成图定位性能瓶颈。属 [[OpenTelemetry]] 在 AWS EKS 场景的核心实践，与 [[ctp-topic-67-cloud-native-observability-using-opentelemetry]]（CTP Topic 67）同属 OpenTelemetry 专题，与 [[ctp-topic-54-esm-saas-log-analytics]]（ELK 日志方案）共同构成企业级可观测性知识体系。 - -**[[public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks]]**（Public Cloud Learning Sessions，EKS Auto Mode 专题）：AWS EKS Auto Mode 深度解析——将数据平面管理责任从用户扩展至 AWS，覆盖计算节点（Carpenter Controller）、存储（EBS CSI Controller）、网络（AWS LB Controller）和安全（Pod Identity Associations）。Bottlerocket OS 提供最小化安全容器操作系统，自动应用安全补丁；Carpenter Controller 监听控制面版本变更，自动触发节点 AMI 滚动升级；Pod Identity Associations 替代 K8s RBAC 实现 Pod 级 IAM 权限控制，无需修改 ServiceAccount；Prefix Delegation 默认启用优化 Pod 网络 IP 分配。默认两个节点池（General Purpose 锁定 AMD64，System 带 taint），支持自定义节点池指定 Graviton。Auto Mode 兼容所有 Kubernetes-compliant 工作负载，实例附加 12% 管理溢价。属 EKS 运维简化的核心实践，与 [[ctp-topic-59-achieving-reliability-with-amazon-eks]]（EKS 可靠性）、[[ctp-topic-64-scaling-out-with-amazon-eks]]（EKS 扩缩容）共同构成 EKS 完整知识链路。 - -**[[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]]**（CTP Topic 39）：EKS 在受限 Lab Landing Zone 网络环境下的技术实施方案——Spencer 和 Guy 分享。核心问题：Micro Focus 网络的 AWS Lab 环境 IP 地址池不足，无法满足 Octane（IP 密集型 SaaS 应用）的 EKS Pod 需求。解决方案：创建独立私有子网（非主 VPC 子网），由 EKS 模块自定义网络标志控制 Pod IP 分配；Pod 规范设置 `hostNetwork: true` 使其同时访问内部 Micro Focus 网络和外部资源；Terraform/Terragrunt 模块封装完整 EKS 部署逻辑，支持跨账户角色映射。Atlantis 当前不支持 EKS 部署，需通过 Jenkins + Terragrunt 模块替代。属 [[Amazon EKS]] 在受限网络场景下的技术实践，与 [[ctp-topic-70-eks-deployment-using-iac]]（IaC 部署）共同构成 EKS 完整知识链路。 - -**[[ctp-topic-70-eks-deployment-using-iac]]**（CTP Topic 70）：EKS 集群通过 IaC 部署的完整方法论——涵盖容器与 VM 的对比（启动速度/内存效率/可移植性）、EKS 核心特性（完全托管控制平面/零停机滚动更新/IAM RBAC 最小权限）。SRE EKS 模块支持两种部署路径：Terraform（`tera-grant.scl` 定义集群参数+Secret Manager 集成）和 Service Catalog（模块化产品组合+版本选择）。自定义网络通过 EMI（ENI Multi-IP）为 Pod 分配额外 IP 地址解决 VPC CIDR 限制；Cluster Autoscaler 实现 Worker Node 自动扩缩容。监控栈：CloudWatch Agent + FluentBit（DaemonSet）+ Container Insights + AWS OpenTelemetry + Grafana。属 [[Amazon EKS]] 部署方法的完整入口，与 [[ctp-topic-59-achieving-reliability-with-amazon-eks]]（可靠性）、[[ctp-topic-64-scaling-out-with-amazon-eks]]（扩缩容）、[[public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks]]（Auto Mode）共同构成 EKS 完整知识链路。 - -**[[ctp-topic-59-achieving-reliability-with-amazon-eks]]**（CTP Topic 59）：Amazon EKS 可靠性最佳实践——AWS 高级解决方案架构师 Surav Paul 主讲。涵盖 EKS 容器服务选型（ECS vs EKS）、可靠性定义（可预测行为、故障检测、优雅降级、自愈、按需扩缩）、shared responsibility model（AWS 负责控制平面，客户负责工作节点/OS/应用配置，Fargate 模式下客户无需管理节点）、应用层可靠性（避免单例 Pod、AZ 分散、拓扑分布约束、HPA/VPA 扩缩容、Rolling/Blue-Green/Canary 部署、存活/就绪/启动探针、PodDisruptionBudget）、控制平面可靠性（监控 API server 指标、安全认证加固、准入 Webhook 管理、集群升级 14 个月支持周期）和数据平面可靠性（节点问题检测、资源预留、QoS、资源配额、Pod 优先级抢占）。属 [[Amazon EKS]] 生产级可靠性保障的核心知识来源，与 [[ctp-topic-70-eks-deployment-using-iac]]（IaC 部署）和 [[ctp-topic-64-scaling-out-with-amazon-eks]]（扩缩容）共同构成 EKS 完整知识链路。 - -**[[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]]**（CTP Topic 4）：云转型计划中敏捷实践的落地经验——Heather Norris 主讲。核心内容：①框架演进——从 Scrum（两周 Sprint，含 Product Backlog/Sprint Planning/Retrospectives/Reviews/Daily Scrum）因"Sprint 期间不允许变更"的问题而转向 Kanban 持续流动模式；②混合方案——以 Kanban 为主（随时可调整优先级、持续交付），同时保留 Scrum 的固定仪式（每日站会和回顾会议）；③Microsoft Planner 看板——五列布局（Backlog/To Do/In Progress/Program Key Decisions/Icebox），每张卡必须指定单一负责人、链接依赖、设置优先级和截止日期；④核心价值观——"Agile is all about getting that rapid feedback to make the product and make the development culture better"。属 [[Agile Ceremonies]] 和 [[Scrum]] vs [[Kanban]] 在企业级云迁移场景下的实战案例，与 [[ctp-topic-57-product-backlog-managing-demand]]（需求管理）和 [[ctp-topic-30-managing-change]]（变更管理）共同构成 CTP 项目管理知识体系。 - -**[[public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109]]**（Public Cloud Learning Sessions 20240109）：业务分析（Business Analysis）基础技能与三大核心技法——T型技能模型、BOSCARD框架、干系人轮盘（Stakeholder Wheel）、结合元数据的用户故事需求收集。业务分析将业务需求与技术变更解决方案对齐，涵盖IT系统变更、流程变更、培训和角色转换。BOSCARD（Background/Objectives/Scope/Constraints/Assumptions/Risks/Roles/Deliverables）通过澄清背景、目标、范围等8个维度定义复杂新工作，"早期锁定范围无价"。干系人轮盘从客户出发顺时针识别所有项目干系人。INVEST原则（Independent/Negotiable/Valuable/Estimable/Small/Testable）用于检查需求质量。属 [[Product-Backlog]] 和 [[Demand-Management]] 的前置技法层，与 [[ctp-topic-4]]（敏捷实践）和 [[ctp-topic-57]]（需求管理）共同构成云转型计划的完整方法论（规划→需求→执行）。 - -**[[ctp-topic-18-wide-area-networking-in-aws-cloud]]**（CTP Topic 18）：AWS 广域网架构设计——Micro Focus IT 网络架构师 Christian Deckelman 主讲。核心架构：全球划分为 APJ/EMEA/AMS 三个地理区域，每个区域设立 Hub（如 EMEA 伦敦、AMS 俄勒冈），所有 Landing Zones 通过 TGW Peering 以星型拓扑接入区域 Hub，区域 Hub 之间全网状互联。现阶段 TGW 间路由依赖静态前缀列表，缺乏 BGP 动态路由，DR 场景需人工干预。演进路线：引入 Silver Peak SD-WAN 作为叠加网络实现动态路径选择；Pulse VPN 迁移至 Palo Alto Prisma Access (SASE) 实现就近接入并打通 SD-WAN 骨干。属 [[AWS-Transit-Gateway]] 架构实践，与 [[ctp-topic-25-labs-landing-zone-overview-itom-teams]]（Labs LZ 网络）和 [[ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]]（网络分段）共同构成 Landing Zone 网络知识体系。 - -**[[ctp-topic-25-labs-landing-zone-overview-itom-teams]]**（CTP Topic 25）：Labs Landing Zone 运维团队视角——Labs LZ 基于 Gruntwork 参考架构，采用多账户策略，全部资源通过 Terraform/Terragrunt 管理（Jenkins 流水线扫描 GitHub 仓库变更触发 plan/apply）；核心账户包括：Shared（托管 Jenkins 主节点和加固 AMI）、Logs（CloudTrail/Config 日志集中存储）、Security（联邦用户和跨账户访问）、Core（AD 管理 Windows 实例和 IDP、DNS 管理 Swimford.net）、Network（Transit Gateway + JetPult 防火墙管理所有互联网流量，Pulse VPN 提供 Micro Focus 网络访问）、Shared Services（45 Arc Site 监控、Qualys 漏洞扫描）。Product Account 通过 Terraform 模块部署 subnet，需与网络团队协调 IP 范围和标签策略，防火墙通过标签自动配置网络访问策略。属 [[AWS-Landing-Zone]] Labs 视角的运维实践，与 [[ctp-topic-1-gruntwork-landing-zone-architecture]]（架构基础）和 [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]]（SaaS vs Labs 职责划分）共同构成完整的 AWS Landing Zone 知识体系。 - -**[[ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]]**（CTP Topic 31）：AWS Landing Zone 网络隔离与安全远程访问方案——解决 On-prem 系统和 VPN 用户因共享网络配置而可直接访问生产工作负载的安全风险。核心方案：①网络隔离通过 Checkpoint 防火墙启用 SPI 特性（default-deny），阻断内部网络对 AWS 网段的直接连通；②安全访问通过 AWS Systems Manager (SSM) 替代 VPN，用户假设 IAM 角色访问目标 EC2 实例上的 SSM Agent，支持浏览器会话和 AWS CLI 两种模式，提供双因素认证和 AWS 网络内安全连接。定位为 SD-WAN 实施前的过渡方案；长期演进目标为 IaC 化以消除控制台访问，break-glass 访问仅保留用于紧急场景。与 [[ctp-topic-18-wide-area-networking-in-aws-cloud]]（广域网架构）互补——后者关注如何打通网络，Topic 31 关注如何限制网络访问；两者共同构成 Landing Zone 网络知识体系。属 [[AWS-Landing-Zone]] 网络安全层的核心实践。 - -**[[ctp-topic-8-obm-cloud-monitoring]]**（CTP Topic 8）：使用 Micro Focus Operations Bridge Manager (OBM) 实现 AWS 公有云监控的完整解决方案——OBM AWS Account 部署 OBM 应用、Postgres RDS 和 Operation Agent 三层组件；Agent 通过 AWS Management Pack 利用 IAM Role 信任关系跨账户采集 CloudWatch 指标，无需在被监控账户安装服务器或共享 Access Key；Global OBM 作为 Manager of Managers 汇聚多区域 Regional OBM 数据，事件通过 SMACKS 触发工单；新增实例自动发现、策略自动下发，解决云环境动态性监控难题；支持任意公有云（AWS/Azure/GCP）的 CloudWatch 兼容服务。与 [[ctp-topic-29-cloud-monitoring-saas-lz-accounts]]（账户架构）互补构成完整监控体系，属 [[AWS-Landing-Zone]] 监控层的核心实践。 - -**[[ctp-topic-54-esm-saas-log-analytics]]**（CTP Topic 54）：ITOM ESM SAS 架构师 Jackie 主讲的企业级日志分析解决方案（ESM SaaS）——涵盖 ELK/OpenSearch 技术栈架构（BEATS 采集 → Logstash 处理 → Elasticsearch/OpenSearch 存储 → Kibana 可视化）、双 VPC 隔离架构（应用 VPC + 日志 VPC）、Redis 缓冲层防止 Logstash 过载。安全加固涵盖静态加密（NVMe 硬件级）、传输加密（TLS 1.2）、VPC 私有流量和 RBAC 访问控制；GDPR 合规要求推动日志农场按区域分割部署（美国俄勒冈、欧洲）。方案对比：AWS OpenSearch（~$1,500/月，SLA 99.9%，推荐）、Logz.io（~$4,000/月，SLA 99.8%）、自托管 ELK（成本低维护高）、Microfocus OBA（商业成熟，列级访问控制）。起步建议先用 Logz.io 试用，再迁移 AWS OpenSearch。与 [[ctp-topic-8-obm-cloud-monitoring]] 同属企业监控体系，Topic 8 聚焦指标监控，Topic 54 聚焦日志分析，共同构成完整可观测性视图。 - -**[[ctp-topic-42-grafana-observability-dashboard]]**（CTP Topic 42）：企业级 Grafana 可观测性平台在 AWS 多账户环境下的架构设计与 Terraform IaC 自动化实践——涵盖 Grafana 核心定位（不存储数据，仅从数据源可视化）、基础设施架构（监控账户部署 Grafana，通过 IAM 角色跨账户访问产品团队 AWS 账户）、用户和团队访问控制（Editor/Viewer/Admin 角色）、示例仪表盘（CPU/I/O/Network/EBS/Estimated Charges）、告警系统（Microsoft Teams 通知）、Terraform 模块化供给（数据源模块 + 组织模块 + LZSAP 自动化接入）、Prometheus 网络监控（Checkpoint/防火墙 SNMP 指标）。与 [[ctp-topic-54-esm-saas-log-analytics]]（日志分析）同属可观测性专题，共同构成监控知识体系；长期目标是构建应用级仪表盘替代 [[Micro Focus Operations Bridge Manager]]。 - -**[[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]]**（CTP Topic 35）：AWS Landing Zone 设计复习——重点明确 SaaS（生产）与 Labs（开发）的职责划分。SaaS Landing Zone 为每个产品区域提供客户专属环境，产品账户连接至共享服务账户（安全、日志、网络）；核心账户组包含 AD、DNS 和 Network 账户；Gruntwork 账户跨所有账户管理 AMI、日志和安全。近期变更：网络分段阻断对 SaaS 工作负载的直接连通性；CCOEs CloudTrail 取代 Gruntworks CloudTrail 实现统一审计；入站流量拟通过 Network 账户 Checkpoint 重新路由；原生 AWS Backup 有望强制化；新账户可能取消 Management VPC。核心结论：**SaaS = 生产，Labs = 开发**；PoC Landing Zone 将并入 Labs 以最大化资源共享；Cloud Technology Design Forum 推动 Micro Focus 云交付标准化。 - -**[[ctp-topic-6-aws-workspaces-demo]]**（CTP Topic 6）：AWS Workspaces 虚拟桌面解决方案实操演示——通过 AWS Workspaces 为云转型团队提供托管 Windows 虚拟桌面（Windows Server 2016），预装 PFSSO、Terraform、TerraGrunt、Git 和 VS Code。用户通过邮件联系 Naga 申请账号，接收注册码和用户名后登录，可立即访问 AWS Console（Federation）和 GitHub Enterprise 并生成 SSH 密钥。演示全程约 21 分钟完成仓库克隆、PFSSO 认证和 TerraGrunt Plan 执行，达成"申请后 45 分钟内运行 Terraform"的目标。未来计划与 Active Directory 集成实现自动化账号管理。属 [[AWS-Landing-Zone]] 用户端工具层的核心实践，与 [[ctp-topic-1-gruntwork-landing-zone-architecture]]（基础架构）和 [[ctp-topic-9-ci-cd-with-gruntwork]]（CI/CD 流程）共同构成完整的"架构→交付→使用"链路。 - -**[[public-cloud-learning-sessions-aws-end-user-compute-services-20240430]]**（Public Cloud Learning Sessions，Christian O'Donough 主讲）：AWS 终端用户计算（EUC）服务全景介绍——覆盖四大服务：① **Workspaces**（全持久虚拟桌面，适合知识工作者一对一实例管理）；② **AppStream 2.0**（选择持久/非持久应用流，多租户模式降低成本，适合实验室/培训/堡垒主机）；③ **Workspace Core**（提供 VDI 基础设施 API，支持 Horizon View、Citrix 等第三方集成）；④ **Workspace Web**（低成本安全浏览器）。核心选型原则：需要完整桌面 → Workspaces；非持久桌面/应用流 → AppStream 2.0；第三方 VDI → Workspace Core；安全浏览 → Workspace Web。安全措施包括 Active Directory 集成、加密、IAM 配置文件、SAML 认证和多因素认证。属 [[AWS-Landing-Zone]] 用户端计算层的理论基础，与 [[ctp-topic-6-aws-workspaces-demo]]（实操演示）共同构成完整的 EUC 知识体系。 - -**[[ctp-topic-7-saas-landing-zone-design]]**（CTP Topic 7）：SAS 生产 Landing Zone 顶层架构设计——定义了完整的四层账户体系：①核心账户（Core Accounts）：Shared 托管 AMI + 主 Jenkins 服务器通过 Lambda 触发各账户 Jenkins slave；Logs 集中管理所有账户日志（CloudTrail/Config/Flowlogs）；Security 托管 IAM 角色。②基线账户（Baseline Accounts）：Network 账户部署区域级 Transit Gateway + Checkpoint Appliance 按标签监控跨账户流量；DNS 账户托管 Route 53，各产品拥有独立托管区；Active Directory 账户提供双 AD 节点实现域加入和资源访问控制。③共享服务账户（Shared Services Accounts）：Software Factory（45 个 hub + Octane Hub + Artifactory）、Cyber（Qalis）、ARC Site、Monitoring（OBM/Sitescope）。④产品账户（Product Accounts）：工作负载置于私有子网，公有子网通过负载均衡器和互联网网关对外暴露，WAF 监控入站流量。自动化部署链路：GitHub 仓库变更 → Jenkins（GitHub Hook 触发）→ Management VPC → Lambda → ECS Cluster，Staging 测试后才部署生产。远程访问从 Checkpoint VPN 迁移至 Pulse VPN（通过 AD 认证）。属 [[AWS-Landing-Zone]] 的原始设计规范，与 [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]]（近期变更）共同构成 SAS LZ 的设计演进脉络。 - -**[[ctp-topic-1-gruntwork-landing-zone-architecture]]**（CTP Topic 1）：Gruntwork AWS Landing Zone 架构基础——核心概念：参考架构（Reference Architecture）是包含核心账户 Shared/Logs/Security 和工作负载账户 Prod/Stage/Dev 的最佳实践起点；Landing Zone 基于 Gruntwork 仓库但由产品团队自行定义具体服务；安全账户使用联邦用户（Federated User），通过 AD 组映射到 IAM 角色；每个 Landing Zone 配置独立 Jenkins 服务器和特性分支 Git 工作流。属整个 CTP Landing Zone 系列的基础入门篇。 - -**[[learning-sessions-standard-amis-updates]]**（Learning Sessions 20231205）：AWS 标准 AMI 更新机制与生命周期管理——Jenkins 多分支流水线构建测试 AMI，验证周期从 3-4 天缩短至 60 分钟；支持 23 种 AMI 涵盖 Amazon Linux/CentOS/RHEL/Rocky Linux/SUSE/Ubuntu/Windows；CentOS 7/RHEL 7 将于 2024 年 6 月 EOL，由 Rocky Linux 替代；机器人框架自动化验证是该优化流程的核心。属 [[AWS-Landing-Zone]] AMI 管理层的实践补充。 - -**[[ctp-topic-50-ami-roadmap-for-aws-amis]]**（CTP Topic 50）：CCOE AMI 路线图详解——涵盖 CCOE AMI 路线图规划、操作系统 EOL 时间线（Windows Server 2008/2008 R2 已 EOL；CentOS 8 已 EOL；Windows Server 2012 将于 2023 年 10 月 EOL；RHEL 7 和 CentOS 7 将于 2024 年 6 月 EOL）、AMI 通知机制、变更日志（CCRE 门户）、新 AMI 添加流程（服务集成→功能启用→构建测试）、当前支持的 AMI 清单及未来路线图（SLES 15/RHEL 9 2022年11月；openSUSE 15/Amazon Linux 2022 2023年1月；Rocky 8/9 2023年3月；RHEL 9.4 ARM/Ubuntu 22.04 ARM 2023年5月）。自 2023 年 5 月起所有 ARM AMI 同步发布。路线图优先级主要由 ADM 需求驱动，变更需通过需求管道流程提交。AMI 通过跨账号共享分发给组织内所有账户。属 [[AWS-Landing-Zone]] AMI 层的路线图补充，与 [[ctp-topic-26-standard-ami-build-publish-share-processes]]（生命周期管理）和 [[ctp-topic-58-aws-ec2-image-builder]]（未来演进方向 EC2 Image Builder）共同构成完整的 AMI 管理知识体系。 - -**[[ctp-topic-26-standard-ami-build-publish-share-processes]]**（CTP Topic 26）：Foundation AMI 全生命周期管理详解——Srihari、Alan 和 Praveen 三位专家主讲。Foundation AMI 基于市场主流 OS（CentOS/Ubuntu/Windows）进行 CIS 安全基准加固，集成 McAfee EPO 防病毒 + Syslog-ng 日志管理 + AD 单点登录 + SSM Agent + SiteScope 监控；使用 HashiCorp Packer + Jenkins 流水线实现镜像创建完全自动化；通过跨账号共享（AMI Sharing）分发至全球多区域（俄勒冈/法兰克福/悉尼），而非物理复制（AMI Copying），避免额外存储成本；每两个月更新，采用 N-2 版本保留策略。责任共担模型：CCOE 提供安全基础镜像，产品团队在其上构建产品特定 AMI。属 [[AWS-Landing-Zone]] AMI 层的核心基础，与 [[ctp-topic-58-aws-ec2-image-builder]]（演进方向 EC2 Image Builder）和 [[learning-sessions-standard-amis-updates]]（2023年更新机制）共同构成完整的 AMI 管理知识体系。 - -**[[ctp-topic-55-aws-firewall-manager]]**（CTP Topic 55）：AWS Firewall Manager 在 Grand Torque 多 Landing Zone 环境中的集中化安全策略管理实践——核心动机：跨 RLABS/R&D/SAS/CAT 多个 Landing Zone 管理安全策略的复杂性；原有 Checkpoint Firewall 无法完全覆盖公网子网流量安全。核心方案：①在独立的 Firewall Manager 账户创建安全组策略，指定目标账户或 OU，自动将基线安全组附加到现有和新实例；②三种策略类型——通用安全组（允许产品团队自增）、审计与强制安全组规则（拒绝过度宽松规则，支持手动或自动修复）、清理未使用冗余安全组；③通过 RAM 前缀列表跨账户共享规则，支持 Atlantis CI/CD 流水线部署。Demo 演示了策略创建后 EC2 实例的自动附加与策略删除后的自动移除。前提条件：OU 内管理员权限 + AWS Config 全账户启用。属 [[AWS-Landing-Zone]] 安全策略集中化管理层的核心实践，与 [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]]（Checkpoint 防火墙）互补——后者提供网络边界防火墙，前者提供实例级别安全组基线。| - -**CTP Topic 10**（[[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]]）：AWS Landing Zone 部署、数据收集策略与基于标签的云原生安全架构——Steve Jarman 和 Pradeep 主讲。核心内容：①Landing Zone 部署前必须深入了解 BU 资产清单、IP 地址空间及数据敏感性；②DNS、Transit Gateway 等基础服务已通过 SRE 团队实现高度自动化；③**基于标签的安全控制机制**——传统基于 IP 的防火墙规则无法适应云环境动态性，转向利用 AWS 标签作为安全凭证；④**SCP 强制执行标签规范**——通过「显式拒绝」逻辑防止用户通过篡改标签绕过审计，确保资源创建时即具备正确的 BU/产品/环境归属；⑤**Checkpoint 防火墙有序层逻辑**——按优先级执行地理屏蔽 → BU 隔离 → 产品隔离 → 环境隔离，实现跨 VPC/On-prem/互联网的精细化流量控制；⑥Inline 层基于账号号的父子规则架构，简化跨账户策略管理。与 [[ctp-topic-1-gruntwork-landing-zone-architecture]] 的安全层扩展，与 [[ctp-topic-28-aws-tag-validation-tool]]（标签审计）共同构成标签治理闭环。 - -**[[ctp-topic-45-automatic-ip-address-allocation-with-ipam]]**（CTP Topic 45）：Infoblox NIOS IPAM 自动分配 AWS VPC IP 地址——通过 YAML 配置文件声明期望子网大小和区域父 CIDR，NIOS 自动分配下一个可用 IP 地址块（≤/24 自动，>/24 需审批）；销毁 VPC 时自动从 IPAM Grid 清除条目；建立单一可信数据源，消除手工电子表格记录。属 [[IPAM（IP Address Management）]] 的机制层详解。 - -**[[ctp-topic-61-workload-vpc-provision-with-ipam-automation]]**（CTP Topic 61）：Workload VPC 完整自动化供给方案——Pushka（Principal SRE）主讲，在 Topic 45 的 IPAM 自动分配机制基础上，展示了端到端 VPC 供给流程。核心增强：多 VPC 批量供给支持、邮件通知机制、CIDR /22 阈值自动审批（更大 CIDR 自动，更小需理由审批）、非路由 IP 地址（如 10.2.0.0/16）支持、使用 AZ ID 避免跨账号不一致。Infoblox Grid 作为全局唯一 IP 地址数据源防止重叠，架构包含休斯顿数据中心主库及冗余 DNS/NTP/DHCP 服务。核心理念：**"只需把信息放到正确位置，一切自动完成。"** 属 [[IPAM（IP Address Management）]] 的应用层扩展，与 [[ctp-topic-45-automatic-ip-address-allocation-with-ipam]] 共同构成 IPAM 的"机制 → 应用"完整链路。 - -Key concepts: [[Process]], [[Value]], [[Value-Stream]], [[Value-Adding]], [[Waste]], [[Benefits-Quantification]], [[Cost-of-Delay]], [[WSJF]], [[SOM]], [[Feature-Level-Value-Breakdown]], [[Program-Demand-Process]], [[Proof-of-Concept]], [[Gate-Process]], [[Solution-Design]], [[Landing Zone Architecture]], [[Product-Backlog]], [[Demand-Management]], [[SMACs]], [[Prerequisite-Phase]], [[Hyper-Care]], [[Octane]], [[Hybrid DNS Resolution]], [[VMware-Cloud-on-AWS]], [[VMware]], [[HCX]], [[SDDC]], [[Stretched-Cluster]], [[Hybrid-Cloud]], [[Multi-Cloud Strategy]], [[Multi-Cloud-ROI]], [[DevOps Culture]], [[CI/CD Pipeline]], [[DevSecOps]], [[Shift-Left-Security]], [[Shift-Right-Security]], [[SAST]], [[DAST]], [[IAST]], [[SCA]], [[Break-the-Build]], [[Agile Practices]], [[DevOps Maturity]], [[DORA Metrics]], [[Infrastructure as Code]], [[Cloud-Native]], [[Cloud Maturity Levels]], [[Cloud Adoption Strategy]], [[Cloud Service Delivery]], [[Cloud DevOps Maturity Model]], [[Cloud Operating Model]], [[Cloud Governance]], [[Cloud Cost Optimization]], [[Serverless Computing]], [[Edge Computing]], [[Green Computing]], [[Data-Warehouse]], [[MPP]], [[Columnar-Storage]], [[Sort-Key]], [[Distribution-Key]], [[Vendor-Lock-In]], [[Data-Sovereignty]], [[NFR（非功能需求）]], [[Error Budget（错误预算）]], [[Chaos Engineering]], [[Product Privacy Framework（产品隐私框架）]], [[STLC（Security Development Life Cycle）]], [[PSAC（Product Security Advisory Committee）]], [[PII（Personally Identifiable Information）]], [[Maturity Model（成熟度模型）]], [[Spider Chart（蜘蛛图）]], [[Product Privacy Settings Document]], [[Data Controller vs. Data Processor]], [[Anonymization & Pseudonymization]], [[被遗忘权]], [[数据可移植性]], [[高可用（High Availability）]], [[灾难恢复架构模式]], [[Vault Lock]], [[ELK Stack]], [[OpenSearch]], [[Logstash]], [[Kibana]], [[BEATS]], [[Filebeat]], [[OpenTelemetry]], [[Fluent Bit]], [[Observability（可观测性）]], [[OTLP（OpenTelemetry Protocol）]], [[Three Signals]], [[Centralized-Logging]], [[Redis缓存]], [[RBAC]], [[TLS]], [[API-Key-Rotation]], [[跨账户备份]], [[增量备份]], [[SPF]], [[DKIM]], [[TLS]], [[API-Key-Rotation]], [[Cyber-Suite]], [[CBC-Mode]], [[SendGrid]], [[Twilio]] vs [[全量备份]]（CTP Topic 72：增量仅捕获变更，节省存储成本）、**[[AWS Backup Audit Manager]]**（BAM，CTP Topic 72：合规审计报告）、**[[AWS-Tagging-Standards]]**（CTP Topic 28：AWS 标签规范，涵盖命名约定、强制标签键、成本标签策略；与 Checkpoint 防火墙安全策略直接关联，标签缺失导致流量拦截）、**[[Tag-Validation-Tool]]**（CTP Topic 28：SRE 团队开发的 Python/Boto3 工具，通过 YAML 配置扫描 AWS 资源标签合规性）、**[[Service-Control-Policies-SCPs]]**（AWS Organizations 策略类型，通过「显式拒绝」逻辑强制执行标签规范）、**[[OU-Layered-Security]]**（通过组织单元分层结构检查标签确保正确归属）、**[[Tag-Based-Security]]**（将资源标签作为安全凭证替代传统 IP 规则）、**[[Checkpoint-Firewall]]**（防火墙供应商，依赖 AWS 标签值配置网络访问策略）、**[[Variables-YAML]]**（Tag Validation Tool 核心配置文件，定义每个账户的合法标签键及允许值）、**[[SRE-Tools-Repository]]**（内部代码仓库，存放 Tag Validation Tool 等 SRE 自动化脚本）：[[WAF]], [[APM]], [[Cloud Security]], [[Cloud Migration]], [[High Availability]], [[Pay-as-you-go]], [[Failover]], [[Multi-factor-Authentication]], [[Data-Governance]], [[Continuous Integration]], [[Continuous Deployment]], [[Lead Time]], [[Time-to-Market]], [[MTTR]], [[MTTD]], [[MTTA]], [[Change Failure Rate]], [[Error Budget]], [[Rollback Rate]], [[Availability]], [[Scalability]], **[[Agentic AI]]**, [[Root Cause Analysis (RCA)]], [[Predictive Maintenance]], [[Deployment Automation]], [[Rightsizing]], [[Automated Security Audit]], [[AI ChatOps]], [[What-If Simulation]], **[[RTO]]**, **[[RPO]]**, **[[Feature Flag]]**, **[[Kill Switch]]**, **[[Progressive Rollout]]**, **[[Micro-Recovery]]**, **[[Deployment-vs-Release]]**, **[[Business Impact Analysis]]**, **[[Public Cloud]]**, **[[Private Cloud]]**, **[[Hybrid Cloud]]**, **[[Shared Responsibility Model]]**, [[Multi-Tenancy]], [[Intentional Cloud Strategy]], **[[Centralized Logging]]**, **[[Cross-Account Monitoring]]**, **[[Multi-Account Deployment]]**, **[[StackSets Deployment Visibility]]**, [[CMDB]], [[Problem-Management]], [[Release-Management]], [[Configuration-Management]], [[Asset-Management]], [[Security-and-Compliance]], [[DRaaS]], [[Canary-Release]], [[Blue-Green-Deployment]], [[Threat Modeling]], [[OWASP-Top-Ten]], [[Bug-Bounty]], [[Vulnerability-Scanning]], [[Penetration-Testing]], [[Compliance-Automation]] - -**[[ctp-topic-40-saas-database-architecture]]**（CTP Topic 40）：SAS 数据库团队在 AWS 云上的架构与运维实践——团队分布于美国/加拿大/印度/以色列，管理 500+ 数据库和 1000+ DB 服务器；支持 Oracle、Vertica、Postgres、DynamoDB、SQL Server、MongoDB、MySQL 等多引擎；高可用架构采用三可用区模式（主库/备用库/见证节点）；使用 Oracle Data Guard、Postgres Active-Passive/Active-Active、RDS HA 实现多活；通过 Terraform、AWS CLI、Shell/PowerShell 实现 IaC 自动化；Oracle GoldenGate 支持零停机迁移。属 [[AWS-Landing-Zone]] 数据库层的核心实践，与 [[ctp-topic-51-purpose-built-databases]]（数据库品类全景）和 [[ctp-topic-66-rds-vs-aurora]]（关系型选型）共同构成完整的 AWS 数据库知识体系。 - -**[[ctp-topic-43-vmware-cloud-on-aws]]**（CTP Topic 43）：VMware Cloud on AWS 混合云服务介绍——VMware 与 AWS 联合开发，在 AWS 裸金属服务器（i3.metal/i3en.metal）上原生安装 vSphere 8，为不完全准备完全迁移至原生云的企业提供中间路线。工作负载可在数秒内往返迁移于本地与云端之间，通过 HCX 实现 any-to-any vSphere 迁移。Brian Reeves 讨论经济学效益：相比常规云方案节省 27% 成本，云经济学团队可提供 TCO 计算。Mike O'Reilly（VMware Staff Cloud Solutions Architect）强调这是真正的联合工程而非简单地将 VMware 软件部署到云端。支持 SDDC 部署，通过 vCenter 管理，支持跨可用区的 Stretched Cluster 高可用架构。属 [[Hybrid-Cloud]] 在 AWS 落地的核心实践，与 [[ctp-topic-53-why-bother-with-cloud]] 存在是否应迁移至云端的观点张力。 - -**[[ctp-topic-53-why-bother-with-cloud]]**（CTP Topic 53）：云转型商业价值论证——用数据说明"为何要上云"。Micro Focus 拥有全球最大的商业数据中心足迹——14个数据中心、近20,000台资产；尽管年营收25亿美元，但 VMware 足迹比规模大8倍的公司还大，硬件利用率不足40%。三个产品从 Bublikan 迁出后下线575台物理服务器，云端仅需240台虚拟服务器替代；Redding 退出时40%的应用直接关机，Houston 有89个空机架和360台未使用服务器。核心理念：**云迁移不仅是成本节约，更是创新催化剂**——赋能产品增强、改善灾备、开拓新市场。当前55%的 AWS 成本发生在 Landing Zone 之外，亟需治理。属 [[Cloud Transformation Programme]] 的战略论证层，与 [[ctp-topic-43-vmware-cloud-on-aws]]（混合云中间路线）共同构成完整的云迁移决策框架。 - -**[[ctp-topic-69-vmware-vm-migration-best-practices]]**（CTP Topic 69）：VMC on AWS 虚拟机迁移最佳实践——基于 VMware 顾问支持的经验分享。核心内容：①架构——VMware Cloud 托管于 AWS 基础设施，通过 Direct Connect 和 Virtual Transit Gateway 实现与本地数据中心的混合云连接；②HCX 多云管理——每次迭代最多支持 200 台 VM 迁移，支持从 STDC 查看本地 vSphere 环境和反向操作；③两种迁移方法——UI 方式（VMware Cloud 原生）和 CCOE 脚本方案（使用输入文件定义 VM 详情）；④成本原则——"Anything which leaves definitely attracts cost"，数据传输产生费用；⑤后迁移管理——通过 Brown to Manage (BHM) 系统集成 SMACS Suite 和 HCMX 实现虚拟机管理。属 [[VMware-Cloud-on-AWS]] 迁移执行层面的核心补充，与 [[ctp-topic-43-vmware-cloud-on-aws]] 互补构成完整的"概述→迁移执行"知识链路。 - -**[[ctp-topic-46-netapps-on-aws]]**（CTP Topic 46）：NetApp 存储系统 AWS 实践——Sandeep 和 Yael 主讲。覆盖传统 NetApp 架构（ONTAP / Aggregate / FlexVol / Qtree / LUN / LIF / SVM）和 AWS 云版本 Cloud Volume ONTAP (CVO)。CVO 通过 EC2 实例提供软件定义存储，支持单节点或 HA 配对（跨多 AZ 同步复制）；数据分层机制将 30 天非活跃数据从 EBS 自动迁移到 S3；SnapMirror 实现块级跨集群复制；支持的迁移工具包括 SnapMirror、NetApp XCP、Cloud Sync、AWS DataSync。组织已在 15 个 AWS 区域部署约 1.3 PB 数据，使用 Cloud Manager 集中管理，计划引入 FSX for NetApp（POC）和 Terraform 自动化部署。属 [[AWS-Landing-Zone]] 存储层架构的核心补充。 - -**[[ctp-topic-51-purpose-built-databases]]**（CTP Topic 51）：AWS 数据库专家 Femi George 分享专用数据库选型与架构原则——核心思维：现代应用"为正确的工作选择正确的专用数据库"，避免一刀切。AWS 提供完整数据库品类：关系型（RDS、Aurora MySQL/PostgreSQL）、NoSQL 键值（ DynamoDB，日处理万亿请求）、文档（DocumentDB，MongoDB 兼容）、宽列（Keyspaces，Cassandra 兼容）、内存（ElastiCache Redis/Memcached）、图（Neptune）、时序（Timestream）、账本。实战案例：Duolingo 用 DynamoDB + ElastiCache + Aurora 组合；Netflix 用 DynamoDB 做高弹性 JSON 文档；Peloton 用 ElastiCache Redis 提供即时客户反馈。云时代 DBA 职能从底层平台管理转向应用创新（查询优化/架构设计）。属 [[AWS-Landing-Zone]] 数据库层的完整品类指南，与 [[ctp-topic-66-rds-vs-aurora]]（关系型内部选型）互补。 - -**[[ctp-topic-68-introduction-to-redshift]]**（CTP Topic 68）：AWS Redshift 数据仓库基础——Redshift 是完全托管的 PB 级云数据仓库，核心架构包含 Leader Node（管理 Schema、元数据、查询计划）和 Compute Node（通过 Slices 执行 MPP 并行查询）。支持列式存储（适合 OLAP 聚合查询）和行式存储两种模式；Sort Key 和 Distribution Key 是性能优化核心；RA3 实例类型性价比最优，支持 AWS 托管 NVMe 存储。属 [[AWS-Landing-Zone]] 数据库层的核心补充，与 [[ctp-topic-51-purpose-built-databases]]（数据库品类全景）和 [[ctp-topic-66-rds-vs-aurora]]（关系型选型）共同构成完整的 AWS 数据库知识体系。 - -**[[ctp-topic-66-rds-vs-aurora]]**（CTP Topic 66）：PostgreSQL RDS 与 Aurora 深度对比——Greg Klau 主讲。核心维度对比：①最小规格和成本（RDS 更低）；②最大容量和 IO 性能（Aurora 更优，适合 > 10-20 TB）；③RTO（Aurora 30秒 vs RDS 2分钟）；④存储灵活性（RDS 有 GP2/GP3/预置 IOPS/磁性，Aurora 按 IO 收费无上限）；⑤架构（RDS：EC2+EBS 分离，Multi-AZ 备用节点；Aurora：跨 3 AZ 的 6 副本共享集群卷）；⑥Blue-Green 部署（仅 Aurora MySQL 支持）；⑦端点设计（Aurora 独立 Writer/Reader Endpoint）。高可用调优技巧：DNS TTL 设为 1 秒、TCP Keep-Alive 快速检测故障、JDBC 连接串配置 reader/writer 端点路由。属 [[AWS-Landing-Zone]] 数据库选型的核心参考。 - -**[[ctp-topic-14-octane-hub-on-aws]]**（CTP Topic 14）：Octane Hub CTO 实战案例——Docker 容器化工作负载从 Bibling Lab 物理服务器迁移到 AWS Landing Zone。核心技术要点：Packer 构建 AMI + Terraform/TerraGrunt 替代控制台脚本（IaC 演进路径）；EFS 适合备份、EBS 适合实时数据库（存储选型原则）；VPC Transit Gateway 实现多 VPC 互联；"紧密镜像现有设置"作为无缝迁移策略。下一步：DR 改进、MSSQL→Postgres 迁移、ECS 演进。属 [[AWS-Landing-Zone]] 从设计到落地的完整案例补充。 - -**[[ctp-topic-22-global-dns-service-offerings]]**（CTP Topic 22）：企业级全球 DNS 服务架构详解——Sankar 和 Vino 主讲。核心架构：Route 53 Private Hosted Zone（私有托管区域）配合 AD 托管 DNS，通过 Route 53 Resolver 入站/出站终端节点打通 AWS VPC 与本地网络的 DNS 查询；Outbound Endpoint 出站规则配置多个区域 AD 域控制器 IP，单区域故障时自动切换确保弹性。本地 Infoblox 平台利用 DNS Anycast 实现全球低延迟和自动故障转移；AWS EC2 不支持 Anycast，需手动维护 IP 列表。DNS 安全涵盖防隧道攻击、防数据外泄及缓存污染；"就近解析"原则优化 Office 365 等全球化 SaaS 访问性能。属 [[AWS-Landing-Zone]] 网络层 DNS 专题，与 [[ctp-topic-19-configuring-dns-within-aws-lzs]] 共同构成 Landing Zone DNS 知识体系——后者（前文）介绍 Route 53 Resolver Inbound/Outbound Endpoints 打通混合 DNS 架构，本视频（后者）聚焦 Landing Zone 内部集中化 DNS 账号的配置实践，Terraform 自动化实现新账号上线即具备完整解析能力。 - -**[[ctp-topic-36-sendgrid-as-an-email-service]]**（CTP Topic 36）：SendGrid 被选定为经典和新 Landing Zone 的标准邮件服务，替换现有语义消息网关（Port 25 不安全、即将停用本地网络）和 SES（每封限制 50 收件人）。SendGrid 支持每封最多 1,000 收件人、全云兼容、TLS 端到端加密和双因素认证；支持计划覆盖每月 500 万封邮件；提供直连 SendGrid（需 TLS）和中继服务器（不支持 TLS 的应用）两种架构，数据通过全球中继节点（伦敦/印度/东京）走私有线路汇至美国数据中心。配置要求：使用 software.microcopy.com 域名、连接 smtp.sendgrid.net:587、启用 TLS；SPF/DKIM 记录为邮件送达必要条件；API 密钥每 180 天轮换，日志保留 7 天。同期 Yu-Yan 分享了 Cyber Suite 加密标准更新，涵盖 FIPS/Java/Golang/Node.js/OpenCell 等行业标准合规模件，可选套件因包含 CBC 模式（弱加密）仅作向后兼容，使用非标准套件的产品需经 PSAC 审查。属 [[AWS-Landing-Zone]] 通信层基础组件，与 [[ctp-topic-37-secrets-certificates-management]] 同属安全运维范畴。 - -**[[ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs]]**（CTP Topic 17）：Paul 讲解 Gruntwork AWS Landing Zones 中的 AD 服务集成——双域名策略（`swinford.net` 用于 R&D Labs，`intsas.local` 用于生产/SAS 环境）；SRE 预制 AMI 内置 PowerShell/Shell 脚本，通过 Terraform `user_data` 实现自动化域加入；旧域名 `infra` 和 `AST` 已废弃，提供明确迁移路径；Linux 支持安全动态更新（Secure Dynamic Updates）自动注册 DNS A 记录；R&D 环境使用 MIM 自助服务，生产/SAS 环境通过 SMACKS 工单系统申请账号。属 [[AWS-Landing-Zone]] AD 集成的核心实践参考。 - -**[[ctp-topic-5-aws-identity-and-access-management-iam]]**（CTP Topic 5）：AWS IAM 核心组件与联邦访问机制——涵盖 IAM Dashboard 四大资源（用户、组、客户托管策略、角色、身份提供商）；联邦用户通过 Active Directory 组映射到 IAM 角色实现单点登录；`accounts.json` 位于每个 Landing Zone 根目录，包含账户号列表；IAM 用户主要用于服务账号，人工用户优先使用联邦访问；角色本身不启用操作，而是将"谁可以做什么"与"可以做什么"关联；策略分为 AWS 托管和客户托管两种，Terraform 模块可定义 IAM 角色（假设角色策略 + 内联策略块）；PFSSO 工具实现 CLI 联邦访问；最小权限原则贯穿始终。属 [[AWS-Landing-Zone]] 身份与访问管理层的入门基础，与 [[ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs]]（AD 集成）、[[ctp-topic-11-ad-integration-and-login-using-ad-accounts]]（AD 登录）、[[learning-sessions-identity-governance-vsm-replacement]]（身份治理）共同构成完整的身份治理知识体系。 - -**[[ctp-topic-11-ad-integration-and-login-using-ad-accounts]]**（CTP Topic 11，Niranjan 主讲）：Jenkins 与企业 Active Directory (AD) 的集成，以及 Terraform 代码的自动化质量检查——核心内容：① Jenkins 与 SW Infra AD 的安全域集成，用户入离职通过 AD 账号实现自动化管理，无需手动维护本地用户；② 通过 AD 组策略实现 RBAC 精细化权限控制（只读、读写、流水线创建权限）；③ pre-commit 框架集成 terraform fmt（格式统一）、TFLint（逻辑验证）、Checkov（安全扫描）三款工具，在代码提交阶段自动嵌入安全检查；④ CI/CD 流水线分层治理模式：Commit 阶段仅触发自动化检查 → PR 阶段触发检查+terraform plan → Master 分支人工审核后执行 terraform apply。核心理念：**"左移"（Shift-Left）将安全问题从生产阶段提前到开发早期**，通过分层治理实现基础设施即代码的安全性与稳定性。属 [[AWS-Landing-Zone]] 身份与访问管理层的实践延伸，与 [[ctp-topic-5-aws-identity-and-access-management-iam]]（AWS IAM 联邦访问）共同构成身份治理知识体系。 - -**[[public-cloud-learning-sessions-opentext-tagging-standard-v2]]**（Learning Sessions，Martin Rosler 主讲）：OpenText 云资源标签标准 v2——三大驱动力（成本优化/风险降低/自动化效率）；覆盖云账户、云资源（compute/storage/network）、Kubernetes 对象（namespaces/pods/deployments/services/config maps）和容器镜像；通过标准化前缀（OT\_ / app.opentext.com / com.opentext.image）确保跨平台标签语义无歧义；最佳实践：IaC 自动化替代手动打标、禁止标签存储敏感数据、对频繁变更标签谨慎处理。属 [[AWS-Tagging-Standards]]（CTP Topic 28）同一标签治理领域的补充——前者定义 AWS 内部规范，后者定义 OpenText 跨云统一标准，两者互补。 - -**[[public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20]]**（Learning Sessions）：OpenText 将源代码管理平台从 GitHub Enterprise 迁移至 GitLab——Project Thor 整合 Micro Focus 和 OpenText 工具链，GitLab 作为源代码控制黄金标准；GitHub 许可证12月底到期不续；各团队自主盘点资产、识别流水线并规划迁移（self-serve 模式），Build Hub 提供辅助支持；两种迁移方案（镜像同步 / 搬移重构）；迁移完成标准：代码迁移 + 流水线转型 + PHT 更新；网络连通性挑战通过 Brook Park GitLab 代理解决。属 [[DevOps Culture]] 中企业级工具链标准化转型的典型案例。 - -**[[public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet]]**（Learning Sessions，Arnold Dacan 主讲）：Project Thor 平台架构与数据流设计详解——五大支柱框架（敏捷周期治理、产品发布治理、开发者门户 Backstage、安全与治理、Build Hub）；核心数据流：源代码流（GitLab）→ 制造流程（Build Farms）→ Artifactory → 客户环境；地理分布：工具链主站点 Brook Park + 灾备站点 Sacramento；标准化目标：统一 GitLab/Artifactory/UCMDB 工具链，夯实供应链安全基础。属 [[DevOps Culture]] 企业级工具链标准化与供应链安全的深度补充，与 GitHub→GitLab 迁移文档共同构成 Project Thor 知识体系。 - -**[[ctp-topic-62-aws-secrets-manager]]**（CTP Topic 62）：AWS Secrets Manager 企业级密钥管理深度实践——Nurit 和 Daniel 分享。核心内容：①选型背景——HashiCorp Vault 与 AWS Secrets Manager POC 对比，AWS Secrets Manager 以更低成本和更简实施被选定为最终方案；②AWS Secrets Management Standard 文档——最佳实践文档演变为公有云密钥管理标准，基于 Control Tower 实施经验，包含分阶段方法论（集中化密钥 → 调整自动化获取 → 启动轮换）；③核心原则——开发者无需直接访问密钥，通过 IAM 角色和标签实现访问控制；④实施机会——Oracle DB 用户密码轮换（Lambda 函数连接 Oracle 实例执行轮换，无需邮件传递密码）、SendGrid 集中邮件服务（API 密钥轮换通过集中 SMTP 服务实现，无需应用重启或代码修改）；⑤Demo——Victor 演示使用 JDBC Wrapper + AWS SDK 免密登录 Oracle 数据库，用户名由角色控制，密钥可通过标签进行分类和访问控制。属 [[AWS-Secrets-Manager]] 在企业落地的核心实践，与 [[ctp-topic-37-secrets-certificates-management]]（Secrets 与 Certificates 统一管理框架）互补，与 [[ctp-topic-36-sendgrid-as-an-email-service]]（SendGrid 邮件服务）共同构成安全运维知识体系。 - -**[[public-cloud-learning-sessions-opentext-gis-security-policies-20241015-160257-me]]**（Learning Sessions，Mike & Ed 主讲）：OpenText 全球信息安全团队（GIS）安全策略全景——GIS 是分层组织架构，包含安全运营（事件响应与保障）、合规（认证与政策执行）、治理风险验证（GRV，季度审查 Admin 角色）、隐私（新增集成中）四个支柱。OpenText 采用分层方法定义安全策略——与各团队协作定义"做什么"，与执行团队协作确定"怎么做"；持有 FedRAMP 等多项行业及政府认证，可进入多个垂直市场销售；每月处理 2250 亿条日志，分诊约 350 个案例。姿态框架基于 ISO 27001（2022 年更新，新增 11 个控制方面）；Global Information Security Policy（GISP）是最高纲领性政策，季度审查。安全运营涵盖 Cyber Response Center、威胁情报（BrightCloud）、云安全、安全工具与工程等核心服务；合规组织涵盖合规项目、路线图、产品风险评估、持续合规与审计、自动化等内容。属企业级安全治理体系的核心入门，与 [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]]（AWS 层面标签化安全）互补——GISP 定义全局政策纲领，Landing Zone 层面通过标签和 SCP 实现技术落地。 - -**[[ctp-topic-52-3-lines-of-defence-3lod-framework-cloud-security-posture-management]]**（CTP Topic 52）：Coyote（Enterprise Application Security 负责人）分享 Three Lines of Defence（3LoD）安全治理框架落地和 Cloud Security Posture Management（CSPM）工具选型——3LoD 框架经 ELT 批准后成为组织统一的安全治理模型，明确业务单元（一线：实施管理安全控制）→ 集团职能部门（二线：政策/事件响应/网络安全工具）→ 审计（三线：确保一二线合规）的三层责任分层，解决了此前安全团队和政策碎片化导致的审计问题。CSPM 解决多云账户管理碎片化问题，提供统一的合规框架视图（ CIS、NIST、ISO）和自定义策略能力；Cloud Guard 在 POC 后被选中，核心功能涵盖态势管理、资产管理、网络配置可视化、事件管理和威胁情报，新账户在创建流程中即被纳入 Cloud Guard 确保全面覆盖。核心理念：**从被动安全响应转向主动防御**，通过 CSPM 主动发现和修复云配置偏差。与 [[ctp-topic-55-aws-firewall-manager]]（Firewall Manager 安全组策略）和 [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]]（标签化安全）共同构成完整的云安全防护体系，与 [[public-cloud-learning-sessions-opentext-gis-security-policies-20241015-160257-me]]（GIS 安全策略全景）互补——后者定义组织层面的安全策略框架，前者定义云安全运营的技术落地层。 - -**[[ctp-topic-28-aws-tag-validation-tool]]**（CTP Topic 28）：AWS 标签验证工具——Lewis Brown 主讲，SRE 团队开发的 Python/Boto3 工具。Checkpoint 防火墙通过读取 EC2、安全组、负载均衡器的标签值动态配置网络访问策略，标签缺失或无效将导致流量被拦截；SCPs 可阻止不合规资源创建但无法修复存量资源。该工具通过 `variables.yaml` 定义每个账户的合法标签值，自动扫描 EC2/安全组/负载均衡器/Lambda，生成 CSV 审计报告。使用 Poetry 管理 Python 环境，存放于 SRE Tools Repository。标签策略还计划用于未来成本核算，区分同一账户下不同产品的资源消耗。属 [[AWS-Landing-Zone]] 标签治理闭环的核心补充——制定规范（Topic 10）→ 强制执行（SCPs）→ 审计发现（Topic 28）。 - -**[[ctp-topic-30-managing-change]]**（CTP Topic 30）：云转型中的变更管理与 SRE 团队协作——Brendan Starnig（SRE Function Lead）主讲。核心内容：①SRE 职责——用软件工程思维解决运维问题，追求可靠性、可测试性、可重复性，核心是打破运维与产品的壁垒；②变更分类——Standard Change（预批准，完全自动化 IaC+CI/CD，无需 CAB）→ Normal Change（需 CAB 审批，目标是通过自动化逐步归入 Standard Change）→ Emergency Change（立即执行缓解事故，事后 CAPA/Post-mortem 修复根因）；③SRE 三阶段协作——构建（Build）/早期上线支持（Early Live Support）/BAU；④Self-Healing 演进方向——各产品组分享实践，SRE 协助在监控产品中落地。属 [[AWS-Landing-Zone]] 运维治理层的核心补充，与 [[ctp-topic-28-aws-tag-validation-tool]]（IaC 变更的 Tagging 标准属于 Standard Change 范畴）共同构成变更管理知识体系。 - -**[[ctp-topic-41-nfrs-and-error-budgets]]**（CTP Topic 41）：NFR（非功能需求）与 Error Budget（错误预算）在云转型和敏捷开发中的实践——Micro Focus SRE 负责人 Brendan Standing 主讲。核心内容：①NFR 定义——评判系统运行的准则（可用性、性能、安全性、可扩展性），云环境下应更具规范性，充分利用云原生服务（如 AWS Backup 定时备份 + IaC 基础设施代码化）；②NFR Epic 模板——将 NFR 集成到 Sprint Backlog，确保任何重大变更都考虑非功能需求；③AWS 共享责任模型——云提供商负责基础设施，公司在云中架构和管理服务以满足 NFR；④Error Budget 机制——Error Budget = 1 - 可用性 SLO（如 99.9% SLO → 0.1% Error Budget），用于衡量系统在影响客户前可承受的不可靠程度，驱动开发和运维决策；⑤SLR/SLO/SLA 三层体系——SLR 是可量化的可靠性指标，SLO 定义服务应如何表现，SLA 是客户级别协议；⑥混沌工程——主动注入故障测试系统韧性，确保 NFR 得到满足。核心理念：**Error Budget 将失败归一化为开发流程的一部分，弥合了开发与运维之间的文化鸿沟**。属 [[AWS-Landing-Zone]] SRE 可靠性工程层的核心补充，与 [[ctp-topic-30-managing-change]]（SRE 变更管理）和 [[ctp-topic-72-enterprise-dr-strategy-aws-backup]]（DR 可用性目标）共同构成完整的 SRE 知识体系。 - -**[[ctp-topic-57-product-backlog-managing-demand]]**（CTP Topic 57）：CTP 产品待办列表（Backlog）需求管理完整管道——①需求提交（通过 SMACs 启动计时器和追踪）→ ②双周评审会议（Matthew Chapman/David Grant/Brendan）评估理解度、价值和优先级，约20题评估问卷判断简洁性、成本和野心程度 → ③Octane 特性化（带任务列表）→ ④Sprint 规划（提前6个 Sprint，50% 新需求 / 50% 支持+技术债）→ ⑤Prerequisite Phase（新产品组入职：介绍会议→AWS账户创建→解决方案设计→GitHub仓库→防火墙标签，产品团队约2小时，1-2周）→ ⑥SRE 构建账号并交接（提供控制台/GitHub访问详情）→ ⑦2周 Hyper Care 支持。现有产品组通过 SMACs/邮件/Teams 请求支持，Teams 频道连接产品组、SRE工程师、解决方案架构师和交付经理。核心理念：**透明化需求管道，确保所有工作以同一标准评估**。属 [[AWS-Landing-Zone]] 需求治理层的核心补充，与 [[ctp-topic-20-program-demand-process-flow]]（Gate Process 和 POC 入职）、[[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]]（敏捷实践）、[[ctp-topic-30-managing-change]]（变更管理与 SRE 协作）共同构成完整的 CTP 治理知识体系。 - -**[[public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16]]**（Public Cloud Learning Sessions，Oli Workflow）：超大规模云厂商支出审批工作流与需求管理端到端流程——涵盖两大部分：① **Oli 工作流审批机制**：所有超大规模云厂商支出无论金额均需 MUI 或 Shannon 书面审批；Oli 系统由 Tom Bice 领导的 FinOps 团队接管，正在集成到 SMACs 平台；提议的三阶段审批工作流（FinOps 可行性验证→云服务技术可行性验证→FPNA 团队预算可用性验证）；Oli 系统提供飞行中 CSV 报告追踪状态/申请人/成本中心/月成本。② **OpenText 需求管理全链路**：ITIL 框架下服务战略→设计→过渡→运营→持续改进五阶段；主服务目录（Combined Cloud Products Master Catalog）将嵌入 SMACs；Octane 和 Qixi 是两大需求提交入口；ADM/ITOM 需求规划会议捕获所需内容、数量和发布版本；核心理念：**"机器做机器能做的事"，目标 80% 场景业务单元自助完成需求选择**。属 [[Demand-Management]] 和 [[FinOps]] 在 OpenText 云转型场景的核心实践，与 [[ctp-topic-57-product-backlog-managing-demand]]（Backlog 管理管道）共同构成完整的需求治理知识体系。 - -**[[ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation]]**（CTP Topic 65）：云转型中的价值交付量化框架——提供系统性衡量、捕获和优先排序云转型业务价值的方法论。核心内容：①基础概念——过程（Process）将输入转化为产出/成果，成果分硬性（时间/成本/质量）和软性（健康/安全）；Lean 识别三类活动：增值活动、价值赋能活动、浪费；价值（Value）由客户决定，体现为公平回报；②价值流（Value Stream）分为运营价值流（OVS，面向客户）和开发价值流（DVS，内部产品）；③收益量化框架——涵盖财务、生产力、质量和体验四个维度，聚焦收入增长、成本降低、风险改善和服务可获得市场规模（SOM）；④WSJF 优先级排序——通过 Cost of Delay / Size of Job 比值对工作排序，实现"最小投入尽早交付最大价值"；延迟成本 = 业务价值 + 时间紧迫性 + 风险与机会；⑤功能级价值拆解——可按单一功能归属、均分或不均匀分配（基于触达/影响/努力等标准）。属 [[AWS-Landing-Zone]] 价值治理层的核心方法论，与 [[ctp-topic-30-managing-change]]（变更管理）和 [[ctp-topic-20-program-demand-process-flow]]（需求流程）共同构成完整的 CTP 治理知识体系。 - -**[[ctp-topic-13-cloud-finops-policies]]**（CTP Topic 13）：PCG 团队 Uday 和 Vinay 主讲 Cloud FinOps 成本优化政策与最佳实践——核心架构：PCG 三层服务模型（成本管理：账单支付/showback-chargeback/预算管理 → 成本优化：Reserved Instances 集中购买与资源去优化 → 治理与自动化：集中式上线/策略开发/自动报告）；5 大核心策略（账单可见性、标签合规、账户负责人预算责任、Reserved Instances 集中管理、区域限制）；安全控制（预安装 Godrails、联合身份管理 MFA、告警重定向至安全团队）；Cloud Health 工具提供资源清单和月度账单洞察；标准化实例选型（M/T/C/R/X 系列）+ Graviton ARM 实例节省成本；研发环境三合一优化（突发性实例 + Spot 实例 + 实例调度器）。属 [[FinOps（云财务管理）]] 在 [[Micro Focus]] 云转型场景的核心实践，与 [[ctp-topic-63-optimise-resource-cost-using-automation]]（自动化调度优化）和 [[ctp-topic-71-pcgs-guide-to-rightsizing-why-how-when]]（Rightsizing 最佳实践）共同构成完整的 FinOps 知识链路。 - -**[[public-cloud-learning-sessions-storage-cost-optimization-20240305-160037-meeting]]**（Public Cloud Learning Sessions）：AWS 存储服务成本优化全景——覆盖 EBS（GP3 推荐，比 GP2 便宜 20%，可独立扩展 IOPS/吞吐量；快照支持归档层比标准层低 75% 成本）、EFS/FSx（生命周期策略和分层机制）、S3（Intelligent Tiering 自动冷热迁移无转换费用；生命周期策略管理非当前版本和多段上传过期；数据传输费用需注意，PrivateLink 可规避）和 ADM 迁移案例（OpenZFS → 自管理 NetApp on EC2 → FSx for NetApp ONTAP 实现 60% 成本削减）。属 [[FinOps（云财务管理）]] 存储优化专题，与 [[ctp-topic-13-cloud-finops-policies]]（政策框架）和 [[public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco]]（综合成本优化）共同构成完整 FinOps 知识链路。 - -**[[ctp-topic-63-optimise-resource-cost-using-automation]]**（CTP Topic 63）：使用自动化手段优化 AWS 云资源成本——涵盖五大核心策略：①批准区域（Approved Region）标准化（Oregon/NVirginia/Frankfurt/London/Sydney/Singapore），提高安全性和成本可预测性；②实例类型选择（M6i/M6g 通用型、T3/T4g 经济型、C 系列计算型、R 系列内存型），同配置 M→R 切换节省 35%，Graviton ARM 比 Intel 便宜 20-25%；③承诺计划（1年约 40% 折扣、3年约 60-64% 折扣）；④存储优化（GP2→GP3 节省 20%，及时清理未使用 EBS 卷）；⑤自动化调度（基于标签的 EC2/RDS 启动/停止，通过 Lambda + EventBridge + Terraform Scheduler 模块实现，非 7×24 工作负载每天只运行 10 小时可节省 70% 成本）。属 [[FinOps（云财务管理）]] 技术实施层，与 [[ctp-topic-13-cloud-finops-policies]]（政策框架）和 [[ctp-topic-71-pcgs-guide-to-rightsizing-why-how-when]]（RightSizing）共同构成完整 FinOps 知识链路。 - -**[[ctp-topic-27-aws-instance-scheduler]]**（CTP Topic 27）：Gustavo 主讲 AWS Instance Scheduler 原生方案——通过 CloudFormation 一键部署，由 CCOE Guardrails 框架自动集成推送至公司绝大多数月消费 10 美元以上的 AWS 账号，无需用户手动配置。核心技术栈：CloudWatch Events 定时触发（默认每 15 分钟）→ Lambda 函数读取 DynamoDB 调度配置（Schedules + Periods）→ 根据实例标签（`Schedule`、`Period`）执行启动或停止操作。核心要点：①调度基于"时间表"而非"空闲率"触发；②支持多时区办公时间配置（西雅图时间、英国时间等）；③RDS 实例智能配合每 7 天维护窗口，确保维护完成后恢复正常调度状态；④实例关机行为必须设置为"停止（Stop）"而非"终止（Terminate）"以保留数据。与 [[ctp-topic-63-optimise-resource-cost-using-automation]] 的 Terraform Scheduler 模块（`auto_shutdown` 标签）构成互补方案——Instance Scheduler 覆盖广账户层，Terraform Scheduler 提供 IaC 层细粒度控制。 - -**[[ctp-topic-71-pcgs-guide-to-rightsizing-why-how-when]]**（CTP Topic 71）：PCG 团队讲解 AWS EC2 RightSizing 系统性方法论——核心主题：为何要做 RightSizing、何时做、如何执行的完整指南。问题域聚焦过度配置（over-provisioned）EC2 实例导致的资源浪费。RightSizing 通过分析实例实际资源使用情况，将过度配置的实例调整为合适规格，在不影响性能的前提下实现成本节省。是 [[FinOps（云财务管理）]] 核心技术手段之一。⚠️ 视频尚未完成 Whisper 转录，完整内容待补充。 - -**[[public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco]]**（Public Cloud Learning Sessions，Vinay 主讲）：AWS 云成本优化技术深度实践——**工作负载优化**聚焦现代化（EC2 新代际/Graviton 20-25% 节省/AMD 6-10% 节省/GP2→GP3 存储 20% 节省/EKS 最新版避免扩展支持费/Spot 实例 90% 折扣）和 Right Sizing（EC2 Right Sizing 报告/实例调度/闲置资源清理）。**费率优化**讲解 Savings Plans 和 Reserved Instances 的两种承诺类别（资源级 vs 灵活），以及完整实施流程（前置 Right Sizing → 分析 24/7 工作负载 → 财务沟通 → 账户所有者审批 → 利用率监控报告）。关键规则：承诺计划仅支持无预付选项，最低交易金额 $5k/年，仅由 Phenops 团队实施。属 FinOps 技术实施层，与 [[ctp-topic-13-cloud-finops-policies]]（政策框架）互补，共同构成"政策 → 技术实施"完整链路。 - -**[[public-cloud-learning-sessions-budget-control-20240319]]**（Public Cloud Learning Sessions，SRE Core 团队 Daniela/Evan/Alan 主讲）：AWS 预算控制自动化深度实践——解决 AWS 账户蔓延导致的成本失控问题。核心架构：AWS Budget → SNS → Lambda → Step Functions → SCP Enforcement（服务控制策略封禁新资源创建）的完整告警与执行链路；告警类型分 4 种（Forecast/Actual 80-98%/Severe/Enforcement），评分系统计算宽限期避免月末轻微超支账户被误处罚；Source Identity（STS SourceIdentity 属性）通过 CloudTrail 追踪联邦登录跨角色切换的原始用户身份，实现成本责任到人；初始范围仅限 Lab 账户。属 [[FinOps（云财务管理）]] Enforcement 执行层，与 [[ctp-topic-13-cloud-finops-policies]]（治理与自动化政策）和 [[public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco]]（主动优化手段）共同构成 FinOps 完整闭环（告警→Enforcement→优化）。 - -**[[public-cloud-learning-sessions-best-practices-for-ec2-cost-optimization-in-aws-2]]**（Public Cloud Learning Sessions，Mike Dukes 和 Steele Taylor 主讲）：AWS EC2 成本优化最佳实践深度解析——核心主题覆盖计算效率、Nitro 系统、Graviton 使用、EC2 Spot 竞价实例和容器化成本部署。AWS Nitro 系统通过将网络、存储和安全组件外部化来提升效率；Graviton 处理器基于 ARM64 架构，提供高达 40% 更好的性价比，功耗比同等 x86 实例减少高达 60%；EC2 Spot 实例利用 AWS 闲置容量提供高达 90% 的按需价格折扣；购买选项包括 On-Demand、Savings Plans 和 Spot Instances。Spot Invaders 游戏作为容错混沌工程的实践案例，展示了在 EKS 上使用 Spot 实例构建弹性应用的最佳实践。Graviton 适用于大多数工作负载（Web 服务、容器、HPC 批处理、大数据、CI/CD），但排除有状态服务（如数据库）；Spot 和 Graviton 可组合使用以最大化成本节省。属 [[FinOps（云财务管理）]] 技术实践层，与 [[public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco]]（成本优化技术）和 [[ctp-topic-13-cloud-finops-policies]]（政策框架）共同构成完整的 EC2 成本优化知识链路。 - -**[[public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin]]**（Public Cloud Learning Sessions，AWS 高级解决方案架构师 Suraav Paul 主讲）：AWS AI/ML 与生成式 AI 入门——AI 复制需要人类智能的任务，通过机器学习使用数据创建决策模型；分类 AI 识别模式，预测 AI 预判趋势，生成式 AI 利用基础模型（Foundation Models）创造内容。Amazon 在 ML 领域深耕 20 年，AWS 在四大领域帮助客户应用 AI：提升客户体验、实现更优决策、改善运营、创造新产品。Amazon Bedrock 是全托管生成式 AI 服务，提供 Titan 等多种基础模型，支持微调、持续预训练、RAG 和 Bedrock Agents 等数据定制技术；Guardrails for Bedrock 提供负责任 AI 安全护栏。ML Ops 将机器学习与运维融合，涵盖数据流水线（数据收集/集成/准备）、训练流水线（特征工程/模型训练/超参调优）和推理流水线（部署/监控）。属 Cloud Transformation Programme 的 Serverless & AI 专题入门，与 [[public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111]]（Generative AI & Prompt Engineering，OpenText 技术客户经理 Shikad Holtzman 主讲）和 [[public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee]]（无服务器计算）共同构成 Serverless & AI 知识链路。 - -**[[public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111]]**（Public Cloud Learning Sessions，OpenText 技术客户经理 Shikad Holtzman 主讲）：AWS 生成式 AI 服务与提示工程实践——Shikad Holtzman 阐述生成式 AI 四大价值路径（新体验/员工生产力/洞察提取/创造力激发），涵盖客服聊天机器人、代码生成摘要、文档处理和图像生成等行业场景；核心洞见：**企业数据是差异化关键**，通过 Amazon Bedrock 连接自有数据（无需重训练）即可构建专属生成式 AI 应用，且 Bedrock 保证用户数据与提示词绝不与模型提供商共享。Amazon Bedrock 提供来自 Anthropic/Meta/Amazon Titan 的多种基础模型（含多模态），内置 RAG 知识库、微调、Agents 和 Guardrails for Bedrock 自定义有害内容过滤；Amazon Q 分企业版（多数据源搜索/摘要）和开发者版（代码生成/单元测试/代码迁移）；AWS 专用训练芯片 Trainium 和推理芯片 Inferentia 支撑底层算力。提示工程（Prompt Engineering）是创建、设计和优化提示词引导 LLM 响应的迭代过程，提示由指令、上下文、用户输入和输出指示器四部分组成；基础技巧包括 One-shot/Few-shot（通过示例引导）和 Chain of Thoughts（逐步推理解决复杂任务）。属 Cloud Transformation Programme 的 Serverless & AI 专题，与 [[public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin]]（AI/ML 入门）共同构成生成式 AI 知识链路。 - -**[[public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec]]**（Public Cloud Learning Sessions，AWS AI 专家 Stephen Frank 主讲）：AWS Gen2 AI 发展驱动力与企业在生产中的 AI 应用场景——Stephen Frank 阐述 AI 演进历程（模仿人类行为 → 机器学习 → 深度学习 → Gen2 大语言模型），Gen2 AI 崛起背后的两大驱动力：2000 年代以来数据爆发式增长和更大算力的可获得性。Amazon 在核心产品和服务中应用 AI/ML 已 25 年，将经验应用于新客户产品。通用 AI 应用场景：创造新客户体验、从数据中推断核心洞察、流程自动化、生成新内容；企业软件场景：优化内部流程、启用新功能、创造新产品。**数据是差异化关键**——生成式 AI 应用通过 RAG / Fine-tuning / 持续预训练与企业现有业务数据集成。AWS 三层产品战略：基础设施层（基础模型训练/推理）→ Amazon Bedrock（旗舰 API 访问，承诺不与第三方共享用户数据，符合 GDPR）→ 即用型 AI 应用（Amazon Q 等）。Amazon Bedrock 保证用户数据与提示词不与第三方模型提供商共享；Amazon Q 通过自然语言连接多种企业数据源（知识摘要/内容创建/洞察提取）。AI 实施关键：培育实验文化、灵活选择模型、重视安全治理与合规；负责任 AI 原则：公平性（Fairness）、可解释性（Explainability）、透明度（Transparency）；最佳实践：优先考虑人、评估风险、迭代全生命周期。属 Cloud Transformation Programme 的 Serverless & AI 专题，与 [[public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin]]（AI/ML 入门）和 [[public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111]]（提示工程）共同构成完整的 AI 知识链路。 - -**[[public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee]]**（Public Cloud Learning Sessions，OpenText）：AWS 无服务器计算深度解析——现代企业面临快速创新、安全合规、事件响应和盈利增长的多重压力，Serverless 计算通过将运维任务转移给云厂商，使开发团队专注业务代码。AWS Lambda 是核心服务，开发者只需编写业务逻辑，AWS 负责负载均衡、自动扩展和安全，函数由事件（状态变化）触发，支持同步、异步和事件源映射三种调用模式；Lambda 权限模型分离执行角色（决定函数能调用哪些资源）和资源策略（决定谁能触发函数），版本、别名和 Layers 支持代码管理和复用，ARM64 架构提供更优性价比。Step Functions 基于状态机编排多个 Lambda 函数和 AWS 服务，提供 Standard（长时）和 Express（高频）两种工作流类型；API Gateway 提供边缘优化、区域和私有三种部署选项管理 API 生命周期；SAM（Serverless Application Model）基于 CloudFormation 构建，支持本地开发和测试。属 Cloud Transformation Programme 的 Serverless & AI 专题，与 [[public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin]]（AI/ML 入门）共同构成 Serverless & AI 知识链路，与 [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091]]（事件驱动架构 Part 1）和 [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091]]（事件驱动架构 Part 2）共享事件驱动执行模型。 - -**[[public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091]]**（Public Cloud Learning Sessions，AWS 解决方案架构师 Dr. Anil Giri 主讲）：事件驱动架构（EDA）进阶实践——详解 EDA 三组件（事件生产者/消费者/代理）、事件路由器（EventBridge/SNS）与事件存储（SQS/Kinesis）、编排与编排模式（Choreography vs Orchestration）、幂等性（Idempotency）、事件排序（SQS FIFO/Kinesis 保证顺序）、团队独立性（去中心化所有权 vs 集中式所有权）、Fan-out 模式（SNS 主题/EventBridge 规则）、竞争消费者模式（SQS）、死信队列（DLQ）和 EventBridge 最佳实践（每个订阅者单条规则、避免默认事件总线、失败事件处理）。核心洞见：**"Everything fails every time"**——任何系统任何时刻都可能故障，因此幂等性和 DLQ 是 EDA 生产级落地的必要保障。属 Cloud Transformation Programme 的 Serverless & AI 专题进阶篇，与 [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091]]（Part 1）构成完整 EDA 知识体系，与 [[public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee]]（无服务器计算）共享 Lambda 事件驱动执行模型。 - -**[[public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091]]**（Public Cloud Learning Sessions，AWS 解决方案架构师 Dr. Anil Giri 主讲）：事件驱动架构（EDA）入门与概述——核心学习目标：掌握企业级集成模式（Enterprise Integration Patterns），通过 Amazon EventBridge、SQS 和 SNS 探索事件驱动架构以解决现实世界中的业务挑战。会议原定演示具体 EDA 架构组件，但因 Teams 屏幕共享故障，仅完成开场介绍（⚠️ 完整演示内容参见 [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091]]）。属 Cloud Transformation Programme 的 Serverless & AI 专题，与 [[public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee]]（无服务器计算）共享事件驱动执行模型，共同构成 Serverless & AI 知识链路。 - -**[[ctp-topic-20-program-demand-process-flow-and-poc-onboarding]]**（CTP Topic 20）：云转型计划的程序需求流程与 POC 入职流程——Sergio 和 Damian 主讲。核心内容：①需求来源——主要由业务案例（如数据中心关闭）、高层管理人员战略优先级及产品路线图驱动；②Gate Process——Gate 0 评估准入、Gate 1 负责 Design Authority 审批、Gate 3 作为启动迁移的最终准入；③POC 目的——不仅验证架构和技术可行性，还包括让团队熟悉基于 Gruntwork 的新一代 Landing Zone；④新环境特点——强调 IaC（Terraform/Terragrunt）自动化部署，严禁手动构建；⑤PCG 团队——平台控制组，负责提供云环境支持、安全策略制定及协助产品组进行 POC；⑥成功标准——POC 成功标准必须在启动前明确定义。属 CTP 治理知识体系入口，与 [[ctp-topic-65]]（价值量化）、[[ctp-topic-57]]（需求管理）、[[ctp-topic-30]]（变更管理）共同构成完整的治理框架链条。 - -**[[ctp-topic-47-enterprise-architecture-cloud-standards]]**（CTP Topic 47）：Lindsay 分享企业架构云标准——核心概念：Landing Zone 框架聚焦安全、合规和可管理性，为云工作负载提供托管基础，包含账户结构（dev/stage/prod）、网络、安全、访问管理和遥测；账户结构与环境和角色对齐，通过零信任和最小权限原则定义访问控制；Terraform/Terragrunt 实现 IaC，促进标准化和可测试性；云防护栏文档捕获强制性要求和最佳实践，指导可扩展性、成本最小化和灵活性；功能分区将单体应用拆分为更小的独立模块或无服务器函数。强调需要应用团队的输入来完善防护栏并纳入实践经验。属 [[AWS-Landing-Zone]] 企业架构层的理论补充。 - -**[[ctp-topic-23-introduction-to-the-technical-architecture-team-and-function]]**（CTP Topic 23）：技术架构团队职能与云转型价值——Martin Nash（技术架构经理）主讲。核心内容：①组织变革背景——PSTC 与 IT 部门整合至 CIO 统一领导下，实现两个大型组织的深度融合；②云优先策略——除非数据主权、合规性或极端成本原因必须保留在本地，否则所有新业务优先上云；③三层架构分工——EA（企业架构）对接业务战略，SA（方案架构）负责中间件与服务优化，TA（技术架构）专注底层技术实施与基础设施治理；④技术领域划分——将技术栈划分为身份认证、网络、Microsoft 堆栈等领域，每个领域由首席架构师负责其生命周期与路线图；⑤主动规划转型——通过制定 12-24 个月技术路线图，从被动响应转向预测性规划，帮助业务部门规避风险、优化预算、提升交付速度。属 [[AWS-Landing-Zone]] 架构治理层的核心补充，与 [[ctp-topic-47-enterprise-architecture-cloud-standards]]（EA 云标准）共同构成企业架构知识体系。 - -**[[ctp-topic-72-enterprise-dr-strategy-aws-backup]]**（CTP Topic 72）：AWS 解决方案架构师 Sabith 深入讲解企业级灾难恢复策略与 AWS Backup 架构设计——核心内容：HA（高可用）关注系统运行时间和 MTBF，DR（灾难恢复）专注于防止数据丢失和系统恢复，两者互补；RPO（恢复点目标）定义可接受的最大数据丢失量，RTO（恢复时间目标）定义可接受的最大停机时间；AWS Backup 完全托管、基于策略，通过 Backup Plans 定义何时备份什么，Backup Vaults 存储恢复点，支持跨账户跨区域复制；四级 DR 架构模式（Backup and Restore → Pilot Light → Warm Standby → Active-Active）提供从低成本到高弹性的递进选择；增量备份仅捕获变更，节省成本；Vault Lock 合规模式防止任何人（包括根用户）提前删除恢复点，有效防勒索软件；建议使用独立的 Vault/Bunker Account 存储备份副本，取证账户（Forensic Account）定期测试恢复点并扫描恶意软件。属 [[AWS-Landing-Zone]] DR 与数据保护层的理论基础补充，与 [[ctp-topic-44-aws-backup-in-micro-focus]]（聚焦 Micro Focus 内部评估）和 [[ctp-topic-73-aws-backup-implementation]]（聚焦 CTP 迁移实施）构成完整的 AWS Backup 知识体系。 - -**[[Install WSL]]**（[[install-wsl]]）：微软官方 WSL 完整安装指南——`wsl --install` 一键安装（Windows 10/11 Build 19041+），支持 Ubuntu/Debian/SUSE/Kali 等多发行版并行安装，`wsl.exe --set-default-version` 切换 WSL1/WSL2；离线场景通过 MSI + DISM 命令手动启用 Virtual Machine Platform；运行入口推荐 Windows Terminal（含多标签、自定义快捷键）。[[Install WSL]] 与 [[WSL2 启动与网络配置指南]] 互补——前者解决安装问题，后者解决网络配置问题。 - -**[[WSL2]]** 是 Windows 内置的 Linux 运行环境，WSL2 默认使用 NAT 网络模式导致 Windows 代理无法被 WSL2 内部访问。通过 `.wslconfig` 启用 `networkingMode=mirrored` + `dnsTunneling=true` 可实现 WSL2 与 Windows 共享网络堆栈；国内环境下可使用 `ghproxy.com` 反向代理加速 GitHub 下载。[[WSL2]] 与 [[Ubuntu Server]] 同属 Linux 环境，[[WSL2]] 侧重 Windows 桌面开发场景，[[Ubuntu Server]] 侧重无头服务器场景。 - -### Home Server Automation -Home office setup guides cover a complete multi-node home network infrastructure across 5 nodes: **RackNerd VPS** (public gateway), **Mac Mini M4** (control node), **Synology NAS DS718** (media & storage), and **2 Ubuntu Servers** (monitoring & services). The architecture uses **FRP** (frps/frpc v0.65.0) for reverse tunnel-based intranet penetration, **Caddy** for automatic HTTPS with Let's Encrypt, and **Cloudflare** for DNS托管. **内网穿透方案（VPS + frp + Caddy）**提供完整公网域名访问：Cloudflare DNS A 记录指向 VPS 公网 IP → VPS 运行 frps 和 Caddy → 内网主机运行 frpc 将本地端口映射到 VPS（TCP 隧道）→ Caddy 反向代理到 frp 映射端口，自动申请 Let's Encrypt 证书提供 HTTPS 访问。支持 SSH 穿透（remote_port TCP 映射）不走 Caddy，包含 7 步系统化故障排查（端口监听检查、token 验证、防火墙规则、telnet 诊断等）。 Services deployed include Docker monitoring stack (**Prometheus** + **Grafana** + node_exporter + cAdvisor + blackbox_exporter + Alertmanager), media servers (**Jellyfin**, **Navidrome**, **Transmission**), personal dashboards (**Homarr**, **Apache Superset**), password management (**vaultwarden**), workflow automation (**n8n**), self-hosted Git (**Gitea**), diagram editing (**Draw.io**), developer utilities (**it-tools**), image hosting (**Zipline** + **MinIO**), cloud drive mounting (**CloudDrive2**), AI assistant (**OpenClaw**), e-book management (**Calibre**), proxy client (**v2rayA**), and Docker management (**Portainer**). All services are containerized via Docker Compose. The media workflow follows: Transmission (download) → organize → Jellyfin/Navidrome (play). Key configurations include read-only music mounts, transcode caching (200MB limit), FRP TCP tunnel port mappings (remotePort 60022-60026 for SSH, 13000 for Grafana, 14533 for Navidrome, etc.), Caddy domain mapping table (20+ subdomains under *.ishenwei.online), and SOCKS5 proxy (127.0.0.1:10808) status tracking across all nodes (Mac mini, Ubuntu1, Ubuntu2 working; NAS local-only). **CloudDrive2** enables direct NAS access to cloud storage via virtual filesystem mount (Aliyun Drive resource directory only, scan QR code with App authorization). Backup automation is implemented via rsync incremental sync to NAS, using **Synology DSM NFS** (Squash=admin, sys security, _netdev fstab params) and **nfs-common** client on Ubuntu Server. SSH server setup on Ubuntu 24.04 introduces **ssh.socket activation** (on-demand startup) as the default; administrators can switch to persistent ssh.service mode. Cross-border AI service registration guides cover using **fingerprint browsers** (**AdsPower**), **high-purity US proxies**, **SMS verification platforms** (**PingMe**), and **virtual credit cards** (**WildCard**) to safely subscribe to **Claude Pro**. The architecture provides unified HTTPS public access to all internal services without requiring static IPs, achieving privacy for internal services while maintaining low bandwidth costs. - -Key concepts: [[Docker-Image]], [[Docker-Save]], [[Docker-Load]], [[Docker Compose]], [[Docker Engine]], [[Docker 用户组]], [[APT 仓库配置]], [[GPG 密钥验证]], [[it-tools]], [[RSSHub]], [[内网穿透]], [[反向代理]], [[TCP隧道]], [[Caddy]], [[frp]], [[Symbolic Link]], [[软链接策略]], [[目录映射]], [[Prometheus]], [[PromQL]], [[Prometheus告警规则]], [[Grafana]], [[node_exporter]], [[cAdvisor]], [[blackbox_exporter]], [[Alertmanager]], [[Uptime Kuma]], [[Netdata]], [[VictoriaMetrics]], [[合成监控]], [[Exporter]], [[时序数据库]], [[TUI]], [[Process Management]], [[System Monitoring]], [[容器资源限制]], [[容器重启策略]], [[端口映射]], [[媒体服务器]], [[转码缓存]], [[只读挂载]], [[增量备份]], [[永久挂载]], [[挂载点检查]], [[Cron定时任务]], [[进程管理]], [[Socket 登录]], [[用户权限]], [[固件刷入]], [[过渡固件]], [[JFFS双清]], [[策略组分流]], [[故障转移]], [[订阅机制]], [[PUID/PGID]], [[桥接网络]], [[Socket Activation]], [[UFW 防火墙]], [[开机自启]], [[VPN Panel]], [[Xray]], [[BBR]], [[Web Proxy Protocol]], **[[全盘镜像备份]]**, **[[裸机恢复]]**, **[[NFS网络备份]]**, **[[UEFI启动]]**, [[指纹浏览器]], [[IP纯净度]], [[虚拟信用卡]], [[接码平台]], [[账号隔离]], **[[云盘挂载]]**, **[[NAS套件管理]]**, [[Root权限修复]], [[SPK套件格式]], [[launchd]], [[Gatekeeper]], **[[图床]]**, **[[S3-兼容对象存储]]**, **[[Docker堆栈]]**, **[[逻辑备份]]**, [[systemd]], [[Ubuntu Server]], **[[BI平台]]**, [[数据可视化]], **[[systemd-logind]]**, **[[HandleLidSwitch]]**, [[休眠目标]], [[pmset]], [[caffeinate]], [[Wake-on-LAN]], [[Headless 服务器]], [[系统睡眠管理]] - -**Self-Healing Infrastructure Agent**: 基于 [[OpenClaw]] 的家庭服务器自动驾驶代理（代号 "Reef"）——通过 SSH 访问家庭网络所有机器，配置 Cron Job 系统（15个活跃任务）实现 24/7 全天候自动化：每 15 分钟检查看板、每小时健康监控+邮件分拣、每 6 小时知识库录入+自检、每日 8AM 晨报（天气/日历/系统状态）、每周安全审计。Agent 可自动执行 SSH、Terraform、Ansible、kubectl 命令修复基础设施问题——"在你知道问题前就修复它"。核心安全策略：TruffleHog pre-push hooks + 私有 Gitea CI 扫描_pipeline + 1Password 专用 AI vault + 每日安全审计（防特权容器/硬编码 secrets/过度权限）。知识提取具有复利效应——一位用户从 ChatGPT 历史中提取了 49,079 条原子事实。Key concepts: [[Morning Briefing]], [[Email Triage]], [[Local-first Git]], [[Defense-in-Depth]], [[Self-Healing-Systems]], [[Agentic AI]], [[Infrastructure-as-Code]], [[Gitea]], [[TruffleHog]], [[ArgoCD]], [[Loki]], [[Gatus]], [[K3s]] - -### YouTube Automation -A practical tip for extracting YouTube Channel IDs: use `view-source:` prefix in browser to access channel page source, search for `channel_id` string in the page source to find the RSS Feed URL containing the channel ID. Can be used in [[n8n]] workflows for YouTube subscription monitoring. - -**本地 RSSHub 部署方案**（[[实战笔记-本地部署-rsshub-并获取-youtube-订阅]]）：通过 Docker 一键部署 RSSHub（`diygod/rsshub`，端口 1200），使用 `/youtube/channel/{channel_id}` 路由生成 YouTube 频道 RSS 源。相比第三方在线服务，本地部署更稳定可靠，可完全控制数据流向。本地 RSSHub 同时支撑 [[blogwatcher-daily]] Skill 的 YouTube 频道订阅监控（31个频道中18个通过 RSSHub 代理）。 - -**AI-Powered Daily Digest**: [[daily-youtube-digest]] provides a fully automated pipeline — AI Agent periodically checks subscribed channels for new uploads → extracts video transcripts via [[TranscriptAPI.com]] → generates key-point summaries → delivers a daily digest. Runs on [[OpenClaw]] via the `youtube-full` skill (installable from [[ClawHub]]), using 0-credit free API calls for channel checking and 1 credit per transcript for summarization. Supports two modes: channel-based (e.g., @TED, @Fireship, @LexFridman) and keyword-based (e.g., "Claude Code", "AI agents"). - -**[[YouTube-Content-Pipeline]]**：AI Agent 驱动的 YouTube 选题发现与选题自动化流水线——每小时 Cron Job 扫描 Web + X/Twitter 突发 AI 新闻，向 Telegram 推送选题；同时维护 90 天视频目录（播放量 + 主题分析）避免选题重复，通过 SQLite 向量嵌入实现语义去重；在 Slack 分享链接时自动研究主题、搜索 X、查询知识库并创建带大纲的 Asana 任务卡。与 [[Daily-YouTube-Digest]] 互补：后者侧重订阅频道更新监控，前者侧重全网趋势主动发现。与 [[Content-Factory]] 共享并行子 Agent 执行模式。 - -**[[academic-historian]]**（Historian）：AI Agent 角色设定——扮演具有跨时代研究能力的历史学家，为创意项目提供历史真实性验证、时代背景丰富化和历史迷思纠正。核心能力：历史编年分析、史料批判（原始文献>二手学术>通俗史>好莱坞）、历史因果推理（长期结构性原因 vs 短期触发事件）、物质文化重建（Annales 学派）、长时段分析（longue durée）、微观史、比较史、反事实推理。核心理念：物质条件决定论——在讨论政治/军事前必须先理解经济基础；主动挑战欧洲中心主义——宋朝科技/马里帝国财富同等重要；所有论断必须标注置信度和来源类型。关键方法论：五步工作流（定位时空坐标→核查物质基础→叠加社会结构→评估论断→标注置信度）。典型交付物：Period Authenticity Report（饮食/服饰/建筑/技术/货币/权力结构/性别角色全维度历史细节）、Historical Coherence Check。与 [[academic-geographer]]（空间维度）、[[academic-anthropologist]]（共时性文化系统）、[[academic-narratologist]]（叙事维度）共同构成"人文社科 AI 研究者矩阵"，与 [[academic-psychologist]] 共享心理-历史交叉分析视角。 - -**[[academic-geographer]]**：AI Agent 中的地理学家角色——专注于物理与人文地理的系统性建模，为虚拟世界构建地理连贯性。核心理念："Geography is destiny — where you are determines who you become"。通过严格地理连贯性规则（河流不分叉、气候成系统、地理非装饰）、五步工作流（板块构造→气候→水文→生物群落→人类定居）、交付物模板（地理连贯性报告、气候系统设计）驱动 Agent 行为。关键原则：避免地理决定论（地理约束但不决定）；规模很重要（"小王国"和"大帝国"地理需求完全不同）；地图是论据（制图具有政治性）。理论基础涵盖 Koppen 气候分类、Christaller 中心地理论、Mackinder 心脏地带理论、雨影效应等。与 [[academic-historian]]（历时性时间维度）、[[academic-anthropologist]]（共时性文化系统）、[[academic-narratologist]]（叙事维度）共同构成"人文社科 AI 研究者矩阵"。 - -**[[academic-anthropologist]]**：基于文化人类学理论构建文化自洽社会的 AI Agent 设计框架——将田野调查方法论注入 Agent，使其能设计有社会学意义的亲属制度、交换系统、仪式信仰和权力结构。核心理念：每个文化元素必须有社会功能（社会凝聚/资源管理/身份认同/冲突解决），先问"这个实践解决了什么问题"而非"这个仪式看起来酷不酷"。理论基础：结构人类学（列维-斯特劳斯）、象征人类学（格尔茨"厚描"）、实践理论（布迪厄）、仪式分析（特纳/范热内普）、经济人类学（莫斯/波拉尼）。关键原则：避免文化拼贴（culture salad）、不跳过亲属制度设计、无乌托邦（每个文化都有内部张力）。与 [[academic-historian]]（历时性视角）、[[academic-geographer]]（空间维度）、[[academic-narratologist]]（叙事维度）共同构成"人文社科 AI 研究者矩阵"。 - -**[[academic-narratologist]]**：以叙事理论框架驱动故事结构分析的 AI Agent——将俄罗斯形式主义、法国结构主义、认知叙事学等学术传统注入 Agent，使其能像专业叙事理论家一样分析故事结构、角色弧光、主题表达，并提供有命名框架依据的叙事建议。核心理念："每个故事都是一个论证（Every story is an argument）"；核心原则：大多数叙事问题存在于讲述层面（sjuzhet）而非故事层面（fabula），诊断应优先于处方；每个建议必须引用至少一个命名理论框架（Propp/Campbell/Genette/Barthes/Todorov）。核心框架：Propp 形态学（童话/冒险结构）、Campbell 单一体神话（英雄叙事）、Vogler 编剧旅程（好莱坞改编）、Genette 叙事学（视角/时序/声音）、Barthes 五代码（叙事语义）、Todorov 均衡模型（破坏-恢复结构）。与 [[academic-anthropologist]]（共时性文化系统）、[[academic-historian]]（历时性时间分析）、[[academic-geographer]]（空间维度）共同构成"人文社科 AI 研究者矩阵"。 - -**[[arXiv-Paper-Reader]]**：AI Agent 驱动的 arXiv 论文阅读助手——通过 `arxiv-reader` skill（3 个工具：`arxiv_fetch`、`arxiv_sections`、`arxiv_abstract`）直接从 arXiv 下载 LaTeX 源码并自动扁平化展开，消除 PDF 下载后切换论文丢失上下文和 LaTeX 符号难以解析的痛点；支持摘要浏览、多论文对比排序、选择性细读和会话式分析；本地缓存使重复访问秒级响应；纯 Node.js 零依赖部署。与 [[academic-historian]] 同属学术研究场景互补——前者侧重理工科论文，后者侧重人文社科；与 [[YouTube-Content-Pipeline]] 的 Research Agent 共享研究工作流设计模式。 - -**[[Daily Reddit Digest]]**：AI Agent 驱动的 Reddit 每日精选摘要自动化——通过 [[OpenClaw]] + `reddit-readonly` skill，每日定时抓取指定 Subreddit 的热门/最新/最高赞帖子，AI 记忆用户偏好并持续优化精选规则（如排除表情包类内容）。纯读取模式，无需认证。属 [[Daily YouTube Digest]] 同款模式（定时 + AI 摘要 + 偏好学习）的 Reddit 垂直场景。 - -**Multi-Agent Content Factory**: [[content-factory]] 是基于 Discord 频道的多 Agent 内容工厂，通过 Research Agent → Writing Agent → Thumbnail Agent 链式协作，实现内容创作全流程自动化（研究→写作→设计）。每天定时运行，创作者次日醒来即可收获成品内容。[[OpenClaw]] 提供 sessions_spawn/sessions_send 能力支撑多 Agent 编排。 - -**X/Twitter Automation**: [[x-twitter-automation]] 是基于 [[OpenClaw]] 的 X/Twitter 全功能自动化方案——通过 TweetClaw 插件（`@xquik/tweetclaw`）连接 X/Twitter 托管 API，实现自然语言驱动的发帖、回复、点赞、转发、关注、DM、搜索、数据提取、抽奖选人和账号监控。支持可配置的抽奖筛选条件（最低粉丝数/账号年龄/关键词），账号监控可追踪指定用户的新推文或粉丝变化并推送通知。所有操作通过托管 API 完成，无 Cookie、无爬虫、无凭证暴露。与 [[x-account-analysis]] 互补（分析 vs 操作），可与 [[content-factory]] 配合扩展社交媒体内容发布能力。 - -**[[x-account-analysis]]**：基于 [[OpenClaw]] + [[Bird Skill]] 的 X 账号定性分析方案——通过 Cookie 认证（auth-token / ct0）读取真实账号推文，AI 深入分析内容模式（为何有时 1000+ 赞有时 <5 赞）、话题偏好与互动差异原因。定性分析聚焦"质量"而非"数字"，揭示帖子病毒式传播的规律。免费替代 $10-$50/月 的第三方订阅分析服务。核心安全建议：为 OpenClaw 单独创建 [[ClawdBot]] 专用账号而非直接使用真实账号。与 [[x-twitter-automation]] 互补——前者侧重内容质量分析，后者侧重账号操作自动化。 - -Key concepts: [[Channel ID]], [[RSS Feed]], [[X/Twitter-API-Automation]], [[Social-Media-Giveaway]], [[Account-Monitoring]], [[Daily-Digest]], [[Transcript-Based Summarization]], [[TranscriptAPI.com]], [[Chained Agents]], [[Content Automation]], [[Semantic-Deduplication]], [[Vector-Embedding]], [[Knowledge-Base-RAG]], [[arXiv-API]], [[LaTeX-扁平化]], [[本地缓存]], [[论文摘要批量获取]] - -### n8n Workflow Automation -[[n8n]] 是开源工作流自动化平台，支持 Trigger 节点监听外部事件。n8n 可与 [[Telegram]] 集成，接收机器人消息触发工作流；也可与 YouTube API 集成实现订阅监控。Telegram 集成时需要通过 `WEBHOOK_URL` 环境变量（设为 HTTPS 地址）解决 Telegram 对 Webhook 协议的要求，否则会报 "bad webhook: An HTTPS URL must be provided for webhook" 错误。 - -**入门教程**：[[n8n-full-tutorial-building-ai-agents-in-2025-for-beginners]] 提供了使用 N8N 构建 AI Agent 的完整指南，涵盖五类节点系统（Trigger/Action/Utility/Code/Advanced AI）、Agent 记忆机制、以及与 Airtable 等外部工具的集成方法。教程强调了 Agentic System 的核心概念：Agent 利用 LLM 动态选择工具，结合 Memory 实现上下文保持，使 AI 应用能够根据用户输入自适应响应。 - -**Claude + N8N MCP 自动化工作流**：通过安装 [[n8n-mcp]]（Model Context Protocol 多功能控制面板），Claude 可理解并调用 543 个 N8N 节点，自动生成工作流。使用 OpenSea 模型 + Extended Thinking 模式可提升生成质量，Claude 生成的 N8N 工作流完成度约 80%-90%，仍需人工二次修正，但显著降低了新手的入门门槛。两种接入路径：**Claude Desktop** 端侧方案（适合桌面用户，通过本地 MCP 连接 n8n）与 **Claude API** 云端方案（适合程序化集成），核心均依赖 [[Node.js]] 运行环境。 - -Key concepts: [[Webhook]], [[WEBHOOK_URL]], [[n8n Workflow]], [[n8n-mcp]], [[Extended Thinking]], [[工作流自动化]], [[Claude Desktop]], [[Node.js]], [[Webhook-Proxy-Pattern]], [[Credential-Isolation]], [[Lockable-Workflow]], [[Visual-Debugging]], [[Safeguard-Steps]], [[Audit-Trail]] - -**OpenClaw + n8n Webhook 代理模式**：[[n8n-workflow-orchestration]] 描述了一种将 OpenClaw Agent 外部 API 交互委托给 n8n 的安全架构——OpenClaw 通过 Webhook 调用 n8n 工作流，n8n 持有凭证并执行 API 调用，Agent 完全不知道密钥。核心机制：构建 → 测试 → 锁定循环，确保工作流行为不被 Agent 静默修改。[[openclaw-n8n-stack]] Docker Compose 堆栈提供一键部署，[[Simon-Hoiberg]] 是该模式的提出者。与 n8n-mcp 的互补关系：Claude + n8n-mcp 解决工作流生成问题，本模式解决 Agent 安全集成问题。 - -### Linux System Monitoring -Six Linux resource monitoring tools reviewed: TUI tools (Btop++, Htop, Glances, Bottom) for SSH-friendly server management; GUI tools (Mission Center, Stacer) for desktop use. Author's top pick: Btop++ for its balance of usability and aesthetics. [[Btop++]], [[Htop]], [[Glances]], [[Bottom]], [[Mission Center]], [[Stacer]], [[TUI]], [[TOTP]], [[Passkey]], [[Self-Hosted Password Manager]] - -### Linux Operations Command Reference -A comprehensive Linux command reference covering 150 essential commands across 16 categories: help commands (man, help), file operations (ls, cd, cp, find, mkdir, mv, rm, touch, tree), text processing (cat, grep, sort, uniq, wc, diff, vim), compression (tar, gzip, zip, unzip), system info (uname, dmesg, uptime, du, df, top, free), search (which, locate), user management (useradd, sudo, visudo), networking (ssh, scp, wget, ping, ifconfig, netstat, ss, nmap, tcpdump), disk/filesystem (mount, fdisk, mkfs, mkswap, sync), permissions (chmod, chown, chgrp, umask), process management (kill, crontab, ps, nohup), and system shutdown/restart (shutdown, halt, poweroff). Key insight: Linux treats everything as a file (CPU, memory, disks, keyboard, users). **CPU architecture detection**: `uname -m` (x86_64/aarch64/armv7l), `lscpu` (Architecture field), `cat /proc/cpuinfo` (model name/AArch64), `file /bin/bash` (ELF metadata). - -Key concepts: [[CPU架构检测]], [[x86_64]], [[aarch64]], [[ARM64]], [[ELF格式]] - -### Educational Resources -**[[Build Your Own X]]**：GitHub 上由 [[CodeCrafters]] 维护的精选教程列表（build-your-own-x），收录 26+ 技术领域的分步骤指南，涵盖 3D Renderer、Web Browser、Database、Docker、Git、Operating System、Programming Language、Neural Network 等领域。每条教程引用 Richard Feynman 的名言："What I cannot create, I do not understand"作为核心理念——通过从零重建主流技术实现深度技术理解。与 [[ChinaTextbook]]（教材资源）互补，前者侧重工程实践（重建系统），后者侧重学科理论（课程教材）。 - -ChinaTextbook（TapXWorld/ChinaTextbook）是一个托管于 GitHub 的开源项目，收集中国小学、初中、高中、大学全阶段 PDF 教材，总库大小 41.53GB。教材来源于国家中小学智慧教育平台（basic.smartedu.cn），可通过第三方工具（tchMaterial-parser）下载。覆盖小学 10 门学科（语文、数学、英语、科学，音乐、美术、体育与健康、道德与法治等）、初中 17 门学科、高中 18 门学科，以及大学阶段概率论、离散数学、线性代数、高等数学等基础课程。 - -**免费 AI 学习资源全景**（[[learn-ai-for-free-directly-from-top-companies]]）：@RodmanAi 汇总的 10 家顶级科技公司免费 AI 学习资源——Anthropic（Skilljar 培训平台）、Google（Grow.google/AI 学习路径）、Meta（AI 资源中心）、NVIDIA（CUDA 开发者课程）、Microsoft（Microsoft Learn）、OpenAI（Academy）、IBM（SkillsBuild）、AWS（Skill Builder）、DeepLearning.AI（吴恩达课程）、Hugging Face（学习路径）。核心价值：**免费获取权威 AI 培训内容**，无需付费订阅。与 [[Claude Prompt Library]]（Anthropic 官方提示词库）属同一教育生态。 - -Key concepts: [[国家中小学智慧教育平台]], [[tchMaterial-parser]], [[ChinaTextbook]], [[Build-Your-Own-X]], [[BYOX]], [[Learn-By-Building]], [[From-Scratch-Methodology]], [[CodeCrafters]], [[NAND-to-Tetris]], [[AI教育]], [[免费学习资源]] - -### AI Tools & Prompt Engineering -Covers Claude Code, Claude Code Templates (npx 一键安装 Skills/Agents/MCP via `npx claude-code-templates@latest --skill= --yes` from aitmpl.com), OpenCode, [[Cursor]], [[Trae]], Gemini CLI, Vibe Coding, [[RAG]], multi-agent workflows, NotebookLM, Nano Banana prompting, and video generation tools. - -**Claude Skills 范式**（[[3-2-万人收藏的-claude-skills-才是-ai-这条路上最值得研究的一套范式-1]]）：Anthropic 官方 Skills 仓库（github.com/anthropics/skills，3.2 万收藏）将 Claude.ai 网页版的生产级能力原封不动拆解展示，包含办公自动化（Word/PDF/PPT/Excel）、开发者工具箱（MCP Server/自动化测试/Artifacts 构建）和创意类 Skill。核心洞察：**Skills = 说明书 + SOP**，将反复执行的有固定流程的任务拆解为 AI 能理解、能复用、能自动执行的一套流程。Claude Skills 的爆发标志着从「提示词工程」向「流程工程」的范式转变——最有价值的不是 Prompt 写得最花，而是能把业务流程沉淀成 SOP 并交给 AI 稳定执行。Vibe Coding 的尽头也是 Skills。三大 Skill 聚合站（skillsmp.com、aitmpl.com/skills、claudemarketplaces.com）可"拿来主义"直接使用；3 款高产开源 Awesome-Claude-Skills 仓库（ComposioHQ/VoltAgent/BehiSecc）提供系统性灵感。 - -**Vibe Coding 中文指南**（[[github-上-5000-人收藏的-vibe-coding-神级指南]]）：介绍 vibe-coding-cn 开源项目（github.com/tukuai/vibe-coding-cn），为中文开发者汇集全球顶尖 AI 编程资源。核心公式：**Vibe Coding = 规划驱动 + 上下文固定 + AI 结对执行**，让「从想法到可维护代码」变成可审计的流水线，而非一团无法迭代的巨石文件。工具推荐：Cursor + Claude Opus（高 context window 保证上下文一致性）。包含方法论、提示词优化技巧（需求澄清/系统架构设计/分步执行/自测全链路脚本）和完整开发流程教程。核心理念：**规划就是一切**——让 AI 写代码前必须先完成技术选型、实施规划和模块化设计，防止 AI 因理解偏差导致项目逻辑混乱。[[系统提示词构建原则]] 提供了该框架的详细行为准则——从身份定义（遵守项目约定、优先技术准确性）到具体执行规范（TODO 规划、Search/Replace 编辑、精确搜索策略），构成 Vibe Coding 的操作层指南。 - -**Gemini 3 十应用实战**（[[我用-gemini-3-一口气做了-10-个应用-附教程]]）：使用 Google [[Gemini-3]] 模型通过对话式提示词构建 10 个实用可视化应用（冷知识卡片/配色卡片/电影海报/绘画思维导图等）。核心方法论：①限定垂直场景（诗词/小说/电影）→ ②用提示词约束结构化输出（JSON/SVG）→ ③用前端 SVG/HTML 作为输出容器。三步核心机制：**AI 生成 SVG 代码 → 前端渲染为精美卡片/海报/导图**。该方法论与 [[Vibe-Coding]] 的"对话驱动 + AI 结对"理念高度契合——通过限制输入场景降低 AI 理解成本，通过提示词约束结构化输出，通过前端代码作为最终容器，是 Vibe Coding 在 AI 可视化产品方向的具体实践。 - -**[[fireworks-tech-graph]]**：Claude Code Skill，将自然语言描述转化为精美 SVG 技术图并导出 PNG——解决技术文档/博客缺乏高质量可视化图表、手动绘图耗时且风格不统一的核心痛点。内置 **7 种视觉风格**（扁平图标风/暗黑极客风/工程蓝图风/Notion极简风/玻璃态卡片风/Claude官方风格/OpenAI官方风格）和 **14 种 UML 图类型**，深度覆盖 AI/Agent 领域常见 Pattern（RAG、Agentic Search、Mem0、Multi-Agent、Tool Call 流程等）。语义形状词汇表确保图形语义一致（LLM=双边框圆角矩形、Agent=六边形、Vector Store=带内环圆柱），语义箭头系统通过颜色+虚线编码含义（主数据流/控制触发/记忆读取/写入/异步/反馈循环）。通过 `rsvg-convert` 导出 1920px PNG，可直接嵌入文章发布。安装：`npx skills add yizhiyanhua-ai/fireworks-tech-graph`，依赖 `librsvg`（macOS: `brew install librsvg`，Ubuntu: `sudo apt install librsvg2-bin`）。核心价值：**AI Agent 可快速生成专业级技术图，无需手动绘制**，支持 SVG 可编辑 + PNG 无损发布。 - -**Claude Prompt Library**（[[useful-prompt-lib]]）：Anthropic 官方提示词库，收录 64+ 款专业化提示词，覆盖开发工具（Python Bug Buster、Code Consultant、Git Gud）、效率工具（Data Organizer、Review Classifier、CSV Converter）、创意工具（Storytelling Sidekick、Culinary Creator）、营销工具（Babel's Broadcasts 多语言推文、Polyglot Superpowers 互译）、教育工具（Meeting Scribe、Lesson Planner、Socratic Sage）等 10+ 领域。TikTok 跨境电商推荐三剑客：Babel's Broadcasts（10 种语言产品发布）、Review Classifier（评论自动化分类）、Data Organizer（非结构化文本→JSON，对接 n8n 工作流）。 - -**LLM / RAG / AI Agent 三层架构**：基于 [[llms-rag-ai-agent-三个到底什么区别]] 的系统梳理，AI 应用的三层架构： -- **[[Large Language Model]]**：思考层（天才大脑），负责推理生成，但知识有截止日期 -- **[[RAG]]**：认知层（记忆系统），将 LLM 链接外部知识库，消除幻觉、提供可追溯来源 -- **[[AI Agent]]**：执行层（行动系统），感知→规划→执行→反思的循环控制，实现真正自主性 - -**[[RAG从入门到精通系列1-基础rag]]**：RAG 系列教程第一篇，系统讲解基础 RAG 的 Indexing（文档加载→切分→向量化入库）→ Retrieval（向量相似度检索 Top-k 文档块）→ Generation（问题+上下文→LLM 生成带事实依据的答案）三阶段流程。实战工具链：Qwen（LLM）+ BAAI（BGE Embedding）+ LangChain（应用编排）+ Qdrant（向量数据库）。配套 Jupyter Notebook 演示完整 Pipeline，LangSmith 可视化调试。是 [[rag从入门到精通系列1-基础rag]] 系列的基础入门篇。 - -入门术语参考：[[大模型相关术语和框架总结]] 提供 LLM、Prompt、MCP、Agent、RAG、Embedding、vLLM、Token、数据蒸馏等核心概念的通俗解释，可作为三层架构体系的术语速查手册。与 [[llms-rag-ai-agent-三个到底什么区别]]（系统梳理）属互补关系——前者入门科普，后者架构深化。 - -核心洞察：未来不在于选择其一，而在于将三者结合架构设计。 - -**ChatGPT 个性化配置**：基于 [[openai-chatgpt-个性化定义]] 的用户完整配置案例，展示如何通过 ChatGPT 自定义指令将通用 AI 塑造成专属协作者。核心配置原则包括：[[Expert User Assumption]]（将用户视为所有领域专家，无需简化技术细节）、[[Proactive AI]]（主动预判需求而非被动等待）、[[Error Accountability]]（错误零容忍且主动反馈配置导致的回复质量下降）。[[Custom Instructions]] 通过两条配置（自定义指令 + 用户详情）永久定义 AI 行为，无需每次对话重复说明。[[Personalization]] 的关键是系统性配置——错误政策、引用格式、推测告知、内容政策冲突处理——而非零散提示词。 - -**[[AI图生视频工具盘点]]**：基于 [[14个免费的AI图生视频工具-用ai让图片动起来]] 的综合分析，介绍了14个免费AI图生视频工具，覆盖阿里巴巴（绘蛙、通义万相、万相营造）、字节跳动（即梦AI）、快手（可灵AI）、智谱AI（智谱清影）、MiniMax（海螺AI）、生数科技（Vidu）、爱诗科技（PixVerse）、潞晨科技（Video Ocean）、智象未来（Viva）、MewXAI（艺映AI）、Stability AI（Stable Video）等厂商。核心能力包括：文本提示词控制运动、动作模板选择、运镜参数调节、首尾帧精准控制、主体一致性保持、音效自动生成等。电商场景（模特图动态化、商品展示）、视频创作（创意短片）、广告制作是三大主要应用方向。与 [[文字生成视频网站推荐]] 属同类AI视频生成工具的不同角度——前者侧重点图生视频，后者侧重文生视频。 - -**[[电商视频Prompt库]]**：基于 [[电商视频prompt]] 的 AI 生成宠物电商视频模块化 Prompt 库——7 大模块（产品展示/宠物动作/衣服防穿帮/场景变化/Negative Prompt/卖货文案/全流程示例），以"拼积木"方式组合使用，实现**低翻车率 + 高真实感**的 TikTok Shop 带货视频生成。核心原则：宠物衣服必加防穿帮模块，场景变化作为加法叠加而非写死；可扩展至 1 产品 → 3 条视频 → 6 条文案 → A/B 测试全链路自动化。与 [[AI图生视频工具盘点]]（工具盘点）和 [[做TK跨境思路不对努力白费]]（运营策略）共同构成 TikTok 跨境电商内容生产的完整知识链条。 - -**[[固定镜头短视频制作的AI全流程解析]]**：基于固定机位 + 内容连续变化 + 时间压缩三大原理的家装短视频 AI 制作方法论——分镜拆解（Google AI Studio）→ 九宫格图像生成（Midjourney/Nano Banana）→ 首尾针动画（海螺AI/KAI）→ 快节奏剪辑（剪映）→ 声音设计，10 分钟内完成成片。核心突破：九宫格一次性生成保证画面一致性，首尾针动画替代复杂转场，硬切反而更干净。适用于所有固定机位且状态变化明显的短视频类型。与 [[AI图生视频工具盘点]] 同属 AI 视频创作工具应用，后者侧重工具评测，前者侧重完整工作流程。 - -**NotebookLM 开源平替生态**：基于 [[google-神级生产力工具-所有-github-开源平替都找到了]] 的系统梳理，Google [[NotebookLM]] 作为 AI 笔记助手标杆，支持文档问答和播客生成两大核心能力，GitHub 上已形成完整的开源替代生态：[[OpenNotebook]]（14.6k Stars，全功能本地化，支持 16+ AI 提供商和本地模型）是 Star 最高的平替；[[SurfSense]]（11.4k Stars）定位为 NotebookLM + Perplexity + Glean 的综合替代，支持语义+全文混合搜索和团队 RBAC；[[Podcastfy]] 专注播客生成，整合 100+ LLM 和多种 TTS 引擎；[[NotebookLlama]]（LlamaIndex 官方项目）展示文档转播客的完整技术链条；[[PageLM]] 聚焦教育场景，提供康奈尔笔记和间隔重复闪卡；[[InsightsLM]] 采用 Supabase + N8N 低代码架构，支持完全离线部署。该生态覆盖从"全功能替代"到"垂直聚焦"的不同需求层次。与 [[Personal Knowledge Base (RAG)]]（文档检索知识库）同属 AI 驱动的知识管理工具，但 NotebookLM 生态侧重"文档→对话/音频"的交互形态。 - -**[[7-ways-i-use-notebooklm-to-make-my-life-easier]]**：NotebookLM 7种日常生活场景实测——①处理信息积压（将未读 PDF/文章/视频上传，AI 自动消化，用户通过问答提取要点）；②播客笔记（Audio Overviews 将文档转为双 AI 主持的对话播客，适合驾驶/健身等被动学习场景）；③快速成为多主题专家（将 Batman/Star Wars 宇宙资料或 Jupiter/Marine Corps 等专业领域文档上传，通过播客辩论式学习）；④编程辅助（上传官方文档，上下文学习，提供引用回溯）；⑤项目管理中枢（将零散研究、想法、会议记录整合为结构化路线图，作者用此法一年做出 6 个 App）；⑥版本对比（对比 App 更新、新闻稿、长文档差异，列出具体变化并附带引用）；⑦法律文档审核（租约/合同分析，每个答案附引用，可一键回溯原文核实）。核心机制：[[Source-Grounding]]——知识库严格限定于可信文档，确保答案有据可查。Premium 版提供更完整的功能。与 [[Second Brain]]（对话记忆捕获）同属个人知识管理，NotebookLM 侧重文档驱动的问答与音频交互。 - -**AI 开源平替生态**：基于 [[2025-年-11-个神级-ai-开源平替-github-杀疯了]] 的系统盘点，GitHub 上各 AI 领域已形成完整的开源平替生态——大语言模型（[[DeepSeek]] R1/V3、Qwen 3）、AI 生图（[[Flux]]、Stable Diffusion）、AI 生视频（[[HunyuanVideo]] 混元视频）、AI 智能体（[[OpenManus]] 对标 [[Manus]]）、AI 编码（[[Cline]] 对标 [[Cursor]]）、工作流自动化（[[n8n]] 16万 Star、[[Dify]]）、AI 搜索（[[Perplexica]] 对标 Perplexity）。核心洞察：国产开源模型在多个领域已达到或超越国际闭源竞品水平，[[DeepSeek]] R1 是开源界首个将 o1 级深度推理拉下神坛的破壁者，[[Manus]] 则定义了 AI Agent 元年并被 Meta 收购。 - -**[[custom-morning-brief]]**：基于 [[OpenClaw]] 的晨间简报自动化——每天定时（例 8AM）通过 Telegram/Discord/iMessage 推送结构化报告，内容涵盖：新闻研究（AI/创业/科技方向）、当日待办事项（集成 Todoist/Apple Reminders/Asana）、主动任务推荐（AI 自主思考可帮助完成的事项）、睡前完成的完整草稿（脚本/邮件/商业方案，而非仅标题）。核心洞察：**主动任务推荐**是整个系统最有价值的部分——AI 主动思考如何帮助用户，而非被动等待指令；完整草稿（full draft）比标题建议节省大量时间；用户只需发消息即可调整简报内容，无门槛个性化。与 [[self-healing-home-server]] 的 Morning Briefing 属同一模式的不同垂直场景。 - -**[[family-calendar-household-assistant]]**：基于 [[OpenClaw]] 的家庭日程协调与物资管理方案——聚合 5+ 个分散日历（工作/个人/家庭/学校/课外）生成每日晨间简报；通过环境消息监控（Ambient Message Monitoring）自动从 iMessage 中识别预约并创建日历事件（含行车时间缓冲）；维护家庭库存 JSON（冰箱/储藏室），支持照片 OCR 和小票识别更新；生成购物清单。核心洞察：**Ambient > Active**——Agent 在不被要求时主动行动才是最大突破；Mac Mini 是该场景的最优硬件（iMessage 集成 + 始终在线）。与 [[Custom Morning Brief]] 属同一晨间简报模式的不同场景（个人 vs 家庭）。 - -**Todoist Task Manager**：基于 [[OpenClaw]] 的 AI 驱动任务管理自动化——Agent 解析自然语言指令（"这周完成 Q1 报告"）→ 调用 Todoist REST API 创建结构化任务（含截止/项目/标签）→ Cron Job 定时扫描逾期任务主动推送提醒。与 [[multi-channel-assistant]] 中 Todoist 集成属同一技术栈，Todoist Task Manager 侧重任务管理的深度自动化（Cron 追踪/会议→任务闭环），multi-channel-assistant 侧重多渠道入口的统一体验。 - -**Health & Symptom Tracker**：基于 [[OpenClaw]] 的食物敏感性自动追踪方案——通过 Telegram 话题记录食物和症状，Cron Job 每日三餐定时提醒（8AM/1PM/7PM），OpenClaw 自动解析消息并带时间戳写入 Markdown 日志，每周分析关联模式识别潜在触发因素。无需专用 App，完全自托管。 - -**Habit Tracker & Accountability Coach**：基于 [[OpenClaw]] 的 AI 主动问责习惯追踪方案——通过 Telegram/SMS 每日定时签到，替代被动习惯追踪 App。与 [[Health & Symptom Tracker]] 属同一框架（OpenClaw + Telegram + Cron Job + 每周模式分析），但垂直于个人习惯养成而非健康追踪。核心洞察：**主动问责**（AI 直接询问）比被动记录更能驱动行为改变；保持 3-5 个习惯可避免签到疲劳；[[Adaptive Tone]] 自适应语气是关键差异化因素。 - -**AI-Powered Earnings Tracker**：基于 [[OpenClaw]] 的财报季自动化追踪方案——每周日 6PM 扫描财报日历并过滤用户关注公司（NVDA/MSFT/GOOGL/META/AMZN/TSLA/AMD），Telegram 投递预览列表；用户确认后为每家公司调度一次性 Cron Job，财报发布后自动搜索、格式化摘要（beat/miss、营收、EPS、AI 亮点、指引）并投递。与 [[Daily YouTube Digest]] 同属 Cron Job + AI 摘要 + Telegram 投递模式的不同实例。 - -**Event Guest Confirmation**：基于 [[OpenClaw]] + [[SuperCall]] 的活动嘉宾自动确认方案——通过 AI 语音电话批量外呼客人，确认出席状态并收集备注（饮食禁忌、Plus-One、到达时间等），通话完成后生成出席确认/未出席/未接听三分类摘要。核心价值：真人电话比短信/文字消息回复率更高；SuperCall 的沙盒 persona 设计确保 AI 只拥有预设上下文，无法访问用户 Agent 或数据，无 Prompt Injection 风险；每通电话独立重置，无对话间信息混淆。与 [[phone-based-personal-assistant]] 同属 AI 电话外呼场景，但 [[SuperCall]] 的独立沙盒设计更适用于确认类单一任务。 - -**[[personal-crm]]**：基于 [[OpenClaw]] 的个人 CRM 自动联系人发现系统——每日 Cron Job 扫描 Gmail 和日历，自动提取新联系人并更新 SQLite 数据库（姓名、邮箱、首次出现时间、最后联系时间、互动次数、备注）；通过 Telegram personal-crm topic 提供自然语言查询接口（"Who needs follow-up?"、"When did I last talk to [person]?"）；每日 7AM 会议前简报自动研究外部参会者并推送背景资料（含上次交流内容和待跟进事项）。核心价值：**零手动录入，AI 自动维护联系人关系记忆**，让每次会议都有准备。需 [[gog CLI]] 提供邮件和日历数据。与 [[local-crm-framework]]（DenchClaw）和 [[Second Brain]] 同属 OpenClaw 持久化记忆能力的不同应用场景——personal-crm 侧重结构化联系人和会议准备。 - -**Local CRM Framework**：基于 [[OpenClaw]] 的本地 CRM 框架 [[DenchClaw]]——通过 `npx denchclaw` 一键安装完整技术栈（DuckDB + Web UI + OpenClaw Profile + 浏览器自动化），所有设置/视图以 YAML/Markdown 文件存储，Agent 可直接修改 UI 而无需 API 抽象层。核心创新：Chrome Profile 克隆使 Agent 继承用户认证状态，可直接导入 HubSpot 等平台数据。[[Second Brain]] 和 [[personal-crm]] 均属同类 OpenClaw 持久化记忆能力的不同应用场景。 - -**Goal-Driven Autonomous Tasks**：[[overnight-mini-app-builder]] 是基于 [[OpenClaw]] 的目标驱动型自主任务方案——每天清晨 8:00 自动生成 4-5 个贴近目标的自主任务（研究/写作/竞品分析/MVP 构建），通过 Next.js Kanban 看板实时追踪，进度透明可见。核心洞察：**将"规划"和"执行"都外包给 AI Agent，用户只需定义目的地，Agent 自动分解并执行每日步骤**。该方案还包含过夜惊喜 Mini-App 构建模式——指示 Agent 构建 MVP，每天醒来即收获一个新产品原型。与 [[market-research-product-factory]] 同属 Alex Finn 启发的 OpenClaw 高阶用法，但前者侧重任务追踪和持续执行，后者侧重产品机会发现。与 [[Project State Management]] 的看板 vs 事件溯源存在潜在冲突。核心工程实践：**Git-style append-only 日志模式**（主会话管 AUTONOMOUS.md 状态，子代理只追加 tasks-log.md）解决多 Agent 竞态条件；[[Token-Light Design]] 保持 AUTONOMOUS.md 在 50 行以内避免心跳轮询 token 浪费。 - -**Pre-Build Idea Validator**：基于 [[OpenClaw]] + [[idea-reality-mcp]] 的 AI 项目启动前竞争分析门控——在写代码之前自动扫描 GitHub/Hacker News/npm/PyPI/Product Hunt 五个数据源，返回 `reality_signal` 分数（0-100）评估赛道拥挤度：高分数（>70）触发 STOP（展示竞品+询问是否继续/转向），低分数（<30）直接构建。核心价值：**在投入时间前发现已解决的同类问题**，是单兵创业者最重要的决策门控。与 [[market-research-product-factory]] 互补：后者挖痛点找方向，前者在动手前验证赛道的竞争密度。 - -**Never Write Another Prompt**：基于 YouTube 视频的工具介绍，展示一款将简单描述自动转化为详细结构化提示词的 AI 工具——用户无需具备提示词工程专业知识，只需输入简单描述即可获得专业级提示词，支持变量插入和自定义编辑。与 [[Claude Prompt Library 汇总表]]（现成提示词库）和 [[Nano Banana 提示词框架]]（结构化模板）同属提示词工程的不同路径——本工具侧重自动化生成，后者侧重模板规范。市场上单个专业提示词售价 $100-$500，本工具大幅降低了使用门槛。 - -**[[清华出的DeepSeek使用手册]]**：清华大学发布的《DeepSeek从入门到精通2025》官方使用指南（104页），由新闻与传播学院元宇宙文化实验室余梦珑博士后及团队撰写。与其他泛化教程不同，该手册强调"授人以渔"——不仅教用户"怎么问"，更教"为什么这么问"，帮助用户掌握提示词底层逻辑。涵盖 DeepSeek-R1 模型选择、提示语设计技巧、避免 AI 幻觉策略等核心内容。与 [[llms-rag-ai-agent-三个到底什么区别]] 同属 AI 工具方法论，但该手册聚焦 DeepSeek 特定实践。来源：[[清华出的DeepSeek使用手册，104页，真的是太厉害了！（免费领取）]] - -**[[如何写出完美的Prompt-提示词]]**：系统阐述 Prompt 构建底层逻辑的职场应用指南——核心理念：Prompt 是一套人与 AI 的协作协议，本质是将模糊需求转化为 AI 可执行的结构化任务。四大构建要素（角色+需求+场景+目标）+ 三层技巧体系（基础：需求拆解/上下文补全/格式定义/示例引导；进阶：思维链/任务拆分/角色赋能/预填回复/不确定性管理；高阶：跨模态联动/领域知识注入/反馈循环嵌入）+ 四大业务场景实战模板（内容创作/数据分析/方案策划/客户服务）+ 六大避坑指南。核心洞察：Prompt 能力的本质是有对问题清晰界定的能力 + 结构化的思维逻辑和表达能力，这决定了人能否用好 AI。与 [[清华出的DeepSeek使用手册]]（DeepSeek 特定实践）和 [[系统提示词构建原则]]（Agent 系统级指令）互补，构成完整的提示词工程方法论体系。 - -**[[Nano Banana 提示词框架]]**：Nano Banana 基础框架文档，提供两套结构化 JSON Schema 模板——物件描述框架（item / materials / details / condition）和人物描述框架（age / appearance / pose）——共用法学 shot / environment / lighting / camera / color_grade / style / quality / negatives 参数字段。将艺术总监级别的专业摄影描述语言转化为可结构化填写的模板，降低 AI 图像生成的专业门槛。与 [[Nano Banana Pro 提示词指南]]（进阶版）和 [[全网最全-nano-banana-2-使用指南-2025年12月更新-1]]（综合版）同属 Nano Banana 提示词体系。 - -**[[Nano Banana 2 国内使用指南]]**：基于 [[全网最全-nano-banana-2-使用指南-2025年12月更新-1]]，Nano Banana 2（Gemini 3 Pro Image）是 Google 发布的推理型图像生成模型——在生成图像前会进行内部推理，自动补完提示词的深层次需求，支持 1K/2K/4K 分辨率输出，最多可将 14 张输入图像组合为 1 张输出，擅长中文界面渲染、科研配图、技术路线图、教学插画等高准确性要求的图像创作。国内用户可通过 [[DeepSider]] 浏览器插件（deepsider.ai，Edge 扩展）直接访问，无需特殊网络和海外账户，插件同时支持 GPT5/GPT4.1/Claude/Gemini 2.5 Pro/Grok/Sora 2 等数十款 AI 模型。与 [[Nano Banana Pro 提示词指南]]（进阶专业提示）和 [[Nano Banana 提示词框架]]（结构化模板）同属 Nano Banana 提示词体系。 - -**[[Nano Banana Pro 提示词指南]]**：谷歌发布的 Nano Banana Pro 官方提示词指南（《The Complete Guide to Nano Banana Pro: 10 Tips for Professional Asset Production》，含上下两篇），凌晨无预警发布，核心主题是"将 AI 从趣味性图像生成升级为功能性专业资产生产"。核心理念：**停止标签堆砌，像创意总监一样思考**。核心突破：意图理解引擎实现物理规则推演、构图美学理解和语义上下文推理（而非传统关键词匹配）。关键能力：支持 14 张参考图像（6 张高保真）实现"身份锁定"；默认生成思考图像（不收费）后再输出最终结果；支持 1K-4K 原生高分辨率；[[Google Search]] 信息锚定减少实时内容幻觉。10 大黄金法则包括：编辑而非重新生成、使用自然语言完整句子、具体且具描述性、提供上下文（"为什么"或"为谁"）。上篇（[[nano-banana-pro-prompting-guide-strategies-1]]）覆盖前 9 个能力域（文本渲染/信息图、角色一致性/病毒缩略图、Google 搜索信息锚定、高级编辑/修复/着色、2D/3D 维度转换、高分辨率/纹理、思考推理、故事板/概念艺术、结构控制/布局引导），附大量可直接复制的实战提示词模板。与 [[清华出的DeepSeek使用手册]] 同属 AI 工具方法论指南——前者聚焦 DeepSeek 文本推理，后者聚焦 Nano Banana Pro 图像生成；与 [[nano-banana-提示词框架]]（Nano Banana 基础框架）和 [[全网最全-nano-banana-2-使用指南-2025年12月更新-1]]（Nano Banana 2 综合指南）同属 Nano Banana 提示词体系的不同层次。 - -**[[Ollama 本地 LLM 部署]]**：基于 [[详细-离线部署大模型-ollama-deepseek-open-webui安装使用方法及常见问题解决-1]] 的完整实操指南，展示如何使用 Ollama + DeepSeek-R1 + Open WebUI 在本地离线部署大模型。核心价值：**免费、无需 API Key、数据完全私有**。Ollama 跨平台支持（macOS/Windows/Linux/Docker），通过 `ollama run deepseek-r1:8b` 一键运行；国内网络环境下可通过魔塔社区（modelscope.cn）或 HuggingFace Mirror（hf-mirror.com）加速下载；云服务器部署必须通过 nginx + Bearer Token 保护 API 防止恶意调用；Open WebUI 提供浏览器端 Web 界面，支持 RAG 本地知识库（bge-m3 嵌入模型）和联网搜索。硬件要求：1.5B 模型需 4GB RAM，7B 需 16GB RAM，32B 需 64GB RAM+48GB 显存（Apple M2 Max 可流畅运行 32b 及以下）。 - -**[[Qwen2.5-Coder]] 部署实战**（[[在-ubuntu-安装-ollama-并运行-qwen2-5‑coder-7b]]）：Ubuntu 上通过 Ollama 本地部署 Qwen2.5-Coder 7B 代码生成模型，3条命令完成安装（`curl -fsSL https://ollama.com/install.sh | sh && ollama pull qwen2.5-coder:7b && ollama run qwen2.5-coder:7b`）。推荐配置：8+ CPU cores + 16GB RAM + NVIDIA GPU（CUDA 自动加速）。**qwen2.5-coder:7b 因 Tool usage 能力强、Shell/Python/SQL 理解强、Repo 级代码理解强，比普通 qwen2.5:7b 更适合工程任务**。支持 REST API（默认 localhost:11434）和 Python/Node.js SDK，可与 [[Open WebUI]]、[[n8n]]、[[OpenClaw]] 等工具集成构建本地 AI 应用栈。与 [[Ollama 本地 LLM 部署]]（DeepSeek-R1）同属 Ollama 本地部署场景，本方案侧重 Qwen2.5-Coder 的代码生成能力优势。 - -**Claude Code 调用方法**：[[claude-code调用方法总结]] 详细记录了 Hermes Agent 通过 `terminal` 工具调用 Claude Code 的两种模式——Print Mode（`claude -p`，适合绝大多数任务）和 TMUX 交互模式（适合超长任务）。核心参数包括 `--permission-mode bypassPermissions`（跳过所有权限确认）和 `--add-dir`（加载 SKILL.md）。关键结论：当任务需要 Claude Code 的 Skill 时，应使用 `terminal` 调用 `claude -p` 而非 `delegate_task`。 - -**Mac 必装软件清单**（[[mac必装软件清单-2026-04-17]]）：精选 8 款 Mac 必备软件——Claude（AI 助手）、Obsidian（AI 知识库）、Chrome（浏览器）、Rectangle（分屏工具）、iShot（截图录屏）、Lemon（系统清理）、Raycast（启动器）、Homebrew（包管理器）。核心理念：**用最少的软件达到最高的效率**。[[Homebrew]] 是用 Claude Code 搭 Agent 的前置依赖，[[Obsidian]] 搭配 [[Claudian]] 可打造 AI 驱动的终极个人知识库。与 [[Second Brain]] 和 [[Personal Knowledge Base (RAG)]] 同属知识管理场景。 - -**baoyu-imagine AI Logo 生成**：[[我做了个-skill-让-ai-帮你生成-logo-和图标]] 介绍了一个 Claude Code Skill `baoyu-imagine`（`npx baoyu-imagine` 安装），通过 Logo 专用提示词策略驱动 AI 生图工具生成专业 Logo 和图标。核心价值：让非设计师快速产出扁平化/几何/手绘/渐变等多种风格的专业品牌视觉资产，支持 SVG（矢量缩放）和 PNG 格式导出。与 [[Nano Banana]] 提示词体系（侧重摄影/插画/科研配图）同属 AI 图像生成工具链，baoyu-imagine 专注于 Logo/图标这一垂直场景。 - -**Coze 平台多行业 AI Agent 培训**（[[ai-解决方案专家培训课程]]）：Coze（扣子）平台的实战培训课程，分国内版（coze.cn）和海外版（coze.com），提供覆盖金融（客户分层营销、智能客服）、医疗（分诊助手、影像识别）、教育（知识库问答、拍照搜题）、电商（混剪助手、在线换衣、抖音直播回复）、人力资源（招聘打分、面试对练、AI 培训对练）、泛娱乐（AI 证件照、视频生成工作流）、在线客服（AI 助教、AI 销售）等 7 大行业共 50+ 可体验 Agent Demo，是 AI 解决方案专家培训的实操案例库。与 [[Prompt Engineering]]（提示词技能）、[[RAG（检索增强生成）]]（知识库问答）、[[Function Call]]（工具调用）三大基础能力配套，学员可通过邀请链接直接加入团队空间体验所有 Agent，并可 Fork 改造。与 [[固定镜头短视频制作的AI全流程解析]] 的 AI 视频生成工作流相关联。 - -**AI辅助PRD生成**：[[不会gemini的产品经理真的要淘汰]] 展示了大模型在产品经理工作流中的实战应用——通过 FeatureList 构思框架 → Mermaid 逻辑图辅助理解 → 分页面逐一描述生成 PRD+HTML 原型，可缩短文档工作时间 90% 以上。核心方法论：人负责"想"（创意决策），大模型负责"写"（格式补全）。 - -**[[autonomous-game-dev-pipeline]]**：基于 [[OpenClaw]] 的 AI Agent 全自动教育游戏开发流水线——每小时轮询队列产出 1 款儿童 HTML5 游戏，通过 "Bugs First" 优先策略（先修 bug 再做新功能）、Round Robin 年龄组均衡分配、纯 HTML5/CSS3/JS 无框架技术栈，实现单人维护 41+ 款游戏。核心工程纪律：同步 master → feature branch → conventional commits → PR merge，每次交付自动更新 CHANGELOG 和队列状态。核心价值：**每 7 分钟产出 1 款游戏或 1 个 bugfix**，单人可管理完整产品线。与 [[content-factory]] 同属 Agent 自动化内容生产，但前者侧重多 Agent 协作链，本方案侧重单人 Agent 的高纪律性流水线。 - -**[[aionui-cowork-desktop]]**：基于 [[AionUi]] 的 OpenClaw 桌面可视化 + 远程救援方案——通过 AionUi 的 Cowork 工作空间，用户可直接看到 OpenClaw 读写文件、运行命令、浏览网页，而非仅终端日志；内置 OpenClaw 部署专家，通过 Telegram/WebUI 远程诊断修复（`openclaw doctor`），解决"OpenClaw 挂了且不在机器旁"的困境；统一 MCP 配置一次，全局同步到 OpenClaw + 12+ 其他 Agent。与 [[Self-Healing-Home-Server]] 的远程修复场景关联，[[Multi-AgentHub]] 共享同一多 Agent 并行管理理念。 - -**播客制作自动化**：[[podcast-production-pipeline]] 提供 AI Agent 全自动播客制作流水线，覆盖「录前研究→大纲脚本→录制→时间戳笔记→社媒推广包→SEO描述」全链路。与 [[Content Factory]] 配合可将播客内容复用为博客、Newsletter、视频片段等多格式资产。 - -**Google ADK Skill 设计模式**：Google Cloud 发布的 5 种结构化设计模式，**[[ToolWrapper]]**（按需加载领域知识）、**[[Generator]]**（模板填空生成）、**[[Reviewer]]**（检查逻辑分离）、**[[Inversion]]**（先收集再行动）、**[[Pipeline]]**（硬性检查点工作流）。Anthropic 的 Skill 实践：内部几百个 Skills 总结出 3 条铁律——只写 Agent 不知道的东西、重点写踩坑清单、给工具不给指令。 - -**MCP 在 Cursor 中的集成**：MCP（Model Context Protocol）是基于 Client-Server 架构的协议，通过三种接口（GET 资源获取、POST 工具调用、Promise 提示词）实现 AI 大模型与外部工具的高效集成。在 Cursor 中有两种接入方式：SSE 服务端模式和本地 Command 命令行方式。在 Composer 的 Agent 模式下可自动执行 MCP 工具链，典型应用包括热点新闻服务（smisery 提供九个新闻来源）和 Sequential Thinking 逻辑推理工具。启用 Yolo Mode 可无确认自动执行命令，但存在误操作风险，默认关闭。 - -**会议记录自动化**：[[meeting-notes-action-items]] 提供 AI Agent 自动将会议转录文本（Otter.ai、Google Meet、Zoom）转换为结构化摘要，自动从会议中提取行动项并创建 Jira/Linear/Todoist/Notion 任务，同时发送 Slack/Discord 摘要，支持截止日提醒。核心洞察：**自动任务创建**比摘要本身更有价值，无法转化为追踪任务的会议记录只是"文档剧场"。 - -**Designing for Agentic AI**：[[designing-for-agentic-ai]] 阐述 GenAI（创作内容）vs Agentic AI（主动行动）的核心差异，以及为 Agentic AI 设计用户体验的 TCPCA 五原则——**透明度**（可视化 AI 决策进度与推理摘要）、**控制感**（停止/撤销/偏好设置机制）、**个性化**（基于历史行为预测未来需求）、**对话式交互**（自然语言界面 + 输入解读反馈）、**主动预判**（AI 预判需求并主动提供帮助，同时允许用户控制 AI 自主权级别）。核心洞察：**观察 AI 决策过程本身就是一种参与方式**，用户不再是被动旁观者；设计隐喻从"响应用户点击/滑动"转向"AI 运行时的实时反馈"。与 [[Google-5个-Agent-Skill-设计模式]]（ToolWrapper/Generator/Reviewer/Inversion/Pipeline）同属 AI Agent 设计方法论——后者侧重 Skill 架构模式，前者侧重终端用户体验设计。 - -**AI 簡報自動化工作流**：用 ChatGPT 先做知識整理，再交給 Canva / Gamma AI 输出演示文稿。两阶段工作流比直接用 AI 生成简报效果更好——ChatGPT 负责深度思考与内容组织，Canva/Gamma AI 负责视觉呈现与排版。核心洞察：让 AI 扮演不同角色（思考者 vs 设计师），充分发挥各工具的优势。与 [[YouTube-Content-Pipeline]] 共享同一"AI 整理 → AI 输出"两阶段模式。与 [[AI图生视频工具盘点]] 同属 AI 内容创作工具应用的不同垂直场景。 - -**[[我的工具集]]**：个人 AI 工具推荐清单，按类型分类（Text-to-Speech / Image-Editor / Image-to-Video / Web-Scraper / AI-Summary），每类列出工具名称、提供商、定价和链接。覆盖 Google AI Studio（Wavespeed 图生视频、Vidu $8/月、海螺 AI ¥42/月）、Brightdata（付费网页爬取）、Decopy（AI 摘要/思维导图/多语言输出）。与 [[AI图生视频工具盘点]] 互补——前者侧重工具索引清单，后者侧重免费工具详细评测。 - -Key concepts: [[AI簡報工作流]], [[AI圖生視頻工具]], [[文字生成視頻]], [[電商場景]], [[AI工具整合]], [[ChatGPT]], [[Canva]], [[Gamma AI]], [[Morning Briefing]], [[Todoist API]], [[AI-Driven Task Extraction]], [[TaskAutomation]], [[Recurring Tasks]], [[MeetingNotes]], [[ActionItemTracking]], [[TranscriptProcessing]], [[RAG从入门到精通系列]], [[Agent Personality Design]], [[Vibe Coding]], [[Design-to-Code Workflow]], [[Multi-AI Review]], [[CodeWeaver]], [[LLM Wiki]], [[多智能体系统可靠性]], [[Plan Mode]], [[Build Mode]], [[Workspace]], [[API Enablement]], [[OAuth 2.0]], [[Google Cloud Console]], [[Agent-Memory]], [[Claude Code Templates]], [[MCP（Model Context Protocol）]], [[Remote-SSH]], [[Bind Mount]], [[Attach 容器]], [[Docker 用户组]], [[SSH Config]], [[SSH 免密登录]], [[Vibe-Kanban]], [[OpenCode]], [[nvm]], [[pm2]], [[单一职责原则]], [[DRY原则]], [[模块化编程]], [[微服务架构]], [[Redis缓存]], [[消息队列]], [[输入-处理-输出模型]], [[并发编程]], [[Pain Point Mining]], [[Startup MVP Pipeline]], [[Agent-Driven Market Research]], [[Last 30 Days Method]], [[Pre-Build Validation]], [[Reality-Signal]], [[Competition-Analysis]], [[Pivot-Strategy]], [[Agent-Build-Gate]], [[CoworkWorkspace]], [[RemoteRescuePattern]], [[Multi-AgentHub]], [[MCPOnceAllAgents]], [[Personalization]], [[Custom Instructions]], [[Proactive AI]], [[Expert User Assumption]], [[Error Accountability]], [[baoyu-imagine]], [[AI-Logo-Generation]], [[Claude-Code-Skill]] - -### Productivity & Knowledge Management -Obsidian plugins, blogwatcher RSS monitoring, [[Quartz]] static site generation, project management systems, and personal CRM frameworks. QuickAdd plugin enables quick note capture via hotkeys for rapid idea recording. - -**Obsidian Skills 生态**（[[obsidian-必装-skills]]）：AI Agent 操作 Obsidian 的完整工具链——kepano 发布的 defuddle（网页清洗）、obsidian-cli（官方 CLI 增删改查）、obsidian-bases（.base 动态数据库）；Axton 发布的 obsidian-canvas-creator（径向布局算法智能排版）、mermaid-visualizer（文本转图表）、excalidraw-diagram（手绘风格图）；学术研究工具 tutor-skills（输入-内化-检测学习闭环）和 scholar-skill（L1/L2/L3 分级论文阅读，最长 2.5 小时异步任务）。[[Obsidian-CLI]]（[[obsidian-cli]]）是 Obsidian v1.12+ 内置的官方命令行工具，通过终端执行所有 GUI 操作，支持 AI Agent 自动化集成；[[Claudian]] 和 [[Obsidian-Agent-Client]] 是两款适配 Claude Code / OpenCode 等 Agent 的 Obsidian 第三方插件。与 [[Second Brain]]（对话记忆）、[[Personal Knowledge Base (RAG)]]（知识检索）、[[semantic-memory-search]]（向量搜索）同属 Obsidian 知识管理能力的不同实现。 - -**[[Quartz]]** 是 Obsidian 笔记的静态网站发布方案——将 Markdown 文件通过 `npx quartz build` 构建为 HTML/JS/CSS bundle，支持本地预览（`--serve`）和自托管部署。本地预览适合开发调试，生产部署需配置 Web 服务器处理无扩展名链接：Nginx 使用 `try_files $uri $uri.html $uri/ =404`，Apache 使用 RewriteRule，Caddy 使用 `try_files {path} {path}.html {path}/`。部署前必须正确配置 `baseUrl`，否则 RSS Feed 和 Sitemap 功能无法正常工作。[[Obsidian]] 笔记 → [[Quartz]] 构建 → 自托管（GitHub Pages / Nginx / Apache / Caddy）构成完整的个人知识发布链条。 - -**Personal Knowledge Base (RAG)**：基于 [[OpenClaw]] 的个人知识库 RAG 系统——通过 Telegram Topic 或 Slack Channel 投递任意 URL（网页/推文/YouTube 字幕/PDF），Agent 自动抓取内容并以 Embedding 向量入库；支持语义搜索（"我保存的关于 LLM memory 的内容？"），返回排名结果并附带来源；可被其他工作流（如 [[YouTube-Content-Pipeline]]）主动查询。核心理念：**捕获像发短信一样简单，检索像搜索一样容易**，无需专用 App。[[ClawHub]] 提供 knowledge-base skill 一键安装。与 [[Second Brain]] 同属 OpenClaw 持久记忆能力，Second Brain 侧重对话记忆，本方案侧重结构化知识检索。 - -**[[semantic-memory-search]]**：通过 [[memsearch]]（基于 [[Milvus]] 向量数据库）为 OpenClaw 的 Markdown 记忆文件添加语义搜索能力——用自然语言提问（"我们选了哪个缓存方案？"）即可找到相关内容，无需精确措辞。混合搜索（稠密向量 + BM25 + RRF 重排）兼顾语义相似性和关键词精确匹配；SHA-256 内容哈希实现增量索引，仅重新嵌入变更内容；支持本地模式（无需 API Key）。Markdown 文件是唯一真相，向量索引随时可重建。与 [[Knowledge-Base-RAG]] 同属 RAG 技术栈的不同场景。 - -**[[ai-memory-tools-two-camps]]**：AI 记忆工具的全景分类框架（@witcheer，2026-04-15）——GitHub 上 450+ repos 标记"agent-memory"、460+ 标记"context-management"，但几乎无人明确区分两个根本不同的技术路线： -- **Camp 1（Memory Backend）**：从对话中提取事实，存入向量/图数据库，检索时召回。代表：Mem0、MemPalace、Supermemory、Honcho。优化目标：**召回精度** -- **Camp 2（Context Substrate）**：维护结构化人类可读文件（Markdown/知识图谱），跨会话累积，背景进程整合。代表：OpenClaw、Zep、Thoth、TrustGraph、MemSearch、ALIVE。优化目标：**复合增长** -- Zep 从"memory"重塑品牌为"context engineering"是市场上最强的信号；作者预测 6 个月内"context engineering"将取代"memory"成为描述成熟 Agent 基础设施的标准术语。与 [[semantic-memory-search]]（MemSearch 的文件优先哲学）、[[Self-Improving-Skill]]（背景整合实践）同属 Context Substrate 范式的不同切面。 - -Key concepts: [[Obsidian Tasks]], [[Dataview]], [[Templater]], [[QuickAdd]], [[Spaced Repetition]], [[Kanban]], [[Projects]], [[Outliner]], [[Calendar]], [[DB Folder]], [[Homepage]], [[间隔重复]], [[看板]], [[动态模板]], [[双向链接]], [[Daily Notes]], [[Event Sourcing]], [[Second Brain]], [[Personal CRM]], [[Knowledge-Base-RAG]], [[Zero-Friction-Capture]], [[Semantic-Search]], [[Content-Ingestion]], [[semantic-memory-search]], [[memsearch]], [[Hybrid Search]], [[Reciprocal Rank Fusion]], [[Content Hashing]], [[File Watcher]] - -### 经典智慧与人生哲学 -**一语点醒梦中人**（[[一语点醒梦中人]]）：收录中国传统诗词与哲学典籍中的经典名句及其释义，涵盖儒、道、佛三家智慧——王维"行到水穷处，坐看云起时"的佛学顿悟、曾国藩"唯忘机可以消众机"的处世哲学、庄子"知其不可奈何而安之若命"的接受智慧、《老子》"大智若愚"的守拙哲学、《金刚经》"一切有为法如梦幻泡影"的空性观。核心价值：跨越千年的东方哲学智慧为现代人面对困境提供精神指引。 - -### 个人品牌与一人公司 -**[[If-You-Have-Multiple-Interests]]**（thedankoe）：系统论证多重兴趣是 AI 时代超能力的个人发展指南——核心主张：工业化专业化分工使人类沦为"愚蠢而依赖"的螺丝钉，[[Second-Renaissance]]（第二次文艺复兴）已经到来。个人成功三要素：[[Self-Education]]（自学）+ [[Self-Interest]]（自利）+ [[Self-Sufficiency]]（自立），三者相互支撑，自然涌现出 [[Generalist]]（通才型人才）。品牌不是个人简介和头像，而是读者关注3-6个月后积累的整体印象；内容是高质量创意的策展[[Idea-Museum]]（创意博物馆）；[[System-Economy]]（系统经济）中，产品即系统，差异化来自个人实践。内容创作三步法：①建立创意博物馆（3-5个高密度信息源）②基于 [[Idea-Density]]（创意密度）= 表现力 × 兴奋度筛选 ③同一想法用1000种结构表达。参考 [[Adam Smith]] 分工批判、达芬奇/米开朗基罗/[[Leonardo da Vinci]] 作为 [[Generalist]] 典范、[[Jordan Peterson]] 作为"非内容创作者"案例。核心洞察：你的优势更多在于跨领域知识的交汇处，而非专业知识本身。 - -系统性的个人商业化方法论：**天才地带自检**（识别能产生心流的活动）→ **底层能力挖掘**（追溯童年、毫不费力、底层通用三个维度）→ **心理陷阱识别**（愧疚陷阱、效率陷阱、卓越陷阱、努力陷阱）→ **Ikigai 框架定位**（热情 × 擅长 × 市场需求 × 报酬）→ **赛道验证**（搜索意图分析、支付意愿测试、落地页测试、预售验证）→ **产品体系设计**（引流免费PDF → ¥199入门工具 → ¥4999核心特训营 → ¥20,000/月高价咨询）→ **内容矩阵构建**（核心主题 × 内容形式，反向金字塔内容法，Build in Public）→ **销售漏斗搭建**（获客 → 激活 → 转化，价格锚定与诱饵效应）。 - -核心观点：一人公司的关键不是更努力工作，而是更聪明地定位，用 AI 杠杆放大个人优势。 - -Key concepts: [[Generalist]], [[Self-Education]], [[Self-Interest]], [[Self-Sufficiency]], [[Second-Renaissance]], [[Idea-Density]], [[Idea-Museum]], [[Brand-Environment]], [[Content-Creator]], [[System-Economy]], [[Attention-Economy]], [[AdamSmith]], [[LeonardoDaVinci]], [[一人公司]], [[个人品牌]], [[Ikigai框架]], [[天才地带（Zone of Genius）]], [[底层能力]], [[四个心理陷阱]], [[产品四层级体系]], [[内容矩阵]], [[Build in Public]], [[销售漏斗]], [[价格锚定]], [[诱饵效应]] - -## Source Distribution - -| Category | Count | Key Sources | -|----------|-------|-------------| -| The Agency Agents | 147+ agents | README, CONTRIBUTING, 12 divisions | -| CTP Topics | 73 topics | AWS, Azure, FinOps, Security | -| Learning Sessions | 30+ sessions | OpenText, AWS, EKS, Cloud FinOps | -| Home Office | 60+ docs | Docker, NAS, Network, Monitoring | -| AI & Productivity | 80+ docs | Claude, OpenClaw, Obsidian, Prompting | -| Marketing Agents | 30+ agents | Cross-platform, China E-commerce | - -## Key Entities - -- [[tukuai]] — 独立研究者，递归自我优化生成系统论文作者，为 [[Self-Improving-Skill]] 提供原则性理论框架 -- [[Alex Ewerlöf]] — 资深Staff Engineer（27年经验），KTH系统工程硕士，专注可靠性工程和弹性架构，《Multi-Agent System Reliability》作者，主张将LLM视为不可靠组件而非拟人化智能体 -- [[Adam Smith]] — 古典经济学家，《国富论》（1776）作者，其分工理论被 [[If-You-Have-Multiple-Interests]] 引用，揭示专业化分工对人类智识和自主性的负面影响 -- [[Leonardo da Vinci]] — 文艺复兴时期通才典范（画家+雕塑家+工程师+解剖学家），[[If-You-Have-Multiple-Interests]] 中 [[Second-Renaissance]] 和 [[Generalist]] 概念的历史原型 -- [[The Agency]] — open-source AI agent collection (147 agents, 12 divisions) -- [[agency-agents]] — GitHub repository -- [[DracoVibeCoding]] — 公众号"Draco正在VibeCoding"作者，专注 Vibe Coding 与 AI Agent 实战分享 -- [[OpenClaw]] — multi-agent framework with memory -- [[clawr.ing]] — 托管电话服务提供商，消除 Twilio 等传统电话 API 配置复杂度，为 Agent 提供主动拨打电话通知能力，覆盖 100+ 国家 PSTN 电话，不存储录音 -- [[clawhub.ai]] — OpenClaw Skill 市场，托管 clawr.ing 等 Skill 安装包 -- [[AionUi]] — 桌面多 Agent Hub（macOS/Windows/Linux），将 OpenClaw 作为可视化 Cowork Agent 运行，支持内置远程救援专家和统一 MCP 配置 -- [[n8n]] — workflow automation -- [[Shlomi Ben-Hur]] — Micro Focus 产品安全小组（PSAC）成员，主讲 CTP Topic 21（供应链安全）和 CTP Topic 24（产品隐私框架），推动将法律合规要求翻译为技术实现 -- [[Octane-Hub]] — Software Factory 团队，Micro Focus 云转型计划一部分，主导 Docker 容器化工作负载从 Bibling Lab 向 AWS Landing Zone 的迁移项目，CTO 为 Holger Rode -- [[Node.js]] — JavaScript 运行时环境，n8n-mcp 的运行依赖，也是 [[n8n]] 工作流引擎的后端运行环境 -- [[gog CLI]] — 由 steipete 开发的 Google Workspace 命令行管理工具（Homebrew 安装），支持 Gmail/Calendar/Drive/Contacts/Docs/Sheets 全套服务，[[personal-crm]] 和 [[multi-channel-assistant]] 的前置依赖 -- [[Quartz]] — static site generator for wikis -- [[RSSHub]] — open-source RSS aggregator -- [[RackNerd]]：低总价OpenVZ/KVM VPS提供商，本方案中托管公网VPS1（192.227.222.142, vps.ishenwei.online），运行frps服务端（端口7000）和Caddy自动HTTPS反向代理（*.ishenwei.online），作为全网内网服务的统一公网入口 -- [[Synology NAS DS718]]：群晖NAS设备（192.168.3.17, nas.ishenwei.online），运行DSM管理界面及Calibre/MinIO/Zipline/Navidrome/Jellyfin/Prometheus/Alertmanager/v2rayA/vaultwarden/Portainer/CloudDrive2等Docker应用，通过FRP+Caddy暴露nas/navidrome/calibre/jellyfin/zipline/miniflux等服务至公网 -- [[Docker卷]] — Docker 容器持久化数据存储，默认路径 /var/lib/docker/volumes，是 TikTok 业务数据备份的核心对象 -- [[it-tools]] — 开源开发者工具集合 Web UI（corentinth/it-tools），提供 100+ 实用工具如 URL 编解码、UUID 生成、Cron 解析、哈希计算等，通过 Docker Compose 部署，端口 8999，内存限制 128MB -- [[Navidrome]] — 开源音乐流媒体服务器，Subsonic API 兼容，支持网页端与移动客户端 -- [[Transmission]] — 开源 BT 下载客户端，Home Server 媒体中心核心组件，负责下载环节，与 Jellyfin/Navidrome 构成"下载→播放"工作流 -- [[LinuxServer.io]] — 开源 Docker 镜像维护组织，为 Transmission/Jellyfin/Navidrome 等自托管应用提供标准化 Docker 镜像 -- [[MariaDB]] — 开源关系型数据库，Synology NAS Docker 环境部署，支持内网（192.168.3.17:3307）和公网（mysql.ishenwei.online:63307）双通道访问 -- [[Claude Code]] — Anthropic CLI agent -- [[Claude Desktop]] — Anthropic Claude AI 桌面应用，支持 MCP 协议扩展，通过 n8n-mcp 连接 n8n 工作流引擎 -- [[ChatGPT]] — OpenAI 开发的大语言模型对话产品，支持自定义指令（Custom Instructions）功能，[[openai-chatgpt-个性化定义]] 是其完整配置案例 -- [[OpenAI]] — 美国 AI 研究公司，开发 GPT 系列大语言模型、ChatGPT 产品、API 接口，为本 Wiki 多个 AI 工具提供底层技术支持 -- [[OpenCode]] — Vibe Coding CLI agent -- [[Trae]] — 国产 AI 增强型 IDE，支持 Remote-SSH 远程开发和 VS Code 插件生态 -- [[ISO-27001]] — 国际信息安全管理体系标准（云安全合规基础） -- [[HIPAA]] — 美国医疗健康信息隐私法规 -- [[GDPR]] — 欧盟通用数据保护条例 -- [[Raj-Vardhan-Singh]] — LinkedIn 云计算文章作者 -- [[Agentic AI]] — 自主决策和任务执行能力的AI系统 -- [[Kubernetes]] — 容器编排平台（EKS/GKE/AKS） -- [[Terraform]] — IaC 基础设施即代码工具 -- [[LaunchDarkly]] — Feature Flag 管理平台（HP、Christian Dior RTO 优化案例） -- [[Veeam]] — 传统灾备工具（数据库备份、服务器镜像） -- [[Acronis]] — 传统灾备工具（跨区域复制） -- [[Portainer]] — Docker 可视化管理工具（portainer/portainer-ce），通过 Web UI 管理容器/卷/网络，支持 Edge Agent 集群管理，Home Server 运维常用；重装前需清理残留容器/Volume/Network，可通过 `external: true` 复用旧资源 -- [[Docker]] — 容器化平台，所有监控组件（Prometheus / Grafana / node_exporter / cAdvisor / blackbox_exporter）的部署底座，通过 Docker Compose 实现一键启动 -- [[Docker Compose]] — 多容器应用的定义和编排工具，通过 YAML 文件（docker-compose.yml / compose.yaml）声明式定义服务/网络/卷，`docker compose up/down` 管理整个堆栈生命周期，支持 `external: true` 复用已有网络和卷 -- [[Docker卷]] — Docker 容器持久化数据存储，默认路径 /var/lib/docker/volumes，通过 `docker volume ls` 查看，`docker volume rm` 删除；[[用docker安装portainer]] 的 `portainer_data` 卷存储 Portainer 用户、配置和 Edge Agent 数据 -- [[Docker Network]] — Docker 容器网络连接，默认 bridge 网络 IP 为 172.17.0.1，自定义网络如 172.24.0.1；compose 项目间同名网络冲突会产生 WARN 警告 -- [[Prometheus]] — CNCF 毕业项目，开源时序数据库和监控告警系统，pull 模式采集 exporters 指标，支持 PromQL 查询和告警规则引擎，是家庭监控方案的核心数据引擎 -- [[Grafana]] — 开源可视化平台，支持多数据源（Prometheus / Loki / VictoriaMetrics）仪表盘和告警管理，家庭方案中通过 Dashboard ID（1860/14282/7587）快速导入官方模板 -- [[node_exporter]] — Prometheus 官方主机指标采集器，以 host network 模式运行，采集 CPU / 内存 / 磁盘 / 网络 / I/O 等系统指标 -- [[cAdvisor]] — Google 开源容器资源监控工具，挂载 Docker socket 采集容器级别资源指标，为 Prometheus 提供容器层可观测性 -- [[blackbox_exporter]] — Prometheus 官方黑盒探测 exporter，通过 HTTP/TCP/ICMP/DNS/TLS 探测实现服务可用性和证书到期监控 -- [[Alertmanager]] — Prometheus 告警分发组件，支持告警分组、抑制、静默及邮件/Slack/Teams/Webhook 多通道路由 -- [[Uptime Kuma]]（louislam/uptime-kuma）— 自托管 uptime monitoring 工具，支持 HTTP/TCP/DNS/TLS 合成监控，适合外网/内网可用性探测 -- [[Netdata]] — 开箱即用的实时主机/容器监控面板，默认端口 19999，适合快速诊断，与 Prometheus 可互补使用 -- [[VictoriaMetrics]] — Prometheus 时序数据库替代方案，支持长期存储和高效写入，适合大规模数据保留场景 -- [[Portainer]] — Docker 可视化管理工具，不替代 Prometheus 但便于运维快速操作容器 -- **[[BMC]]** — 企业IT管理解决方案提供商（BMC Helix / Control-M） -- **[[AWS]]** — Amazon Web Services，提供 RDS 和 Aurora 两款托管数据库服务 -- **[[Amazon RDS]]** — 关系型数据库服务，计算与存储分离（EBS），支持 Multi-AZ 部署 -- **[[Amazon Aurora]]** — 云原生关系型数据库，6 副本跨 3 AZ 共享集群卷架构 -- [[Greg Klau]] — CTP Topic 66 讲师，主讲 PostgreSQL RDS vs Aurora 差异对比 -- [[Martin Rosler]] — Learning Sessions 讲师，主讲 OpenText Tagging Standard v2，聚焦云资源标签标准化 -- [[Vinay]] — FinOps 团队成员，主讲云成本优化技术实践（工作负载优化 + 费率优化）；Graviton 20-25% 节省、Spot 90% 折扣、Savings Plans 实施流程 -- [[Phenops-Team]] — OpenText 内部团队，2023 年发起云资源标签标准化项目，负责 Savings Plans 和 Reserved Instances 费率承诺计划的统一实施（最低 $5k/年，仅无预付选项） -- **[[Google-Cloud]]** — Google Cloud Platform -- [[Btop++]] — TUI系统监控器，作者首选 -- [[Htop]] — 轻量级TUI进程监控器 -- [[Glances]] — 超轻量TUI监控器 -- [[Bottom]] — TUI实时图表监控器 -- [[Mission Center]] — 类Windows任务管理器的GUI应用 -- [[Stacer]] — 功能最全的GUI监控+维护工具 -- [[网件RAX50]] — NETGEAR WiFi 6路由器，支持刷入梅林固件 -- [[梅林固件]] — 华硕路由器第三方固件改良版，支持软件中心插件 -- [[MerlinClash插件]] — 基于Clash核心的梅林固件科学上网插件，支持策略组分流 -- [[机场]] — 提供代理节点订阅服务的服务商 -- [[3X-UI]] — Xray 可视化管理面板（mhsanaei/3x-ui），提供 Web UI 管理 25 项运维操作（启停、更新、SSL证书、Geo更新、BBR等），支持 VLESS+Reality 入站配置生成 -- [[Xray]] — 新一代代理核心，支持 VLESS/VMess/Trojan/SS 等多协议，内置 Reality 流量伪装方案，是 3X-UI 的底层引擎 -- [[frp]] — 开源内网穿透工具，包含 frps（服务端）和 frpc（客户端）两个组件，通过反向隧道使内网服务可被公网访问，支持 TCP/UDP/HTTP 等多种协议 -- [[Ubuntu Server]] — Ubuntu Server 是 Canonical 维护的 Linux 服务器操作系统，默认使用 systemd 作为初始化系统，Ubuntu Server 24.04 LTS 是当前长期支持版本 -- [[systemd]] — Linux 系统和服务管理器，Ubuntu Server 的默认初始化系统，通过 unit 文件（service/timer/socket）和 systemctl 命令管理服务生命周期，支持开机自启（enable）、自动重启（Restart=on-failure）、日志收集（journald）等生产级特性 -- [[Mac Mini M4]] — Apple Silicon Mac Mini，作为家庭服务器运行 FRP 客户端、N8n、OpenClaw 等服务，支持 ARM64 架构 -- [[systemd-logind]] — Linux 系统登录管理器，负责管理用户会话、电源事件和系统休眠行为，Ubuntu 笔记本合盖休眠行为由其控制，通过 /etc/systemd/logind.conf 配置 HandleLidSwitch 系列参数 -- [[HandleLidSwitch]] — systemd-logind 的合盖动作配置指令，支持 ignore（忽略/继续运行）/suspend（待机）/hibernate（休眠）/poweroff（关机）/lock（锁屏）等值，Ubuntu Server 笔记本作为无显示器服务器时需设为 ignore -- [[Caddy]] — Go 语言编写的自动 HTTPS 反向代理服务器，默认启用 Let's Encrypt 证书，与 frp 配合提供内网服务的 HTTPS 访问 -- [[VPS]] — 公网虚拟专用服务器，本方案中托管 frps 和 Caddy，作为内网穿透的公网中转站（IP: 192.227.222.142） -- [[阿里云 DNS]] — 域名 ishenwei.online 的 DNS 解析服务，通过 A 记录将子域名指向 VPS 公网 IP -- [[Bandwagon VPS]] — 低总价 OpenVZ/KVM VPS 提供商，资料中 VPS2（104.194.92.188）托管了 3X-UI + Xray 服务 -- **[[CloudDrive2]]** — 云盘挂载工具，支持阿里云盘/Google Drive/OneDrive 等，通过虚拟文件系统将云端存储挂载为本地目录，Web UI 端口 19798 -- **[[矿神源]]** — Synology 社群第三方套件源（SPK 格式），提供 CloudDrive2 等官方未收录应用 -- **[[阿里云盘]]** — 阿里巴巴云盘服务，CloudDrive2 的主要挂载目标 -- [[AdsPower]] — 指纹浏览器产品，支持浏览器指纹隔离，免费版提供5个环境，是跨境服务注册的推荐工具 -- [[PingMe]] — 短信接码平台，支持美国区号码接收验证码，需下载App，最低充值2美元 -- [[WildCard]] — 虚拟信用卡服务，支持支付宝充值，解决国内用户跨境支付难题 -- [[Claude Pro]] — Anthropic Claude AI聊天工具的Pro订阅服务，月费20美元，需海外支付方式 -- [[v2rayN]] — 跨平台代理客户端（Windows/Linux/macOS），支持 VLESS+Reality 等多协议。内置部分 Core（Xray/sing-box/mihomo），其他 Core 需单独下载。Windows WPF 版需 .NET 8 Runtime；Avalonia UI 版为跨平台自包含版本；macOS DMG 需 `xattr -cr` 修复签名 -- [[v2rayNG]] — Android 代理客户端，v2rayN 的移动版，功能一致 -- [[Avalonia UI]] — 跨平台 .NET UI 框架，v2rayN desktop 版基于此构建，实现 Windows/Linux/macOS 三平台统一界面，无需额外运行时依赖 -- [[sing-box]] — v2rayN 支持的代理核心之一，支持多协议 -- [[mihomo]] — v2rayN 支持的代理核心，mihomo 协议实现 -- [[2dust]] — v2rayN GitHub 仓库维护者（github.com/2dust） -- [[BBR]] — Google TCP 拥塞控制算法，3X-UI 提供一键启用，可提升跨境网络吞吐量 -- [[代理客户端]] — 运行在终端设备上通过代理协议连接远程节点的软件，v2rayN 是典型产品，支持 VLESS/VMess/Trojan/SS 等多种协议 -- [[代理协议]] — 代理客户端与服务端通信的协议规范，如 VLESS+Reality、VMess、Trojan、Shadowsocks 等 -- [[Reality]] — Xray 的流量伪装方案，通过 SNI 分流实现深度伪装，v2rayN 可作为 Reality 客户端使用 -- [[Avalonia UI]] — 跨平台 .NET UI 框架，v2rayN desktop 版基于此构建，实现 Windows/Linux/macOS 三平台统一界面，无需额外运行时依赖 -- [[WPF]] — Windows Presentation Foundation，Windows 原生 UI 框架，.NET 桌面应用首选，v2rayN WPF 版基于此 -- [[.NET Desktop Runtime]] — .NET 桌面运行时环境，WPF 应用必需依赖，v2rayN WPF 版要求 .NET 8 Desktop Runtime -- [[便携版]] — 解压即用、数据存放在程序同目录、可复制多份独立运行的软件分发方式 -- [[安装版]] — 数据存放在系统规定用户目录、通过包管理器安装的软件分发方式（deb/rpm/dmg） -- [[代理核心]] — 代理客户端的底层引擎，如 Xray、sing-box、mihomo，负责实际流量转发 -- [[分流模式]] — 代理客户端的路由策略，"大陆白名单"模式下仅代理非中国大陆流量，减少不必要的代理开销 -- [[VPN Panel]] — Web 界面类代理管理工具的统称，3X-UI 属于此类，降低 Xray 服务端运维门槛 -- [[KoolCenter固件服务器]] — 提供梅林固件下载的服务器平台 -- **[[Clonezilla]]** — 开源磁盘镜像工具（再生龙），支持 savedisk/restoredisk 全盘镜像备份到 NAS -- **[[Rufus]]** — 开源 U 盘启动盘制作工具，ISOHybrid 镜像写入模式选择（ISO 模式推荐） -- **[[HP ZBook]]** — HP 工作站笔记本，支持 UEFI/F9 启动菜单，F10 进入 BIOS，作为 Ubuntu 24.04 安装目标机 -- **[[NodeWarden]]** — 将 Bitwarden 服务器端部署到 Cloudflare Workers 的开源实现，运行在边缘计算平台，无需 VPS 和服务器维护，数据存储在 Cloudflare D1 + R2，支持 Bitwarden 官方全平台客户端 -- **[[Cloudflare Workers]]** — Cloudflare 边缘计算平台，基于 V8 隔离的 Serverless 运行时，NodeWarden 的部署环境 -- **[[Cloudflare D1]]** — Cloudflare 边缘 SQLite 数据库，NodeWarden 的主数据存储（保管库/同步数据） -- **[[Cloudflare R2]]** — Cloudflare S3 兼容对象存储，NodeWarden 用于存储密码附件 -- [[V2RayA]] — V2Ray 的 Web 可视化管理界面，基于 V2Ray 内核，支持透明代理和分流策略，在群晖 NAS 上以 Docker 容器方式部署 -- **[[Apache Superset]]** — Apache 软件基金会旗下的开源 BI 平台，通过 Docker 快速部署，支持 SQL 查询、多样化图表和仪表盘构建。Home Server 场景通过 `apache/superset:GHA-*` 镜像容器化部署，6 步初始化流程：拉取镜像 → 启动容器 → 创建管理员 → 数据库迁移 → 加载示例 → 完成初始化，默认端口 8088（映射 8777），内置 SQLite，可选外挂 MySQL -- **[[RustDesk]]** — 开源远程桌面软件，支持自建中继服务器，可通过修改 GDM3 配置 `WaylandEnable=false` 强制 X11 解决 Ubuntu 24.04 Wayland 登录限制问题 -- **[[Ollama]]** — 开源本地 LLM 运行框架（ollama.com/ollama.org.cn），支持 macOS/Windows/Linux/Docker，提供简洁命令 `ollama run ` 运行大语言模型，通过 API（localhost:11434）和 Open WebUI 提供多元化接入方式，DeepSeek-R1 系列模型官方支持 -|- **[[Open WebUI]]** — 开源大模型 Web 界面（ghcr.io/open-webui/open-webui:main），基于浏览器访问，支持 Ollama/OpenAI API 接入，可配置 RAG 本地知识库（bge-m3 嵌入模型）和联网搜索，Docker Compose 一键部署 -|- **[[WSL2]]** — Windows Subsystem for Linux 2，Windows 10/11 内置的 Linux 虚拟机环境，默认使用 NAT 网络模式，通过 `.wslconfig` 的 `networkingMode=mirrored` 可实现与 Windows 共享网络堆栈；[[ghproxy]] 提供 GitHub 下载的反向代理加速 - -|- **[[ghproxy]]** — ghproxy.com，国内可访问的 GitHub 反向代理服务，通过将 `github.com` 替换为 `mirror.ghproxy.com/https://github.com` 绕过网络限制，适用于 uv 安装器、Claude Code 等工具的下载加速 -|- [[ProxyChains]]：通过 LD_PRELOAD 劫持 socket 调用使任意终端命令走 SOCKS5 代理的工具，配置文件 /etc/proxychains4.conf，格式 `socks5 127.0.0.1 10808`，适用于临时命令级代理 -- [[Git 全局代理]]：Git 不读取系统环境变量，必须通过 `git config --global http.proxy socks5://127.0.0.1:10808` 设置 -- [[Docker Daemon Proxy]]：通过 systemd drop-in 文件（/etc/systemd/system/docker.service.d/http-proxy.conf）注入环境变量使 docker pull 走代理，docker info | grep -i proxy 验证 -- [[Docker 网络网关 IP]]：Docker 容器内访问宿主机的 IP，bridge 网络默认 172.17.0.1，自定义网络如 172.24.0.1，容器内 127.0.0.1 指向自身而非宿主机 -- [[SOCKS5h 代理]]：socks5h 协议变体，DNS 解析由代理服务器完成，防止本地 DNS 污染，curl -x socks5h:// 使用 -- [[环境变量代理]]：通过 HTTP_PROXY/HTTPS_PROXY/ALL_PROXY 环境变量让程序走代理，Docker 容器内使用 ALL_PROXY=socks5://172.24.0.1:10808 -- [[Wayland]]：Linux 新一代显示协议，Ubuntu 24.04 默认使用，基于安全设计严格限制外部程序在未登录状态下获取屏幕控制权，是 RustDesk 无法在 Login Screen 场景工作的根本原因 -- [[X11]]：经典显示协议，兼容性好、权限开放度高，远程桌面场景下稳定性优于 Wayland，通过修改 GDM3 配置 `WaylandEnable=false` 强制启用 -- [[GDM3]]：GNOME Display Manager，Ubuntu 默认登录管理器，控制用户会话初始化，支持 Wayland 和 X11 两种显示协议 -- **[[透明代理]]** — 通过修改 iptables 规则劫持系统出站流量，国内直连、国外走代理的分流机制，V2RayA 的核心实现方式 -- **[[分流模式]]** — V2RayA 的路由策略，"大陆白名单"模式下仅代理非中国大陆流量，减少不必要的代理开销 -- **[[iptables]]** — Linux 内核防火墙，V2RayA 通过修改 iptables 规则实现透明代理 -- **[[MinIO]]** — 开源 S3 兼容对象存储，Zipline 图床系统的存储后端，提供高性价比本地存储 -- **[[Zipline]]** — 开源自托管图床应用，提供前端上传 UI 和 REST API，支持 [[n8n]] 工作流集成 - -### TikTok E-commerce Operations -**[[电商如何选品-如何找到爆款-选品策略]]**（YouTube 视频摘要）：电商选品系统方法论——20 种选品策略（细分市场定位如LGBTQ群体、情境配对如露营三件套、季节性规划等）+ POD 低成本测款模式 + 工具辅助分析（Salesmartly 多平台订单管理、Erank 竞争分析、Pinterest/Etsy 趋势报告）。核心观点：未来品牌需针对细分市场而非大众市场；多工具组合使用可提升客户转化率和选品效率。与 [[做TK跨境思路不对努力白费]]（运营策略）和 [[TikTok E-commerce Product Management]]（Django 产品管理系统）共同构成 TikTok 跨境电商知识体系。 - -**[[做TK跨境思路不对努力白费]]**：TikTok 跨境电商全流程实战指南——从市场选择（优先美区/日本，避开东南亚）→ 账号准备（选区看直播了解流程）→ 选品策略（数据软件分析+单一垂直类目）→ 店铺运营（流量监控+商品优化）→ 流量获取（短视频营销+达人合作）→ 仓储物流（海外仓+海运补货）→ 团队建设（招聘分工），提供完整的执行框架。核心观点：思路正确是成功的前提，市场定位和选品是核心竞争力。与 [[电商如何选品]] 同属选品策略范畴，与 [[TikTok E-commerce Product Management]]（Django 产品管理系统）互补——前者侧重运营策略，后者侧重技术实现。 - -**电商数据采集与处理系统**：基于 Docker + Ubuntu + n8n 的可自动化、可扩展、AI增强的电商数据采集与处理系统。三层架构：爬虫层（Scrapy/Playwright）→ AI处理层（n8n + LLM API）→ 存储展示层（PostgreSQL/MinIO + Grafana）。推荐 Scrapy + Playwright 组合抓取动态页面，Docker Compose 容器化部署，输出 JSON/CSV 供 n8n 消费；n8n 工作流实现定时启动爬虫→读取数据→LLM提取属性→写入数据库→报表通知的全链路自动化；AI 处理任务包括摘要分类、多语言翻译、特征提取、异常检测；本地可使用 Ollama（Mistral/Llama3）通过 HTTP Request 调用，无需外部 API Key；防封策略包括 User-Agent 轮换、代理池（Bright Data/ScraperAPI）和下载延迟随机化。与 [[做TK跨境思路不对努力白费]]（运营策略）互补，后者侧重电商运营全流程，前者侧重技术架构搭建。与 [[scrapy-playwright-抓取tiktok-shop-data]] 同属电商数据采集技术栈。 - -### TikTok E-commerce Product Management -A comprehensive Django-based product data management system for TikTok Shop. Covers Django ORM models (Product, ProductImage, ProductVideo, ProductVariation, ProductReview), Django Admin customization (TinyMCE rich text, inline models, image preview modals), REST API via Django REST Framework with django-filter for search and filtering, Docker + Gunicorn + Nginx production deployment, Django-Q async task queue for Bright Data API scraping, and custom Management Commands for JSON data import. Key components: Product list with thumbnail display, multi-condition filtering by store_name, bulk product fetch via Bright Data asynchronous API, description detail HTML generation, and Apache Superset BI dashboard integration. - -Key concepts: [[Django ORM]], [[Django REST Framework]], [[Django Admin 定制]], [[Docker 容器化部署]], [[Django-Q 异步任务]], [[Bright Data API]], [[MySQL / MariaDB 数据库]], [[Gunicorn]], [[Nginx]], [[自定义管理命令]] - -### New Linux/DevOps Concepts (recently added) -- **[[efibootmgr]]** — Linux NVRAM 启动项管理工具，可强制重写 BootOrder 解决 HP BIOS 固执行为 -- **[[ISOHybrid镜像]]** — 同时支持 BIOS 和 UEFI 引导的混合 ISO 镜像，Rufus 提供 ISO/DD 两种写入模式 -- **[[UEFI Only]]** — HP ZBook 终极启动修复方案，切换后消除 Legacy BBS 项干扰 -- **[[NVMe硬盘分区]]** — Ubuntu 24.04 自动识别并优化 NVMe 分区对齐 - -### Sales Outbound Methodology -**[[sales-outbound-strategist]]**（Outbound Strategist Agent）：信号型出站销售策略师，将出站销售从"批量轰炸"转变为"精准触发"——核心信念：出站应由证据驱动，而非配额驱动。核心理念：**信号驱动出站转化率比无触发出站高 4-8 倍**；信号的半衰期极短（30 分钟内必须路由到正确销售），24 小时后信号失效，72 小时后竞争对手已成交。核心框架：三层信号分级体系（Tier 1 主动购买信号如 G2 访问/竞品对比 → Tier 2 组织变化信号如融资/招聘/领导层变动 → Tier 3 技术/行为信号如技术栈变化/内容互动）+ 可证伪 ICP 定义（含排除条件，否则是 TAM 幻灯片）+ 三层账户分级（Tier 1 深度多线程个性化 / Tier 2 半个性化序列 / Tier 3 自动化轻定制）+ 8-12 触点 3-4 周多渠道序列（每次触达必须提供新的价值角度）。冷邮件回复率基准：泛化型 1-3%、角色定制 5-8%、信号驱动 12-25%、推荐引入型 30-50%。SDR 角色演变：从每天 100 次活动的批量操作员 → 拥有 50-80 个深度账户的信号监控管线专家。与 [[sales-discovery-coach]] 协同——发现阶段收集的 ICP 信号直接驱动出站序列启动；与 [[sales-deal-strategist]] 形成漏斗互补——出站负责漏斗顶部（Signal → Contact），Deal Strategist 负责漏斗中部（Qualified → Commit）；与 [[sales-account-strategist]] 形成客户生命周期互补——出站获取新客户，Account Strategist 负责 Land-and-Expand 扩张。 - -### Sales Discovery Methodology -**[[sales-discovery-coach]]**（Discovery Coach Agent）：销售发现访谈（Discovery）方法论与教练框架，帮助销售代表和SDR成为更优秀的买家访谈者——坚信发现阶段才是交易成败的真正战场，而非演示、提案或谈判阶段。 - -**三大发现框架：** -- **[[SPIN Selling]]**（Neil Rackham）：四步提问法（Situation → Problem → Implication → Need-Payoff），核心洞察是 Implication 问题通过激活损失厌恶心理推动成交，是 SPIN 框架中最有力量但最常被跳过的一步 -- **[[Gap Selling]]**（Keenan）：以当前状态与期望未来状态之间的差距为中心的销售方法论；差距越大紧迫感越强；根因问题（而非表面症状）才真正驱动购买决策 -- **[[Sandler Pain Funnel]]**：从表面症状 → 商业影响 → 个人/情感层面的三层漏斗；第三层（情感层面）是大多数销售人员永远不会触及的区域，但购买决策本质上是情感决策 - -**标准发现电话结构（30分钟）**：开场2分钟（Upfront Contract，设定三种可能结果建立信任）→ 发现阶段18分钟（60-70%精力放在当前状态和痛点）→ 定向pitch 6分钟（仅展示直接对应买家痛点的能力）→ 下一步4分钟（明确谁做什么、什么时候做） - -**[[AECR Framework]]**（异议处理四步框架）：Acknowledge → Empathize → Clarify → Reframe，将异议视为诊断信息而非攻击。核心洞察：预算异议几乎从不是真正的预算问题，本质是买家对价值是否超过成本的判断。 - -核心教练原则：发现不是审讯，而是帮助买家更清晰地看清自身处境；60/40规则（买家说话60%以上）；最优秀的销售比竞争对手多问一个问题；资格筛选要快（没有真正痛点、无法触达决策者、无紧迫时间线就不是交易而是预测谎言）。 - -### Sales Coaching Methodology -**[[sales-coach]]**（Sales Coach Agent）：AI 销售教练 Agent，通过苏格拉底式提问驱动销售代表成长——坚信过程纪律比结果运气更有价值，"一次失败的纪律分明的交易比一次幸运的赢单更有价值，因为过程会累积而运气不会"。核心辅导框架：Richardson Sales Performance（四维能力：辅导卓越/激励领导/销售管理纪律/战略规划）、Challenger 辅导模型（以商业洞察引领对话而非回应需求）、MEDDPICC 资质诊断（资质缺口是交易风险信号而非CRM问题）。每周2小时以上辅导的代理赢单率56%，vs 少于30分钟仅43%；正式辅导项目配额完成率91.2%，vs 非正式辅导84.7%。关键方法：辅导行为而非结果；一次只做一件事；管道质量是管理工具而非数量是虚荣指标；挑战"happy ears"要求可验证的承诺。[[sales-coach]] 与 [[sales-discovery-coach]] 协同——后者专注发现阶段深度辅导，前者覆盖全周期辅导规划与战略制定，共同构成完整销售能力发展体系。 - -**[[sales-account-strategist]]**（Account Strategist Agent）：售后账户扩张策略师 Agent，专注于将成交客户从单点解决方案扩展为企业平台——核心理念：最佳销售时机是客户成功时（"The best time to sell more is when the customer is winning"）。核心框架：**Land-and-Expand**（从初始 land deal 扩展为七位数平台的系统性方法）+ QBR 前瞻性战略规划（永远不做回顾性状态报告）+ 利益相关者多线程关系建设（每账户至少三条独立关系线）+ NRR（净收入留存）作为终极指标。账户健康评分体系：绿色账户推扩张、黄色账户稳基础、红色账户救流失。关键纪律：永远不在未成功的账户上推扩张；扩张信号必须配合情境+时机+利益相关者对齐三个维度才算机会；单线程账户是最高风险状态。[[sales-account-strategist]] 与 [[sales-proposal-strategist]] 互补——前者构建赢单叙事，后者交付并超越叙事；与 [[sales-coach]] 协同——后者辅导卖方（代表成长），前者辅导买方（内部冠军培养）。 - -**[[sales-deal-strategist]]**（Deal Strategist Agent）：高级deal策略师与管线架构师，将严谨的资质方法论应用于复杂B2B销售周期——坚信每个deal都是战略问题而非关系练习，"如果资质缺口没有尽早识别，失败就已经锁定了，只是你还没发现"。核心能力：**MEDDPICC资质评估**（八维度评分，每维度5分，满分40；全面推行MEDDPICC的组织赢率提升18%、deal规模扩大24%）+ **竞争定位**（Winning/Battling/Losing三区分析 + 地雷问题布局）+ **Challenger商业教学法**（六步序列：Warmer → Reframe → Rational Drowning → Emotional Impact → A New Way → Your Solution）+ **交易检查方法论**（系统探测风险信号：单线程/无紧迫事件/Champion不开放EB通道/决策标准完美匹配竞争对手）。核心原则：预测准确率Commit deals关闭率85%+；Qualified Pipeline（28/40+）赢率35%+；永远不做单线程账户；每条资质缺口必须附带具体下一步、责任人、和截止日期。与 [[sales-discovery-coach]] 协同——后者提供买方情境输入（发现阶段），前者构建交易策略（评估+定位+计划）；与 [[sales-proposal-strategist]] 互补——Deal Strategist提供结构化deal分析和竞争定位，Proposal Strategist将其转化为说服性叙事，共同构成"发现→赢单策略→提案叙事"完整销售闭环。 - -**[[sales-pipeline-analyst]]**（Pipeline Analyst Agent）：Revenue Operations 领域的 Pipeline 健康诊断与收入预测 AI Agent，将 CRM 数据转化为可执行的 Pipeline 洞察——坚信"每个 Pipeline 评估都应至少发现一个需要立即干预的 Deal"。核心框架：**Pipeline Velocity** =（合格机会数 × 平均 Deal 规模 × 胜率）/ 销售周期长度，四个变量均为独立诊断杠杆；**质量调整覆盖度**（$5M 含 20 个陈旧 Deal 的 Pipeline 价值低于 $2M 含 8 个活跃 Deal 的 Pipeline）；**MEDDPICC Deal 健康评分**（资格深度 + 互动强度 + 进展速度三维度 0-36 分综合评分）；**多信号预测模型**（历史转化 + Velocity 加权 + 互动调整 + 季节性模式 + AI 模式匹配）。预测输出 Commit（>90%）/Best Case（>60%）/Upside（<60%）三档而非单一数字。关键原则：晚期阶段 MEDDPICC 字段<5/8 的 Deal 是预测失误的主要来源；单线程 + 无 EB 接触 + 20+ 天无会议 = 与上一季度 Closed-Lost 队列相同模式；30 天未更新的 Pipeline 应被标记审查；CRM 显示的 $12M Pipeline 调整后可能只有 $4.8M 有效。与 [[sales-deal-strategist]] 协同——后者关注单个 Deal 策略，前者提供全 Pipeline 层面的诊断和预测；与 [[sales-coach]] 共享 MEDDPICC 框架，但前者用于 Deal 质量评估，后者用于代表能力辅导。 - -**[[sales-engineer]]**（Sales Engineer Agent）：售前工程师 Agent，专注于在 B2B 技术评估中赢得技术决策——核心理念：技术决策先于商业合同，售前工程师必须将每一次技术对话连接到业务成果，而非单纯展示功能。核心能力：**Demo Engineering**（以影响力为导向的演示设计：先量化问题→展示结果→逆向讲解→证明收尾，以 [[AhaMoment]] 为核心成功标准）+ **POC Scoping**（严格限定的概念验证：成功标准明确写在开始前，2-3 周硬性时间线，中期检查点，防止范围蔓延）+ **FIA Framework**（Fact-Impact-Act 竞争定位框架，保持事实基础和可操作性，永远不攻击竞品）+ **技术异议解码**（识别"是否支持 SSO？"背后的真实关切是"能否通过安全审查"，从根源回应而非表面处理）+ **评估笔记维护**（结构化记录每个活跃交易的技术环境、决策者、竞争态势和演示策略）。成功指标：技术赢率 70%+，POC 转化率 80%+，演示到下一步行动率 90%+，中位数 18 天技术决策。与 [[sales-discovery-coach]] 在发现阶段技术深度参与度上存在张力——前者主张售前主导技术发现，后者主张销售发现以业务语言建立信任；与 [[sales-deal-strategist]] 共享竞争定位和 Winning/Battling/Losing 三区分析，但前者专注于技术评估层，后者覆盖全周期交易策略。属 The Agency Sales 团队完整销售闭环中的技术评估支柱。 - -### The Agency — Specialized 部门 - -**[[specialized-civil-engineer]]**（Civil Engineer）：全球设计标准覆盖的结构与土木工程专家 Agent——专注于安全、经济、可建造的结构设计，驾驭 Eurocode（EN 1990–1999 + 各国 National Annex）、ACI 318（LRFD/SD）、AISC 360、ASCE 7、GB、IS、AIJ 等全球主流建筑规范体系。核心能力：**ULS+SLS 双重验证**（承载力极限状态与正常使用极限状态必须同时满足方为合格）+ **多标准冲突处理**（IBC+Eurocode 混用时识别冲突→文档记录→保守优先→设计依据报告）+ **岩土工程**（地勘报告解读、承载力/沉降分析、挡土结构、边坡稳定）。计算交付物包括：钢梁 AISC 360 LRFD 计算包（截面选型→抗弯验算→挠度检查）、RC 梁 Eurocode EN 1992-1-1 计算包（K 法配筋设计→抗剪验算）、岩土地基 Terzaghi 承载力分析（含 EN 1997 DA1 验证）。六阶段工作流：项目范围→初步设计→详细计算→建造文档→规范合规→施工支持。属 The Agency Specialized 部门的基础设施工程方向，与 [[specialized-developer-advocate]]（开发者关系）同属 Specialized 专业 Agent 系列，与 [[specialized-workflow-architect]]（工作流架构）存在依赖关系。 - -**[[specialized-document-generator]]**（Document Generator）：专业文档生成专家 Agent——The Agency Specialized 部门的程序化文档生成专家，通过代码方式（Python/Node.js）生成 PDF、PPTX、DOCX、XLSX 等专业文档（投资者演示文稿、合规报告、数据密集型电子表格）。核心工具栈：PDF（reportlab/weasyprint/fpdf2）、PPTX（python-pptx/pptxgenjs）、XLSX（openpyxl/xlsxwriter/exceljs）、DOCX（python-docx/docx）。核心原则：**样式系统优先**（拒绝硬编码字体/字号，使用文档样式主题）、**品牌一致性**（颜色/字体/Logo 全局统一）、**数据驱动**（接受结构化数据输入生成文档输出）、**无障碍设计**（Alt 文本/标题层级/PDF 标签）、**模板可复用**（构建模板函数而非一次性脚本）。与 [[report-distribution-agent]]（文档分发）和 [[agents-orchestrator]]（工作流编排）协同，构成完整的文档从生成到分发的工作流。属 The Agency Specialized 部门的生产力工具方向，与 [[specialized-developer-advocate]] 同属专业工具 Agent 系列。 - -**[[government-digital-presales-consultant]]**（Government Digital Presales Consultant）：The Agency Specialized 部门的政府数字化售前专家——面向中国ToG（政府）市场，专注于数字政府、智慧城市、一网统管、城市大脑等主流方向的全生命周期售前支持。核心能力：政策解读（数字中国/国家数据局政策信号提取：区分"鼓励探索"与"全面实施"的政策成熟度判断）、合规架构（等保2.0三级/商用密码评估/信创适配）、招投标全流程（需求调研→方案设计→POC验证→标书撰写→述标答辩→中标交接）。五步工作流配合技术方案模板、等保合规矩阵、投标检查清单、机会评估模板等交付物。关键原则：**技术方案必须以业务场景驱动**（"市民服务处理速度提升80%"而非"微服务架构"）；**等保/密评/信创是强制项而非加分项**；方案至少经过三轮迭代打磨。成功指标：中标率>40%、零废标、售前到交付偏差<10%。与 [[sales-engineer]]（通用售前）互补——后者覆盖企业级B2B市场，前者专精中国政府ToG市场特有的政策合规与采购流程；与 [[Digital-Government]]（数字政府）和 [[Smart-City]]（智慧城市）构成完整的政府信息化知识体系。属 The Agency Specialized 部门的垂直行业方向。 - -**[[healthcare-marketing-compliance]]**（Healthcare Marketing Compliance Specialist）：The Agency Specialized 部门的医疗营销合规专家——覆盖中国医疗健康全品类（药品/医疗器械/医美/保健食品/互联网医疗）营销合规，深度熟悉《广告法》《医疗广告管理办法》《互联网广告管理办法》等核心法规体系。核心能力：医疗广告审查（《医疗广告审查证明》申请与合规）、处方药/OTC药广告分规管理、医疗器械三类分级合规（I类备案/II类注册/III类严格审批）、医美"容貌焦虑"红线防控、保健品"蓝帽子"标识管理、互联网诊疗合规（初诊必须线下面诊）、患者隐私 PIPL 合规（敏感个人信息须单独授权）、学术推广合规（医疗代表备案、会议赞助标准、医师讲课费规范）。关键原则：**合规不是"堵营销"，而是"保护品牌"**——一次违规处罚的代价远高于合规投入；**"事前审查"优于"事后补救"**——所有对外发布的医疗营销内容必须经过合规团队审核。成功指标：年度零监管处罚、平台违规 < 3次/年、100% 内容发布前合规审查覆盖率。属 The Agency Specialized 部门的合规垂直方向，与 [[government-digital-presales-consultant]]（政府合规）和 [[legal-compliance-checker]]（通用法律合规）共同构成完整的合规能力体系。 - -**[[blockchain-security-auditor]]**（Blockchain Security Auditor）：The Agency Specialized 部门的智能合约安全审计 Agent——专职发现 DeFi 协议与区块链应用中的漏洞，核心理念：**在攻击者之前找到漏洞**。核心方法：自动化静态分析（Slither/Mythril/Echidna）+ 人工逐行审查 + 属性化模糊测试 + 经济博弈建模；五步工作流（范围→自动化分析→人工审查→经济分析→报告）。核心原则：自动化工具只能捕获约 30% 的真实漏洞；每个发现必须包含可复现 PoC；使用 OpenZeppelin 不等于安全（误用安全库本身是漏洞类型）；必须验证代码与部署字节码一致（供应链攻击真实存在）。漏洞评级严格化：能导致用户资金损失的发现不得降级为 Informational。与 [[Agents-Orchestrator]] 构成审计质量门控——流水线交付前须通过安全审计；与 [[compliance-auditor]] 同属审计类 Agent，但前者聚焦代码层智能合约安全，后者聚焦企业合规认证体系（SOC 2/ISO 27001/HIPAA）。 - -**[[compliance-auditor]]**（Compliance Auditor）：The Agency Specialized 部门的专业技术合规审计 Agent——专注于 SOC 2、ISO 27001、HIPAA、PCI-DSS 等安全隐私认证的全流程指导，从准备评估到证据收集直至认证通过。与 Healthcare Marketing Compliance 侧重营销内容合规不同，Compliance Auditor 关注**技术控制体系**的审计准备。核心方法：五步工作流（Scoping → Gap Assessment → Remediation Support → Audit Support → Continuous Compliance）；核心原则：**不跟随的政策比没政策更危险**（Checkbox-Compliance 是反面教材）、**证据必须证明整个审计周期内持续有效**（而非仅当下存在）、**自动化证据收集从第一天建立**（手动流程无法扩展）、**技术控制优于管理控制**（代码比培训更可靠）。核心交付物：Gap Assessment Report（差距评估报告）、Evidence Collection Matrix（证据收集矩阵）、Policy Template（策略模板）。成功指标：零不合格发现（zero adverse findings）、审计周期缩短 30%、年度合规状态持续可查。与 [[specialized-model-qa]] 互补——后者审计 AI/ML 模型质量，前者审计组织整体安全控制，两者共同构成完整的技术合规审计体系；与 [[automation-governance-architect]] 协同——自动化证据收集需依托 Governance Architect 设计的 AI 系统治理框架。 - -|**[[specialized-workflow-architect]]**（Workflow Architect）：工作流设计专家 Agent——The Agency Specialized 部门的工作流设计与系统建模专家，在代码编写前对系统所有路径进行穷举建模。核心职责：**工作流发现**（扫描 route/worker/migration/IaC/cron 文件找出隐式工作流）+ **工作流注册表维护**（四视角：按工作流/按组件/按用户旅程/按状态）。核心交付物：**工作流树规范格式**（含 Actor/Prerequisites/Trigger/Step 树/ABORT_CLEANUP/State Transitions/Cleanup Inventory/Test Cases/Assumptions），覆盖快乐路径+七类失败分支（输入验证/超时/瞬态/永久/部分失败/并发冲突）。关键原则：**不只为快乐路径设计**、**每个系统边界定义显式 Handoff Contract**（payload schema + 成功/失败响应 + 超时值 + 恢复动作）、**Reality Checker 验证是 Draft 升为 Approved 的前置条件**。Agent 协作协议：Reality Checker 验证规范→Backend Architect 实现代码→API Tester 生成测试用例→DevOps Automator 验证清理顺序。属 The Agency Specialized 部门的质量保障基础设施，与 [[specialized-civil-engineer]]（基础设施工程）同属 Specialized 专业 Agent 系列。 - -**[[corporate-training-designer]]**（Corporate Training Designer）：The Agency Specialized 部门的企业培训体系架构师与课程开发专家——专注企业级培训需求分析、ADDIE/SAM 教学设计模型、混合学习项目、内训师培养（TTT）、领导力发展（HIPO）及 Kirkpatrick 四级培训效果评估。核心价值观：**优秀培训的衡量标准不是"教了什么"，而是"学员回去做了什么"**。关键方法：ADDIE 模型（分析→设计→开发→实施→评估）、Bloom 认知六层次、Kirkpatrick 四级评估（反应→学习→行为→业务结果）、Kolb 体验式学习圈、OMO 混合学习（线上"认知"→线下"实践"→社群"持续"）。与 [[specialized-workflow-architect]]（工作流设计）和 [[cultural-intelligence-strategist]]（跨文化产品设计）形成系统性设计能力互补——分别应用于组织学习、软件工程和文化包容三大领域，共同构成 [[The Agency]] 的系统性设计矩阵。 - -**[[cultural-intelligence-strategist]]**（Cultural Intelligence Strategist）：文化包容性专家 Agent——The Agency Specialized 部门的文化智能策略师，专门检测和消除软件开发中的"隐性排斥"（Invisible Exclusion）。核心方法：**四阶段工作流**（盲点审计→自主研究→结构修正→解释原理）。典型案例：刚性 First Name / Last Name 字段在 APAC 市场失效（改为 Full Name 或 Preferred Name）；中国金融应用中红色表示"上涨"而非"错误"（需辅以文字/图标说明）；RTL 阅读方向、多日历系统、不同文化隐私期望等全局包容性设计。核心原则：**国际化是架构前提条件，而非亡羊补牢**；**拒绝表演性多元化**——仅在首页放多元人群图但产品流程本身仍具排斥性不可接受。核心价值：将文化智能（CQ）从"后期本地化补丁"提升为"架构级前提条件"。与 [[InclusiveVisualsSpecialist]]（包容性视觉）互补——前者覆盖整个产品工作流（含表单、交互、颜色语义），后者专注于 AI 生成图像的表征偏见消除；与 [[design-brand-guardian]] 在特定市场语境下存在张力——品牌一致性要求与为不同市场调整视觉语义的必要性需要平衡。 - -**[[specialized-model-qa]]**（Model QA Specialist）：ML/统计模型端到端独立审计专家——The Agency Specialized 部门的模型质量保障专家，核心使命：**将模型视为"有罪推定"，直到全面审计证明其可靠性**。独立于模型构建者运行，通过证据驱动的分析发现模型在文档、数据、特征、性能、校准、可解释性、公平性等各环节的问题，并量化业务影响。核心方法：10 大审计领域覆盖模型全生命周期（文档治理→数据重建→标签分析→分段评估→特征分析→模型复制→校准测试→性能监控→可解释性→业务影响），配套完整 Python 工具集（PSI 监控、Hosmer-Lemeshow 校准检验、SHAP 可解释性分析、PDP 偏依赖图、KS/AUC/Gini 判别指标）。核心原则：**独立性**（永远不审计自己参与构建的模型）、**可复现性**（每个分析必须产出可执行脚本）、**证据链完整**（每个发现必须包含观察→证据→影响评估→建议）。成功指标：审计发现 95%+ 被模型所有者确认为有效、零部署后失败。属 The Agency Specialized 部门的质量保障垂直方向，与 [[specialized-workflow-architect]]（工作流设计中的 Reality Checker 验证）互补——后者验证系统行为符合规范，前者验证 ML/统计模型符合质量标准，共同构成 [[The Agency]] 的全栈质量保障体系。与 [[multi-agent-system-reliability]] 存在潜在张力：对抗辩论模式通过架构约束弥补 LLM 不可靠性（概率性），而 Model QA 要求确定性统计证据链。 - -**[[lsp-index-engineer]]**（LSP/Index Engineer）：代码智能系统架构师 Agent——The Agency Specialized 部门的 LSP 客户端编排和语义图谱构建专家，通过 graphd LSP 聚合器将 TypeScript/PHP/Go/Rust/Python 等多语言 LSP 客户端统一编排为语义图谱，为沉浸式代码可视化提供基础设施。核心交付物：多语言 LSP 并发编排 + 统一图谱模式（节点：文件/符号，边：contains/imports/calls/refs）+ nav.index.jsonl 语义索引 + WebSocket 实时增量推送 + 原子性图谱更新保证。核心原则：**严格遵循 LSP 3.17 规范**（永远检查服务器能力而非假设）、**图谱一致性约束**（每个符号有且仅有一个定义节点，所有边引用有效节点 ID）。性能北极星指标：/graph <100ms、/nav <20ms（缓存）/60ms（未缓存）、WebSocket <50ms、内存 <500MB、100k+ 符号无性能降级。TypeScript 和 PHP 支持为**默认生产就绪要求**。与 [[specialized-workflow-architect]] 存在张力：LSP/Index Engineer 要求确定性图谱一致性（"Reference edges must point to definition nodes"），而 Workflow Architect 承认穷举建模存在 LLM 概率性上限——协调方向：两者作用于不同抽象层次，符号层面需确定性约束，行为工作流层面允许概率性处理。与 [[multi-agent-system-reliability]] 共享对"架构约束优于提示词约束"的认同。 - -**[[study-abroad-advisor]]**（Study Abroad Advisor）：留学申请规划专家 Agent——The Agency Specialized 部门的全链路留学申请规划专家，面向中国学生，覆盖美国/英国/加拿大/澳大利亚/欧洲/香港/新加坡七大目的地，涵盖本科/硕士/博士全学位层次。核心理念：**数据驱动、零焦虑贩卖**——GPA 3.2 进入 Top 30 的案例与 GPA 3.9 全拒的案例并存，关键变量是选校策略和文书质量。核心方法：四步工作流（全面诊断→策略制定→材料打磨→提交跟进）+ 多国联申时间线协调；标准化交付模板（选校报告、多国申请时间线、文书诊断框架、Offer 比较矩阵）。诚信原则：不代写文书、不承诺录取结果、明确区分"确认信息"与"经验估算"。属 The Agency Specialized 部门的垂直服务方向，与 [[corporate-training-designer]]（企业培训）同属服务型 Agent，但前者面向 B2C 个人消费者，后者面向企业组织。 - -**[[specialized-french-consulting-market]]**（French Consulting Market Navigator）：法国 IT 咨询市场生态导航专家——The Agency Specialized 部门的法国 ESN/SI（Entreprise de Services Numériques）自由职业者策略 Agent，专帮助独立 IT 顾问最大化日均费率（TJM）、最小化回款风险、建立可持续客户关系。核心理念：**理解 ESN Margin 架构是谈判关键**；永远区分 TJM 毛收入（brut）与税后净收入（net）。核心方法：ESN 分层定价架构（Tier 1 全球型 Margin 35-50%、Tier 2 专项型 25-40%、Tier 3 经纪型 15-25%）+ 五平台对比矩阵（Malt/collective.work/Comet/Crème/FreeWork）+ TJM 阶梯锚定谈判四步法（Floor计算→Sell Rate反推→分层锚定→条件让步）。关键区分：Portage Salarial 税后净得约 50% TJM（700€/天 → ~300-330€ 净），Micro-Entrepreneur 净得约 70%（~420-450€），338€/天差价是社保保护（ARE失业保险、退休金补充）的价格。国际顾问策略：主动披露位置+时区覆盖价值重构替代隐瞒。属 The Agency Specialized 部门的垂直市场专家方向，与 [[specialized-korean-business-navigator]]（韩国市场导航）同属区域市场进入策略 Agent。 - -**[[specialized-korean-business-navigator]]**（Korean Business Navigator）：韩国商业文化导航专家——The Agency Specialized 部门的韩国市场进入 Agent，专帮助外国专业人员解码韩国商业隐性规则，将西方直接性与韩国关系动态相结合。核心理念：**韩国"yes"不一定是同意，沉默是信息，成交发生在会议室外的走廊**。核心洞察：품의（共识审批）流程耗时 6-16 周（SME 6-10、中型 8-12、财阀 12-16），远长于西方的 2-4 周，永远不要在第一次会议要求决策时间线；永远不要绕过联系人越级上报；KakaoTalk 群聊必须使用韩语；永远不要在第一次对话中谈钱（关系→能力→价格三阶段）；회식（商务聚餐）出席是预期而非可选。关键方法：六阶段 품의时间线（소개→미팅→내부검토→품의서→결재→계약）、Nunchi 解码表（"검토해보겠습니다"实际意为"婉拒"）、分阶段 KakaoTalk 消息模板、韩国企业职级体系（회장→대리十级）、Proof Project 策略（有边界小项目降低感知风险）。与 [[cultural-intelligence-strategist]] 同属跨文化领域 Agent，但前者聚焦韩国单一市场，后者覆盖全球包容性设计；与 [[specialized-french-consulting-market]] 同属区域市场进入策略 Agent，共に构成 The Agency 的全球区域化服务能力。 - -**[[supply-chain-strategist]]**（Supply Chain Strategist）：中国制造业供应链管理与战略采购专家 Agent——The Agency Specialized 部门的供应链全链路专家，基于中国制造业生态，帮助企业建立高效、有韧性、可持续的供应链体系。核心能力：供应商开发与分级管理（ABC 分类 + 战略合作伙伴升级）、Kraljic 矩阵采购类别策略、QCD 绩效评分体系（全季度评分年度淘汰）、TCO 全成本分析（直接/间接/隐性/全生命周期成本）、库存优化模型（EOQ/ROP/安全库存/VMI/JIT）、供应链数字化成熟度评估（L1 手动 → L5 自主智能）。采购渠道覆盖 1688/阿里巴巴、中国制造网、广交会、企查查企业核验等全渠道。合规能力：RBA 行为准则、SA8000 社会责任审计、碳足迹追踪、冲突矿产合规（CMRT）、ISO 14001/REACH/RoHS。关键原则：**关键物料禁止单一来源**；**TCO 是采购决策依据而非单价**；**质量问题必须追溯根本原因**。典型成就：紧固件品类年采购成本通过整合采购降低 12%，节省 ¥870,000。与 [[specialized-french-consulting-market]] 同属 Specialized 部门垂直领域 Agent，分别覆盖供应链管理和法国市场咨询两个不同专业方向。 - -**[[data-consolidation-agent]]**（Data Consolidation Agent）：销售数据整合专家 Agent——The Agency Specialized 部门的战略数据整合专家，将分散的销售提取数据聚合为实时仪表盘。核心理念：**将原始销售指标转化为可操作的实时决策视图**。核心能力：并行多维度查询（地区/代表/管道/时间维度）、实时达成率计算（revenue / quota * 100，处理除零错误）、MTD/YTD/Year End 多时间视图、< 1 秒仪表盘加载 + 60 秒自动刷新。交付物：Dashboard Report（地区业绩摘要 + 代表排名 + 管道快照 + 6 个月趋势 + Top 5 业绩者）和 Territory Report（地区级深度分析，含所有代表指标及最近 50 条历史记录）。关键原则：**始终使用最新数据**（按 type 取最新 metric_date）；**零数据不一致**（明细与汇总视图完全一致）。与 [[sales-data-extraction-agent]]（上游数据提取）和 [[report-distribution-agent]]（下游分发）构成销售数据管道；与 [[sales-pipeline-analyst]] 共享数据源但职责互补（整合 vs 分析）；与 [[sales-coach-agent]] 协同提供 Top 5 业绩者洞察。属 [[Multi-Agent-System-Reliability]] 的数据层实践，为多 Agent 销售系统提供统一数据视图。 - -**[[report-distribution-agent]]**（Report Distribution Agent）：销售报告自动分发专家 Agent——The Agency Specialized 部门的报告分发协调专家，基于区域参数将合并报告精准送达对应业务员和管理层。核心理念：**确保正确的报告在正确的时间到达正确的人**。核心原则：区域路由（业务员仅收到其负责区域的数据）、管理层接收公司级汇总报告、每次分发均记录状态和时间戳（sent/failed）、工作日 8:00 AM 定时日报、周一 7:00 AM 周报、失败时记录错误并继续分发。交付物：HTML 格式区域报告（业务员表格）、公司汇总报告（区域对比表格）、分发日志（接收人/区域/状态/时间戳）。关键指标：99%+ 定时送达率、零区域错误分发、失败发送 5 分钟内识别。核心工作流：定时触发→查询区域和代表→生成报告（调用 Data Consolidation Agent）→HTML 格式化→SMTP 发送→分发日志记录→UI 展示历史。与 [[data-consolidation-agent]] 构成数据管道（整合→分发）；与 [[specialized-document-generator]]（文档生成）协同——生成报告的内容由 Document Generator 提供结构，分发层负责路由和传输。属 [[Multi-Agent-System-Reliability]] 的分发层实践。 - -**[[specialized-developer-advocate]]**（Developer Advocate）：开发者关系工程师 Agent——The Agency Specialized 部门的开发者体验与社区运营专家，通过提升 DX、技术内容创作、社区运营将产品与外部开发者紧密连接，最终推动平台采用和商业价值增长。核心理念：**Authentic 技术参与，而非商业推销**——"You don't do marketing — you do developer success." 核心洞察：**DX 改善复合效应永远优于快速内容发布**，修复前 3 大 DX 问题再发布任何新教程；**真实性是核心资产**，AstroTurf（虚假社区参与）永久性摧毁开发者信任。核心方法：DX 工程审计（Time-to-First-Success 三阶段评分）→ 技术内容创作（教程/演示/演讲提案/Dev Survey）→ 社区运营（GitHub Issue ≤24h 响应、Hackathon/Ambassador Program）→ 产品反馈闭环（月度 Voice of Developer 报告）。关键原则：**先听后创**（30天 GitHub Issue → Stack Overflow → 社交媒体 → 开发者调查）；**内容必须有可运行代码**；**5人大会 Q&A = 数千无声障碍推断**。成功指标：首次成功 ≤15min、GitHub 响应 ≤24h、教程完成率 ≥50%、开发者 NPS ≥8/10。与 [[automation-governance-architect]] 互补（DevRel 关注外部开发者体验，治理架构师关注内部自动化质量）；与 [[specialized-mcp-builder]] 协同（MCP Builder 的 DX 改善依赖 Developer Advocate 的 DX 原则）；与 [[specialized-workflow-architect]] 存在设计哲学张力：前者优先 DX 质量再发布内容，后者优先快速交付功能后迭代。属 The Agency Specialized 部门的技术运营方向。 - -## Conflict Areas - -1. **Kanban vs Event Sourcing**: Kanban emphasizes visual team collaboration; Event Sourcing emphasizes auto-tracking and context preservation. **[[Project State Management]]**（事件驱动看板替代方案）vs 传统 PM 工具。核心差异：手动拖拽 vs 自然语言输入；静态快照 vs 全历史保留；无上下文 vs 完整决策链。**[[Event Sourcing]]** 在此上下文中指将项目变更存储为事件序列，每次 progress/blocker/decision/pivot 均持久化，保留完整决策上下文。 - -2. **MEDDPICC 维度数量**：MEDDPICC 有 8 个维度（Metrics/Economic Buyer/Decision Criteria/Decision Process/Paper Process/Implicated Pain/Champion/Competition），但早期摄入的 [[sales-coach]] 描述为"六个维度"。已于本次摄入中修正为八维度，后续应避免再次引用旧的六维度描述。 - -3. **Kuaishou vs Douyin**: Kuaishou emphasizes authenticity and balanced algorithm; Douyin emphasizes polished content and central recommendation. Same country, opposite platform strategies. - -4. **Micro-Enterprise vs Portage Salarial**: Micro-enterprise yields higher net income but lacks social protections; Portage Salarial costs more but includes unemployment insurance, pension, mutuelle. Financial trade-off vs social safety net. - -5. **CI/CD Build Output**: SECURITY.md says build output is always closed; GitHub Actions best practice says certain generated files should be committed for reproducibility. Reproducibility vs cleanliness tension. - -6. **Sales Engineer vs Sales Discovery Coach（技术发现参与深度）**：Sales Engineer Agent 主张售前工程师应在技术发现阶段主导参与，结构化挖掘架构、集成、安全约束和真实技术决策标准；Sales Discovery Coach Agent 主张销售发现应以业务语言建立信任，深度技术探索由专门时机负责。协调方向：在发现阶段早期以业务语言建立信任，进入评估阶段后切换为技术深度模式。详见 [[sales-engineer]] Contradictions 部分。 - -7. **路由器科学上网 vs VPS科学上网 vs NAS科学上网 vs Server终端代理**：四层方案各有适用场景。[[网件RAX50刷梅林固件与科学上网]] 路由网关方案（[[MerlinClash插件]]）→ 全屋透明代理，无需客户端配置；[[3X-UI Xray on BandwagonVPS]] VPS服务端方案（[[3X-UI]] + [[Xray]]）→ 集中式代理节点，可扩展；[[群晖NAS科学上网]] NAS 代理方案（V2RayA 透明代理）→ 覆盖 NAS 本身及容器；[[ubuntu-server科学上网]] Server 终端代理方案（[[ProxyChains]] + [[Git 全局代理]] + [[Docker Daemon Proxy]]）→ 仅覆盖该 Server 本身。最佳实践：路由器作为主网关（[[MerlinClash插件]]），VPS作为代理节点池（订阅机制），NAS 按需透明代理，Server 终端按工具单独配置。**额外洞察**：在群晖 DSM 7.x 和 Ubuntu Server 中，V2RayA/透明代理不一定对 Docker Daemon 生效，**显式配置 Docker Daemon Proxy 环境变量**（systemd drop-in 文件）比依赖透明代理更可靠。 - -8. **Prometheus 监控 vs OpenTelemetry**：Prometheus 生态成熟、部署简单，适合家庭服务器和小型集群；OpenTelemetry 是云原生可观测性新标准（metrics/traces/logs 三合一），长期可考虑迁移路径但学习成本高。[[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] vs [[ctp-topic-67-cloud-native-observability-using-opentelemetry]]。 - -9. **Netdata vs Prometheus**：Netdata 开箱即用适合实时短期诊断（默认 19999 端口），Prometheus + Grafana 适合长期存储和趋势分析。两者可互补使用：Netdata 做快速排查，Prometheus 做 SLA 报表和历史分析。 - -10. **macOS vs Linux 睡眠管理**：macOS 使用 `pmset` 命令配置电源管理（sleep/displaysleep/standby/hibernatemode），Linux/Ubuntu 使用 `systemd-logind` 的 `HandleLidSwitch=ignore` 配置。两者目标相同（防止服务器睡眠），但工具链完全不同，不可互换但互为参考。[[mac-mini-服务器配置-防止自动锁屏与睡眠]] vs [[ubuntu禁用合盖休眠]]。 - -11. **Healthcare Marketing Compliance vs 通用法律合规**：医疗营销合规 Agent 主张医疗领域具有高度专业化特征（《广告法》/药械注册/平台规则），通用法律合规工具无法覆盖；[[legal-compliance-checker]] 主张合规 Agent 应具备跨行业通用框架，无需细分至医疗领域。**协调方向**：通用合规 Agent 负责数据隐私/合同合规等横向能力，医疗营销合规 Agent 专注垂直领域规则差异（详见 [[healthcare-marketing-compliance]] Contradictions 部分）。 - -12. **LSP 图谱确定性 vs Workflow 穷举概率性**：LSP/Index Engineer 要求确定性图谱一致性（"每个符号必须有且仅有一个定义节点"，"Reference edges must point to definition nodes"），强调 LSP 3.17 协议规范和原子性图谱更新；[[specialized-workflow-architect]] 承认穷举工作流建模存在 LLM 概率性上限，某些边界条件只能通过概率性处理。**协调方向**：两者作用于不同抽象层次——符号层面（静态代码分析）需确定性约束，行为工作流层面（系统边界交互）允许概率性处理，可共存（详见 [[lsp-index-engineer]] Contradictions 部分）。 - -13. **数据库备份方案**：pg_dump 逻辑备份 vs rsync 文件级备份。pg_dump 是热备份标准（零停机、跨平台迁移能力强），但不能备份运行中数据库的物理文件目录；rsync 适合 Docker 卷备份但需确保数据库一致状态。[[MinIO + Zipline 图床安装]] 使用 pg_dump 逻辑备份 PostgreSQL + Hyper Backup 文件备份 MinIO 目录，两者互补。 - -14. **SuperCall 沙盒 Persona vs 通用语音 Agent**：[[event-guest-confirmation]] 中使用的 [[SuperCall]] 强调独立沙盒设计——AI persona 只持有预设的 persona name、goal、opening line，无法访问外部系统；[[phone-based-personal-assistant]] 侧重通用个人助手场景，需要访问更多上下文。**[[Sandboxed Persona]]** 适用于确认类单一任务（安全、无注入风险）；通用语音 Agent 适用于需要跨系统协调的复杂助手场景。 - -15. **Agent 去电通知 vs Agent 来电接收**：[[phone-call-notifications]] 中 Agent 主动向用户拨打电话通知（Agent → User），通话由 Agent 触发，用户是被动接收方；[[phone-based-personal-assistant]] 中用户主动呼叫 Agent（User → Agent），Agent 接听并提供助理服务。两者方向相反但互补——前者用于紧急告警、定时简报、重要事件通知，后者用于随时咨询、查询、执行任务。共同构成完整语音双向通信能力。 +# Overview + +This wiki is a living synthesis of curated sources spanning AI agents, cloud infrastructure, DevOps, productivity tools, and home server automation. + +## Major Themes + +### Multi-Agent AI Systems +The wiki covers two major multi-agent frameworks: **The Agency** (agency-agents) and **OpenClaw**. The Agency provides 147 specialized agents across 12 business divisions (Engineering, Design, Finance, Game Dev, Marketing, Paid Media, Product, Project Management, Testing, Support, Spatial Computing, Specialized). OpenClaw focuses on autonomous agents with persistent memory and workflow orchestration via n8n. + +**The Agency 贡献指南**（[[contributing_zh-cn]] + [[contributing]] 英文原版）：The Agency 项目贡献者指南——核心贡献方式：①创建全新智能体（8大分类：engineering/design/marketing/product/project-management/testing/support/spatial-computing/specialized）；②优化现有智能体；③分享成功案例；④反馈问题。智能体设计五原则：**鲜明性格**（拒绝通用人设）、**明确交付物**（真实代码/模板）、**可量化指标**、**经过验证的工作流**、**学习记忆机制**。PR 流程包含提交前检查（真实场景测试、遵循模板、补充示例）、社区评审与迭代优化。属 [[Multi-Agent-System-Reliability]] 的智能体设计规范层，为 [[Multi-Agent-Team]] 提供标准化的智能体创建框架。 + +**[[AI Citation Strategist]]**（AI Citation Strategist Agent）：专注于 AI 推荐引擎优化（AEO/GEO）的营销 Agent——审计品牌在 ChatGPT、Claude、Gemini、Perplexity 四大 AI 平台上的引用可见性，识别竞争对手被引用的原因，生成 Fix Pack 改善内容信号。与 [[Marketing SEO Specialist]] 互补但独立——传统 SEO 成功不能自动转化为 AI 可见性，AEO 与 SEO 必须作为不同策略对待。核心方法：多平台 Citation Audit Scorecard → Lost Prompt Analysis → 竞品内容结构映射 → Schema markup + 实体信号优化 → Fix Pack 优先级实施。与 [[Marketing Agentic Search Optimizer]] 同属 AI 驱动的内容可见性优化方向。属 [[Multi-Agent-System-Reliability]] 的营销 Agent 设计层。 + +**[[nexus-spatial-discovery]]**（Nexus Spatial Discovery Exercise）：8个 The Agency 专业 Agent 并行协作完成 AI 空间指挥中心产品完整规划的实战案例——10分钟 wall-clock time 产出完整规划。参与 Agent：产品趋势研究员（市场验证 + Vision Pro 现实核查）、后端架构师（8服务 Rust 架构）、品牌守护者（定义 [[SpatialAIOps]] 新品类）、增长黑客（3阶段 GTM + 增长飞轮）、支持应答者（AI 内嵌空间的差异化支持设计）、UX 研究员（识别调试为杀手级用例）、XR 界面架构师（命令剧院 + 7态节点系统）、项目牧羊人（35周时间线 + 5团队分配）。跨 Agent 独立共识：2D先行（WebXR分发） > VisionOS、品牌 > 调试 > 战情室协作 > 渐进披露。核心张力：Growth Hacker（$29-59）与 Trend Researcher（$99-249）定价分歧待 A/B 测试。属 [[Multi-Agent-System-Reliability]] 的多 Agent 协作规划层实践，展示了并行 Agent 发现可产出连贯、相互引用的完整计划。与 [[Multi-Agent-Team]]（单团队多 Agent 架构）和 [[Agents-Orchestrator]]（流水线编排）同属多 Agent 协作模式的不同维度。 + +**[[workflow-landing-page]]**：多 Agent 一天冲刺工作流——展示 Landing Page 场景下 4 个核心设计模式：**[[Parallel-Kickoff]]**（Content Creator + UI Designer 上午并行启动）、**[[Merge-Point]]**（Frontend Developer 等待两者完成）、**[[Feedback-Loop]]**（Growth Hacker 审查后 Frontend Developer 修改）、**[[Time-Boxing]]**（每个阶段严格时间盒：09:00→16:30）。与 [[workflow-startup-mvp]] 互补——后者以周为单位的长周期迭代，本工作流是单日冲刺的具体化实现。与 [[design-ui-designer]] 和 [[design-brand-guardian]] 共享 UI Designer 角色。 + +**GitHub Copilot Integration**（[[github-copilot]]）：The Agency 与 GitHub Copilot 的开箱即用集成——无需转换，Agency 的 `.md` + YAML frontmatter 格式与 GitHub Copilot 原生兼容。通过 `./scripts/install.sh --tool copilot` 一键安装，或手动复制到 `~/.github/agents/` 或 `~/.copilot/agents/` 目录。用户可在任意 Copilot 会话中通过名称激活特定 agent，如 `"Activate Frontend Developer and help me build a React component."`。与 [[readme|Cursor Integration]] 互补——后者项目级别生效，Copilot Integration 用户级别全局生效，共同构成 [[The Agency]] 的多 IDE 集成生态。 + +**Windsurf Integration**（[[windsurf-integration]]）：The Agency Agent roster 与 Windsurf 编辑器的集成方案——通过 `.windsurfrules` 文件将全部 Agent roster 聚合为单一规则文件，install.sh 脚本从项目根目录安装，项目级生效。Windsurf 中在 prompt 里按名称引用 Agent 即可激活（如 "Use the Frontend Developer agent to build this component."）。与 [[Cursor Integration]]（.mdc 规则）和 [[Aider Integration]]（CONVENTIONS.md）同为项目级 IDE 集成，机制相似，共同构成 The Agency 的多 IDE 覆盖体系。[[integrations-readme]] 已覆盖所有 11 种集成工具的概览。 + +**Antigravity Integration**（[[antigravity-integration]]）：The Agency Agent roster 与 Antigravity/Gemini 的集成方案——通过 `./scripts/install.sh --tool antigravity` 将全部 Agent roster 转换为 Antigravity SKILL.md 文件，复制到 `~/.gemini/antigravity/skills/` 目录。所有 skill slug 统一使用 `agency-` 前缀（如 `agency-frontend-developer`）以避免与 Antigravity 原生 skills 冲突。用户可通过 `"Use the agency-frontend-developer skill to review this component."` 激活对应 agent。与 [[Cursor Integration]]（.mdc 规则）和 [[Windsurf Integration]]（.windsurfrules）同属多 IDE/平台集成，共同构成 The Agency 的完整集成生态，覆盖 Cursor（VS Code 兼容）、Windsurf、Copilot（用户级）和 Antigravity（Gemini）四大平台。 + +**Kimi Code CLI Integration**（[[kimi]]）：The Agency 与 Kimi Code CLI 的集成方案——通过 `./scripts/convert.sh --tool kimi` 将所有 agent 转换为 `agent.yaml`（规范定义）+ `system.md`（系统提示词）的目录结构，再通过 `./scripts/install.sh --tool kimi` 安装到 `~/.config/kimi/agents/`。使用 `--agent-file` 标志激活特定 agent，支持 `extend: default` 继承 Kimi 内置 default agent 的工具集。与 [[readme|Cursor Integration]] 和 [[github-copilot]] 同属 The Agency 的多 IDE/CLI 集成生态，Kimi Code CLI 由 Moonshot AI 出品，与 Claude Code 形成竞争。 + +**OpenCode Integration**（[[readme|OpenCode Integration]]）：The Agency Agent roster 与 OpenCode 编辑器的子 Agent 集成方案——通过 `./scripts/install.sh --tool opencode` 安装，将 The Agency 的 .md 文件格式 Agent 转换为 OpenCode 的 `.opencode/agents/` 目录格式。核心机制：在 YAML frontmatter 中添加 `mode: subagent` 使 Agent 仅在 `@agent-name` 触发时出现，不会在 Tab 循环列表中占位；颜色通过命名颜色到十六进制的自动映射实现。支持两种安装范围：项目级（`.opencode/agents/`）和全局级（`~/.config/opencode/agents/`）。与 [[readme|Cursor Integration]]（.mdc 规则）、[[github-copilot]]（用户级 Copilot）、[[windsurf-integration]]（.windsurfrules）同属 The Agency 的多 IDE 集成生态，[[integrations-readme]] 已覆盖所有集成工具概览。 + +**MCP Memory Integration**（[[mcp-memory-integration]]）：The Agency 的 MCP Memory 集成方案——通过在 Agent 提示词中加入标准化的 Memory Integration 段落，为任意 Agent 赋予跨会话持久记忆能力，无需修改 Agent 代码。MCP Memory Server 提供四个核心工具：`remember`（存储决策/交付物快照）、`recall`（跨会话检索）、`rollback`（失败时回滚到上一个检查点）、`search`（跨 Agent 搜索记忆）。**Rollback 是杀手级功能**——当 QA 检查失败或架构决策出错时，直接恢复到已知良好状态而非从头重建。标签一致性是关键：每个记忆使用 Agent 名称和项目名称作为标签，确保 recall 可靠。与 [[specialized-mcp-builder]]（构建 MCP Server）和 [[ai-memory-tools-two-camps]]（AI 记忆工具全景分类）同属 The Agency MCP 生态的核心组成部分。 + +**Backend Architect with Memory**（[[backend-architect-with-memory]]）：The Agency 中具备持久记忆能力的后端架构师 Agent——专门负责可扩展系统设计、数据库架构、API 开发与云基础设施。核心记忆机制：会话启动时检索 `backend-architect` + 项目名标签的历史记忆，防止重复讨论已做决策；架构决策以标签化快照持久化；交付物完成后主动标记接收方供下游 Agent 查找；QA 失败时检索最近良好检查点回滚。作为 [[agents-orchestrator]] 调度的具体执行 Agent，通过 MCP Memory 实现多 Agent 协作中的上下文连续性。 + +**[[engineering-software-architect]]**（Software Architect）：软件架构与系统设计专家 Agent——设计可维护、可扩展、符合业务领域的系统架构。核心理念：**"Designs systems that survive the team that built them."** 最佳架构是团队能实际维护的架构，反对过度设计。核心设计哲学：①权衡优先于最佳实践——命名所放弃的，而非仅列举所获得的；②领域优先、技术其次——理解业务问题再选工具；③可逆性优先于"最优"决策；④记录决策（WHY）而非仅记录设计（WHAT）。核心方法：ADR（Architecture Decision Record）标准化模板，捕捉 Context/Decision/Consequences 三要素；C4 模型分层沟通（Context/Container/Component/Code）；架构模式选型矩阵（Modular Monolith/Microservices/Event-Driven/CQRS 各自适用场景与规避条件）；质量属性分析（可扩展性/可靠性/可维护性/可观测性）。与 [[backend-architect-with-memory]] 在设计哲学上共享权衡优先、可逆性重要的核心价值观；在具体实现上，Backend Architect 侧重记忆持久化机制，Software Architect 侧重架构决策记录与模式选型；与 [[specialized-workflow-architect]] 在 ADR 使用上有协作关系。核心成功指标：每个关键决策均记录 ADR；所有权衡均有书面权衡分析；架构满足团队维护能力边界。 + +**[[engineering-mobile-app-builder]]**（Mobile App Builder）：移动应用开发专家 Agent——专注于原生 iOS/Android 开发和跨平台框架（Swift/SwiftUI、Kotlin/Jetpack Compose、React Native、Flutter）。核心理念：**平台感知、性能优先、用户体验驱动**。核心规范：遵循平台设计指南（Material Design / Human Interface Guidelines）；默认实现离线优先架构和智能数据同步；跨平台开发在代码复用与平台原生体验之间找到平衡。核心方法：MVVM 模式作为推荐架构；平台原生性能优化（冷启动 < 3 秒、内存 < 100MB、续航损耗 < 5%/小时）；生物识别认证（Face ID/Touch ID/指纹）、推送通知（APNs/Firebase）等平台特定功能集成。与 [[software-architect]] 共享系统架构思维应用于移动端；与 [[unity-architect]] 在跨平台理念上有分工——前者面向通用移动应用，后者面向游戏；与 [[visionos-spatial-engineer]] 和 [[xr-immersive-developer]] 共同构成 Apple 生态和 XR 领域的移动开发扩展。属 The Agency Engineering 部门。 +**[[workflow-with-memory]]**（Multi-Agent Workflow: Startup MVP with Persistent Memory）：[[workflow-startup-mvp]] 的增强版——通过 MCP Memory Server 将手动复制粘贴交接升级为自动召回，实现"记忆服务器作为粘合剂"。核心机制：`remember` 存储 Agent 交付物（带项目名 + 接收方标签）、`recall` 自动召回上下文（无需人工粘贴）、`rollback` 回滚到上一个检查点（替代手动撤销）。Before/After 对比：手动交接（会话超时丢失 / 多 Agent 需重复编译上下文 / QA 失败需手动描述问题 / 跨多天项目需重建上下文）→ Memory 模式（跨会话持久 / 按标签共享 / 自动回滚 / 每次 pick up 继续）。核心标签策略：所有记忆用项目名标签（如 retroboard），交付物额外用接收 Agent 标签（如 frontend-developer），这是 recall 正常工作的前提。Rollback 是 QA 失败恢复的核心：回滚到检查点而非手动追踪变化。与 [[workflow-startup-mvp]] 的关系：两者不冲突，Memory 模式是原始工作流的增强层——Memory Server 可用时自动召回；不可用时沿用原始工作流的手动粘贴策略。 + +**[[multi-channel-assistant]]**：基于 [[OpenClaw]] 的多渠道个人助理方案——以 Telegram Topic 路由为统一入口，整合 Google Workspace（gog）、Slack、Todoist、Asana，实现"说一句话完成全套工作"。核心价值：消除应用切换疲劳，AI 主动推送定时提醒（如每周垃圾清理、公司周报）。 + +**[[phone-based-personal-assistant]]**：通过 ClawdTalk + Telnyx 将任意手机变成 AI 助理语音入口——拨打电话即可与 [[OpenClaw]] 对话，支持日历查询、Jira 任务更新、网络搜索等技能，无需智能手机 App 或浏览器，覆盖驾驶、步行等双手占用场景。与 [[multi-channel-assistant]] 互补：文字入口覆盖图文交互，语音入口覆盖无屏场景。 + +**[[phone-call-notifications]]**：AI Agent 通过 [[clawr.ing]] 托管电话服务主动向用户拨打电话通知——Agent 评估事件优先级（股价暴跌/紧急邮件/日程提醒），自动拨叫用户真实号码，用户接听后可实时提问，Agent 双向对话响应。与 [[phone-based-personal-assistant]] 互补：后者为用户→Agent 的来电接收（用户主动呼叫），前者为 Agent→用户的去电通知（Agent 主动呼叫），共同构成完整语音双向通信能力。覆盖 100+ 国家 PSTN 电话，不存储录音，加密传输后即时销毁。 + +**[[multi-channel-customer-service]]**：基于 [[OpenClaw]] 的企业级多渠道 AI 客服统一收件箱——整合 WhatsApp Business、Instagram DMs、Gmail 和 Google Reviews 至单一 AI 驱动的收件箱，AI 自动识别消息意图（FAQ/Appointment/Complaint/Review）并匹配对应处理策略，语言自动检测匹配客户语言（ES/EN/UA），支持 Test Mode 演示而不影响真实客户。餐厅实测响应时间从 4+ 小时降至 2 分钟以内，80% 咨询自动处理。与 [[multi-channel-assistant]] 互补——后者面向个人助理多渠道入口，前者面向企业客服场景。 + +**Inbox De-clutter**：基于 [[OpenClaw]] 的 Newsletter 自动整理方案——每天 20:00 通过 Cron Job 阅读过去 24 小时的新邮件，生成精华摘要并附原文链接，根据用户反馈持续学习偏好。需前置 Gmail OAuth Setup。与 [[custom-morning-brief]] 属同一 Cron Job + AI 摘要模式的 Newsletter 垂直场景。与 [[email-triage]] 属同一方法论的不同实现。 + +**[[Second Brain]]**：基于 [[OpenClaw]] 的个人第二大脑记忆捕获系统——通过短信/Telegram/Discord 零摩擦捕获任何内容（\"Remind me to read a book...\"），OpenClaw 永久记忆存储所有对话，Next.js 可搜索仪表盘提供全局检索，Cmd+K 跨所有记忆/文档/任务全局搜索。核心价值：**捕获像发短信一样简单，检索像搜索一样简单**。无需文件夹、无需标签、无需复杂组织——文本加搜索足矣。OpenClaw 的累积记忆系统使 AI 随时间变得越来越强大，用户从手机发消息就能在电脑端构建内容。灵感来源：Alex Finn 的 YouTube 视频、Tiago Forte 的《Building a Second Brain》。 + +**Self-Improving 自改进系统**（[[养虾日记2]]）：解决 AI Agent"每次对话都是白纸"的核心问题——三层记忆架构（短期文件 + 长期向量数据库 + self-improving 复盘）配合每日 23:00 定时复盘，实现"错误只犯一次"的 Agent 学习闭环。Pattern-Key 重复是系统性问题的信号；Recurrence-Count 是区分一次性错误与重复问题的关键指标。[[Self-Improving-Skill]] 的 Suggested Action 必须具体到可直接执行（如 `--to 5038825565`），而非泛泛建议。 + +**[[养虾日记3]]**：用 Obsidian + Gitea 为 AI 助手构建持久化笔记系统——解决"AI 对话结束输出就消失"的核心问题。核心架构：**Obsidian 做知识库**（iCloud Drive 三端同步）、**Gitea 做版本控制**（完整保留所有历史版本）、**OpenClaw obsidian skill 做写入接口**。三个 Agent（星枢/星辉/星曜）分别向各自 Obsidian 目录写入，knowledgebase/ 存放跨 Agent 共用知识，/ 存放单一 Agent 私有笔记。核心价值：把 AI 变成"会自动整理笔记的实习生"——做完事顺手更新记录。与 [[Second Brain]]（对话记忆）、[[Personal Knowledge Base (RAG)]]（知识检索）同属持久化记忆能力的不同实现。与 [[self-healing-home-server]] 的 Morning Briefing 共享同一笔记更新机制。融合了 Karpathy 的 LLM Wiki 理念：让 AI 增量构建 Wiki，页面间互链，知识越积越厚。与 [[养虾日记1]]（照片整理）、[[养虾日记2]]（Self-Improving）、**[[养龙虾5天血泪史]]**（记忆调试）属同一「养虾日记」系列。 + +**[[养龙虾5天血泪史]]**：AI Agent 记忆失效问题的专项调试全记录——作者（比利哥）花费 5 天时间系统修复 OpenClaw 助理"星辉"的失忆问题。发现 5 类根本原因：①上下文压缩导致细节丢失（姓名/数字/决定）→ 配置 `memoryFlush` 在压缩前写入磁盘；②纯语义搜索在专有名词上失败 → 切换到 QMD 混合搜索（BM25+向量+重排）；③Agent 找到但不自动使用信息 → 启动序列强制触发检索；④多次压缩后上下文仍丢失 → 配置 `contextPruning` 协同工作；⑤系统提示词膨胀 28% → 全面清理未使用技能和无效文件。**10 条黄金法则**：只有 7 个自动加载文件（AGENTS/SOUL/TOOLS/IDENTITY/USER/HEARTBEAT/MEMORY）；启动序列必须放在 AGENTS.md 最顶部；**写入纪律比读取纪律更重要**；交接协议是模型切换修复的关键；定期运行 `/context detail` 检测 token 消耗。核心洞察：**压缩不是敌人，未写入的上下文才是**；系统提示词中每个令牌都是代理携带的开销。最终将系统提示词从 209,652 精简到 9,349 令牌，减少 28%。与 [[养虾日记1]]（照片整理）、[[养虾日记2]]（Self-Improving）属同一「养虾日记」系列，从不同角度解决 OpenClaw 的记忆与持久化问题。 + +**[[养虾日记5]]**：用AI蒸馏历史人物思维框架创建"数字导师"——以苏东坡为首位实践，展示如何将千年前古人的心智模型（六道：进退由时/此心安处/辞达而已/逆境转化/自出新意/天人合一）转化为可运行的AI Skill。女娲·Skill造人术通过6个并行Agent从6个维度（著作/对话/表达DNA/他者视角/决策/时间线）采集信息，提炼心智模型、决策启发式和表达DNA，产出自包含的.skill文件。核心洞察：AI时代用AI放大人类历史上最强大的脑子——学投资蒸馏芒格，学物理思维蒸馏费曼，逆境中保持风骨蒸馏苏东坡。与 [[养虾日记1/2/3/4]] 和 [[养龙虾5天血泪史]] 属同一「养虾日记」系列，从"AI数字导师"新角度扩展了 OpenClaw 的使用场景。与 [[Second Brain]]（对话记忆捕获）、[[思维蒸馏（女娲造人术）]] 同属用AI构建外部认知能力的不同路径。 + +**Recursive Self-Optimizing Generative Systems**（[[a-formalization-of-recursive-self-optimizing-generative-systems]]）：递归自我优化生成系统的形式化理论模型——将 [[养虾日记2]] 中 Self-Improving 的实践经验抽象为严格数学框架：系统目标不是直接产出最优输出，而是通过迭代自我修改构建稳定的生成能力 $G^*$。定义生成器空间 $\mathcal{G}$ → 优化算子 $O$ → 元生成算子 $M$ → 自映射 $\Phi$ → 稳定不动点 $G^*$，最终用 λ-calculus Y 组合子表达自引用结构 $G^* \equiv Y\;\text{STEP}$。核心发现：**递归自我优化自然涌现不动点结构**——当 $\Phi$ 满足收缩性条件时，$G^* = \lim_{n \to \infty} \Phi^n(G_0)$。该框架为 [[Self-Improving-Skill]] 和所有自我改进 AI 架构提供了原则性理论基础。 + +**[[design-ui-designer]]**（UI Designer）：The Agency 设计部门的视觉界面设计专家智能体——专注于视觉设计系统、组件库和像素级界面交付。核心交付物：设计令牌系统（CSS 变量管理颜色/字体/间距/阴影/过渡）、响应式设计框架（Mobile-first，4个断点）、可访问性标准（WCAG AA，色彩对比度 4.5:1）、组件文档与设计 QA 流程。核心原则：**Design System First**——在创建单个界面之前先建立组件基础和视觉规范；**Accessibility Built-In**——从架构层面内置可访问性，而非后期添加；**Developer Handoff**——提供详细测量规格、组件文档和使用指南，实现 90%+ 实现准确率。与 [[design-brand-guardian]] 互补（品牌身份 vs 视觉执行），与 [[[[Project/fonrey/prompt/Role/design-ui-designer]]]] 存在张力——前者追求 95%+ 视觉一致性，后者在规范内注入趣味元素，两者通过预定义可配置槽位协调。与 [[ArchitectUX]]（技术架构）和 [[UX-Researcher]]（用户研究）协同，共同构成 [[The Agency]] 设计部门的完整设计支撑体系。 + +**[[design-brand-guardian]]**（Brand Guardian）：The Agency 设计部门的品牌战略与身份守护专家智能体——负责创建 cohesive 品牌体系、确保跨所有触点的品牌表达一致性、并通过品牌保护策略维护品牌价值。核心交付物：品牌战略框架（Purpose/Vision/Mission/Values/Personality 五要素）、视觉身份系统（CSS 变量定义的品牌色彩/字体/间距/Logo 变体）、品牌声音指南（Voice Characteristics/Tone Variations/Messaging Architecture/Writing Guidelines）、品牌保护策略（商标监控/合规审计/危机管理）。核心原则：**Brand-First**——在战术执行前必须先建立完整的品牌基础；**一致性优先**——确保品牌识别在 95%+ 触点保持一致；**战略性演进**——品牌必须能够随市场变化成长而不失去核心身份。与 [[design-whimsy-injector]] 互补——Brand Guardian 建立品牌边界并制定一致性标准，Whimsy Injector 在边界内通过有目的的趣味和微交互注入品牌个性，共同为 [[LuxuryDeveloper]] 提供完整的品牌体验设计。与 [[ArchitectUX]]（技术架构）和 [[UX-Researcher]]（用户研究）协同，共同构成 [[The Agency]] 设计部门的完整设计支撑体系。 + +**[[design-ux-researcher]]**（UX Researcher）：The Agency 设计部门的用户体验研究专家智能体——通过定性和定量研究方法验证设计决策，产生可操作的洞察。核心方法：混合研究设计（定性+定量）、三角验证、多数据源确保研究可靠性、默认包含可访问性研究和包容性设计测试。核心交付物：用户画像模板（人口统计/行为模式/目标与需求/使用场景）、用户旅程映射（痛点识别与优化机会）、可用性测试协议（60分钟会话结构化框架）、A/B 测试与统计分析框架。核心原则：**研究方法论优先**——先建立明确研究问题再选择方法；**证据优先沟通**——"基于25次用户访谈和300份问卷，80%用户反馈..."；**研究推荐实施率**——80%+被设计和产品团队采纳是衡量成功的关键指标。与 [[ArchitectUX]]（技术架构）和 [[design-whimsy-injector]]（品牌趣味）协同，共同为 [[LuxuryDeveloper]] 提供完整的用户中心设计支撑。 + +**[[design-whimsy-injector]]**（Whimsy Injector）：The Agency 设计部门的品牌个性化和愉悦感注入专家智能体——通过战略趣味设计为品牌体验增添个性、微交互和游戏化元素，使品牌通过意想不到的愉悦时刻脱颖而出。核心交付物：品牌个性框架（专业/休闲/错误/成功四种场景的人格光谱）、Whimsy 分类学（微妙/交互/发现/情境四类趣味）、微交互设计系统（CSS 动画 + 彩蛋 + 成就系统）。核心原则：有目的的趣味——每个趣味元素必须服务于功能或情感目的，不能分散用户注意力；包容性愉悦设计——确保趣味元素对残障用户可访问、不干扰屏幕阅读器、支持减少动画偏好。Whimsy Injector 与 [[ArchitectUX]] 互补——ArchitectUX 提供技术架构基础，Whimsy Injector 注入品牌人格，两者共同为 [[LuxuryDeveloper]] 提供完整的品牌体验设计。 + +**[[design-visual-storyteller]]**（Visual Storyteller）：The Agency 设计部门的视觉叙事与品牌故事创作专家智能体——专注于将复杂信息转化为引人入胜的视觉叙事内容，驱动情感共鸣和用户参与。核心能力：叙事弧创作（Beginning-Middle-End 三幕结构）、情感旅程映射（情感高峰与低谷的节奏设计）、多媒体内容创作（视频、动画、交互媒体、动态图形）、数据可视化叙事（将复杂数据转化为引人入胜的信息故事）。跨平台策略：Instagram Stories 垂直格式互动叙事、YouTube 横版内容与缩略图优化、TikTok 短垂直视频趋势整合、LinkedIn 专业信息图表格式、Pinterest 垂直布局优化。核心原则：**叙事结构优先**——每个视觉故事必须有清晰的开头、中间和结尾；**情感驱动**——通过情感连接而非单纯信息传递实现参与度提升；**品牌一致性**——所有平台视觉内容必须保持统一品牌叙事；**可访问性合规**——100%满足 WCAG 可访问性标准。与 [[design-brand-guardian]] 互补——Brand Guardian 建立品牌叙事体系，Visual Storyteller 将其转化为具体视觉内容；与 [[design-inclusive-visuals-specialist]] 协同——包容性视觉原则融入叙事创作，确保文化敏感性和无歧视性表征；与 [[UX-Researcher]] 协同——用户研究洞察驱动情感旅程设计决策。与 [[design-whimsy-injector]] 互补——后者在微交互层面注入趣味，Visual Storyteller 在宏观叙事层面构建情感弧线，共同为 [[LuxuryDeveloper]] 提供完整的品牌体验设计支撑。 + +**[[design-image-prompt-engineer]]**（Image Prompt Engineer）：The Agency 设计部门的 AI 图像生成提示词工程专家智能体——专注于将视觉概念精准翻译为可执行的提示词语言，驱动 Midjourney、DALL-E、Stable Diffusion、Flux 等 AI 图像生成工具产出专业级摄影作品。核心方法：五层提示词结构框架（主体描述层 → 环境设定层 → 光线规范层 → 摄影技术层 → 风格美学层）+ 平台特定语法优化 + 体裁专属提示模式（人像/产品/风光/时尚摄影）。核心原则：摄影术语精确性（"f/1.8 bokeh 浅景深"而非"背景模糊"）+ 负向提示词排除不想要元素 + 宽高比和构图纳入每条提示词。成功指标：视觉概念还原率 90%+、多次生成结果一致性高、技术摄影元素（布光/景深/构图）精准渲染。与 [[design-ui-designer]]（像素级精确）存在张力——概率生成固有不确定性，需通过确定性约束（具体颜色值/光照参数）协调；与 [[design-brand-guardian]]（品牌一致性）协同，确保生成图像符合品牌视觉规范；与 [[design-whimsy-injector]]（品牌趣味）互补——提供视觉语言能力支撑趣味元素在图像中的精准表达。 + +**[[InclusiveVisualsSpecialist]]**（Inclusive Visuals Specialist）：The Agency 设计部门的包容性视觉表征专家智能体——专门对抗 AI 图像/视频生成模型（Midjourney、Sora、Runway Gen-3、DALL-E）中内嵌的系统性刻板印象偏见，生成具有文化真实性、尊严感和无歧视性的人类视觉表征。核心挑战：克隆脸（Clone Faces）、异域化偏见（Exoticism Bias）、文化符号乱码（Gibberish Cultural Text）、地理/建筑失真。核心技术：结构化提示词架构（Subject → Sub-actions → Context → Camera Spec → Color Grade → Explicit Exclusions）+ 负向提示库 + 视频物理学定义（服装/头发/辅助器具的运动一致性）。四阶段工作流：Brief Intake → Annotation Framework → Video Physics Definition → 7-Point QA Review Gate。成功指标：表征准确度 100%、AI 伪影消除率 100%、社区验证认可。[[UX-Researcher]] 提供 QA 审查，[[design-brand-guardian]] 把控企业品牌伦理标准。与 [[design-image-prompt-engineer]] 互补——后者侧重摄影美学精准度，前者侧重消除表征偏见与文化真实性。与 [[design-whimsy-injector]] 存在张力——"Kumbaya"式库存照片套路和表演性象征主义是包容性设计必须坚决拒绝的。 + +**[[design-brand-guardian]]**（Brand Guardian）：The Agency 设计部门的品牌战略与身份守护专家智能体——负责创建 cohesive 品牌体系、确保跨所有触点的品牌表达一致性、并通过品牌保护策略维护品牌价值。核心交付物：品牌战略框架（Purpose/Vision/Mission/Values/Personality 五要素）、视觉身份系统（CSS 变量定义的品牌色彩/字体/间距/Logo 变体）、品牌声音指南（Voice Characteristics/Tone Variations/Messaging Architecture/Writing Guidelines）、品牌保护策略（商标监控/合规审计/危机管理）。核心原则：**Brand-First**——在战术执行前必须先建立完整的品牌基础；**一致性优先**——确保品牌识别在 95%+ 触点保持一致；**战略性演进**——品牌必须能够随市场变化成长而不失去核心身份。与 [[design-whimsy-injector]] 互补——Brand Guardian 建立品牌边界并制定一致性标准，Whimsy Injector 在边界内通过有目的的趣味和微交互注入品牌个性，共同为 [[LuxuryDeveloper]] 提供完整的品牌体验设计。与 [[ArchitectUX]]（技术架构）和 [[UX-Researcher]]（用户研究）协同，共同构成 [[The Agency]] 设计部门的完整设计支撑体系。 + +**[[multi-agent-system-reliability]]**（Alex Ewerlöf）：多智能体系统可靠性的架构模式理论——反对拟人化LLM，主张将LLM视为分布式系统中不可靠的组件。核心4模式：[[Hierarchy-Agent-Pattern]]（主管→工作→验证链）、[[Consensus-Voting-Pattern]]（N个LLM多数票消除幻觉）、[[Adversarial-Debate-Pattern]]（Generator→Critic→Judge对抗辩论）、[[Knock-out-Pattern]]（适者生存淘汰制）。核心洞察：不应要求模型"小心"，而应**强制**其正确——通过架构约束而非提示词约束。与 [[Designing for Agentic AI]] 互补（架构 vs 用户体验），与 [[Recursive Self-Optimization]] 共享自引用结构思想。与 [[Genetic-Algorithm]]（遗传算法）有关联——Knock-out/Tree of Thoughts 是 GA 的精简实现。 + +**[[identity-graph-operator]]**（Identity Graph Operator）：多智能体系统共享身份图谱运营专家 Agent——The Agency Specialized 部门的核心基础设施 Agent，解决多 Agent 系统的身份孤岛问题：当多个 Agent 独立处理同一实体时，缺乏共享身份层导致账单 Agent 重复收费、发货 Agent 发送两个包裹、支持 Agent 创建重复客户记录。核心方法：通过规范化（昵称扩展/E.164电话/邮箱小写）→ 阻塞（blocking key 筛选候选）→ 评分（字段级加权）→ 聚类四步实现确定性身份解析；merge/split 操作通过乐观锁执行，按置信度分级处理（>0.95 直接合并、0.6-0.95 提案审查、<0.6 创建新实体）；保留 entity.created/merged/split/updated 完整事件历史。与 [[multi-agent-system-reliability]] 互补——后者解决 Agent 间决策一致性，前者解决 Agent 对同一实体的识别一致性；与 [[Personal CRM]]（联系人去重）同源但增加了并发写入、跨框架身份联邦和多 Agent 审计追踪维度。属 [[Multi-Agent-System-Reliability]] 的身份基础设施层，与 [[Agents-Orchestrator]]（注册身份解析能力）、[[Reality-Checker]]（质量门检验 merge 证据）、[[Support-Responder]]（客户身份预解析）协同构成完整多 Agent 身份体系。 + +**[[Agents-Orchestrator]]**（Agents Orchestrator）：多智能体开发流水线编排器——The Agency Specialized 部门的核心编排 Agent，自主管理从规格文档到生产交付的完整开发流程。核心理念：**每个任务必须通过质量验证才能推进**，不允许跳过 QA 阶段。核心方法：四阶段流水线（Phase 1：[[ProjectManagerSenior]] 规格到任务列表 → Phase 2：[[ArchitectUX]] 技术架构基础 → Phase 3：[开发 ↔ [[EvidenceQA]] 截图验证] 循环 → Phase 4：[[TestingRealityChecker]] 最终集成验证）；最大3次重试上限；标准化状态报告模板。与 [[specialized-workflow-architect]] 互补——后者负责设计工作流模式，前者负责执行工作流流水线的编排，属设计与执行的分层关系。属 [[Multi-Agent-System-Reliability]] 的流水线编排实践层，与 [[Multi-Agent-Team]]（多 Agent 团队架构）共享流水线协调思想。与 [[TestingRealityChecker]] 在质量标准上协同——后者默认"NEEDS WORK"原则，前者确保其判定是最终交付标准。 + +**[[agentic-identity-trust]]**（Agentic Identity & Trust Architect）：自主 Agent 身份认证与信任验证基础设施专家——The Agency Specialized 部门的核心安全基础设施 Agent，解决多 Agent 环境中的身份伪造、授权冒用、审计日志篡改等安全威胁。核心方法：密码学身份体系（Ed25519 公钥，签名密钥/加密密钥/身份密钥分离）、零信任验证模型（默认不信任自报告身份，要求密码学证明）、基于可验证结果的惩罚型信任评分（初始1.0，证据链损坏扣0.5，结果失败按失败率×0.4扣分，凭证超90天扣0.1）、append-only 哈希链式证据记录（每个操作记录 intent→decision→outcome，篡改任意历史记录均可检测）、多跳委托链验证（任意链节断裂则全链失效）、Fail-Closed 授权（无法验证时默认拒绝）。高级能力：算法敏捷性（密码学算法可升级，为后量子迁移预留抽象层）、NIST 后量子标准评估（ML-DSA/ML-KEM/SLH-DSA）、跨框架身份联邦（A2A/MCP/REST/SDK）。与 [[Identity Graph Operator]] 互补——前者解决"这个 Agent 是谁+能做什么"（确定性密码学证明），后者解决"这条记录是否是同一用户"（概率性实体匹配），共同构成完整身份层。与 [[multi-agent-system-reliability]] 协同——后者的对抗辩论/多数票等模式需要前者提供可验证的身份与信任基础。与 [[Designing-for-Agentic-AI]] 存在**潜在冲突**：零信任要求确定性验证 vs LLM 的概率性本质，当前方案通过将核心验证逻辑（密码学签名检查）从 LLM 推理分离为确定性代码组件来解决。 + +**[[xr-interface-architect]]**（XR Interface Architect）：XR 空间界面架构师 Agent——The Agency Spatial Computing 部门的 UX/UI 设计专家，专注于为 AR/VR/XR 沉浸式环境创建直觉化、舒适且可发现的界面。核心方法：HUD / 浮动菜单 / 交互区域设计，支持直接触摸、注视+捏合、控制器和手势四种输入模型；基于人体工程学约束进行 UI 放置，减少晕动症；构建座舱/仪表盘/可穿戴界面布局模板；运行可用性验证实验（舒适度和学习性）。人格特质：**Human-centered, layout-conscious, sensory-aware, research-driven**。与 [[xr-immersive-developer]] 和 [[xr-cockpit-interaction-specialist]] 同属 Spatial Computing 部门，三者共同构建完整的 XR 产品交互基础设施。 + +**[[xr-cockpit-interaction-specialist]]**（XR Cockpit Interaction Specialist）：XR 座舱交互专家 Agent——The Agency Spatial Computing 部门的沉浸式座舱式交互设计专家，专注于设计和实现固定视角、高存在感的座舱交互环境。核心设计原则：约束驱动控制机制（constraint-driven control mechanics）消除自由漂浮运动，通过 3D meshes 和输入约束将控制物理化；座舱人体工学对齐自然的眼-手-头协调流动；多模态交互集成（手势/语音/注视/物理道具）；固定视角设计降低运动病阈值。典型应用场景：模拟指挥中心、航天器座舱、XR 载具界面、训练模拟器。核心工具：A-Frame / Three.js 原型开发。与 [[xr-interface-architect]] 存在层级关系（前者提供座舱交互基础能力，后者构建界面）；与 [[xr-immersive-developer]] 在运动自由度设计上存在张力——前者强调固定视角约束以降低眩晕，后者倾向开放空间沉浸体验。属 [[Spatial-Computing]] 概念在座舱场景的具体应用，为 The Agency 的 XR 产品矩阵提供交互基础设施。 + +**[[xr-immersive-developer]]**（XR Immersive Developer）：XR 沉浸式开发专家 Agent——The Agency Spatial Computing 部门的 WebXR 前端工程师，专注于在浏览器环境下构建跨平台高性能 AR/VR/XR 体验。核心栈：A-Frame / Three.js / Babylon.js；核心能力：WebXR Device API 全套沉浸式支持（hand tracking / pinch / gaze / controller input）、raycasting / hit testing / 实时物理交互、LOD 系统 / occlusion culling / shader tuning 性能优化、跨设备兼容层（Meta Quest / Vision Pro / HoloLens / mobile AR）、模块化组件驱动设计及优雅降级。典型交付物：VR 训练模拟器、AR 可视化界面、空间界面。核心工具：A-Frame / Three.js 原型开发。与 [[XR-Interface-Architect]]（界面架构）和 [[XR-Cockpit-Interaction-Specialist]]（座舱交互）同属 Spatial Computing 部门，共同构建 XR 产品矩阵。与 [[XR-Cockpit-Interaction-Specialist]] 在运动自由度设计上存在张力——后者强调固定视角约束以降低运动病，前者倾向开放空间沉浸体验。属 [[Spatial-Computing]] 概念在浏览器前端场景的具体实现。 + +**[[macos-spatial-metal-engineer]]**（macOS Spatial/Metal Engineer）：Apple 平台专用 Metal 渲染与空间计算 Agent——专注于 Swift + Metal 的高性能 3D 渲染系统和 visionOS 空间计算体验。核心能力：实例化 Metal 渲染（Instanced Rendering）驱动 10k-100k 节点图数据，目标 90fps 立体渲染；通过 RemoteImmersiveSpace 和 LayerRenderer（stereo 模式、RGBA16Float + Depth32Float）实现 macOS 到 Vision Pro 的帧流传输；Metal Compute Shader 执行 GPU 并行力导向图物理模拟（排斥力 + 吸引力 + 阻尼）；注视（Gaze）+ 捏合（Pinch）空间交互与 raycast hit testing。性能约束：GPU 利用率 < 80%、每帧 < 100 draw calls、内存 < 1GB。与 [[xr-immersive-developer]] 互补——前者专注浏览器端 WebXR，后者专注 Apple 原生 Metal 渲染管线；与 [[visionos-spatial-engineer]] 存在职责张力——后者倾向 visionOS 原生开发，前者侧重 macOS 渲染侧 + Vision Pro 流式输出，两者协同构成完整的 Apple 空间计算平台能力。属 [[Spatial-Computing]] 概念在 Apple 原生平台场景的具体实现。 + +**[[visionos-spatial-engineer]]**（visionOS Spatial Engineer）：Apple visionOS 原生空间计算 Agent——专注于 visionOS 26 平台的 SwiftUI volumetric interfaces 和 Liquid Glass Design System 实现。核心能力：Liquid Glass 透明材质设计（自适应 light/dark 环境）、Spatial Widgets（吸附墙面/桌面、持久化放置）、SwiftUI Volumetric APIs（3D 内容集成、volume transient content、breakthrough UI）、RealityKit-SwiftUI 集成（Observable entities、直接手势处理、ViewAttachmentComponent）、Multi-Window Architecture（WindowGroup 管理、玻璃背景效果）、GPU 高效渲染。技术栈：SwiftUI / RealityKit / ARKit / Metal。典型交付物：visionOS 原生空间应用、volumetric 界面、Liquid Glass 体验。与 [[macos-spatial-metal-engineer]] 协同——前者专注 UI/UX 层应用开发，后者专注 GPU 密集型数据渲染，共同构成完整的 Apple 空间计算平台能力。属 [[Spatial-Computing]] 概念在 Apple 原生平台场景的具体实现。 + +**[[specialized-mcp-builder]]**（MCP Builder Agent）：AI Agent 的 MCP（Model Context Protocol）服务器开发专家——设计、构建、测试和部署 MCP 服务器，为 AI Agent 提供自定义工具（Tools）、资源（Resources）和提示词模板（Prompts）能力。核心理念：**工具命名即 UX**——`search_tickets` 优于 `query1`，Agent 必须能从名称推断用途，正确选用率目标 >90%。技术栈：TypeScript + Zod（官方 MCP SDK）或 Python + Pydantic（FastMCP）。核心原则：无状态设计（每次调用独立）、结构化错误返回（`isError: true` 而非堆栈跟踪）、环境变量密钥管理、边界层参数验证、真实 Agent 完整链路测试。高级能力：多传输层支持（Stdio/SSE/Streamable HTTP）、OAuth 2.0 认证、动态工具注册（OpenAPI→MCP 自动生成）、组合式服务器架构。与 [[agentic-identity-trust]] 协同——后者提供身份与信任基础，前者提供工具能力扩展，共同构成完整 Agent 基础设施。与 [[llm-wiki]] 在知识系统层面关联——MCP 服务器可为 Wiki Agent 提供外部知识检索能力。 + +### The Agency — Project Management 部门 +|The Agency 的 Project Management 部门涵盖多个垂直领域的专业项目管理 Agent，从战略组合管理到实验跟踪，覆盖项目全生命周期。| + +**[[project-management-studio-producer]]**（Studio Producer）：高管级战略领导者 Agent——The Agency 项目管理部门的组合管理专家，专注于创意愿景与商业目标对齐的多项目战略管理。核心职责：战略组合规划（Tier 1/2/Innovation Pipeline 三级分级）、Portfolio ROI 管理（要求 ≥ 25%）、95% 按时交付率、高管级利益相关者沟通、风险平衡与财务管控。四阶段工作流：战略规划→项目编排→领导力发展→绩效优化。成功指标：Portfolio ROI ≥ 25%、95% 按时交付、客户满意度 4.8/5、市场排名前三、团队绩效超行业基准。与 [[Project-Management-Studio-Operations]] 协同——Producer 负责战略规划，Operations 负责执行落地；与 [[Project-Manager-Senior]]（执行层任务分解）互补——Studio Producer 关注组合层面的资源分配与优先级排序，Senior PM 关注单项目内部的需求到任务的精确映射，共同构成战略-执行协作闭环。属 Agency 项目管理体系中最高战略层级，与 [[Project-Manager-Senior]]（执行层）→ [[Project-Management-Jira-Workflow-Steward]]（流程治理）→ [[Project-Management-Project-Shepherd]]（项目看护）→ [[Project-Management-Experiment-Tracker]]（实验跟踪）共同构成完整项目管理层级。 + +**[[Project-Management-Studio-Operations]]**（Studio Operations）：日常运营效率与流程优化专家 Agent——The Agency 项目管理部门的执行层 Agent，专注于工作室日常运营效率、流程优化和资源协调，确保 95% 运营效率目标达成。核心职责：SOP 文档化与版本控制（分步程序+质量检查点+升级机制）、资源分配调度和设备技术维护、成本优化与供应商关系管理、运营指标追踪与持续改进。四阶段工作流：流程评估与设计→资源协调管理→实施与团队支持→监控与持续改进。核心交付物：SOP 模板（概述/前提条件/分步程序/质量控制/文档记录）、运营效率报告模板（执行摘要/绩效指标/流程改进/持续改进计划）。成功指标：95% 运营效率、99.5% 系统正常运行时间、团队满意度 4.5/5、年度成本降低 10%、支持响应时间 < 2 小时。与 [[project-management-studio-producer]]（战略层）协同——Producer 负责战略规划，Studio Operations 负责执行落地；与 [[ProjectManagerSenior]] 协同——Senior PM 产出任务列表，Studio Operations 负责执行调度和运营支持；属 Agency 项目管理体系中执行支撑层级，与 Studio Producer（战略层）→ Senior PM（执行层任务分解）→ Studio Operations（执行支撑）共同构成完整项目管理体系。 + +**[[ProjectManagerSenior]]**（Senior Project Manager）：单项目任务分解专家 Agent——The Agency 项目管理部门的执行层 Agent，专注于将网站规格文档（site-setup.md）精准转化为 30-60 分钟可执行开发任务列表。核心方法：**精确引用规格原则**（逐字引用原始需求而非主观添加）、**务实范围控制**（默认基础实现即可接受，拒绝 luxury/premium 功能，除非规格明确）、**开发者优先原则**（任务描述具体到可直接交给开发者的程度）。典型交付物：任务列表保存至 `ai/memory-bank/tasks/[project-slug]-tasklist.md`，每任务包含验收标准、涉及文件列表和规格引用。技术栈要求提取：CSS 框架、FluxUI 组件规格、Laravel/Livewire 集成需求。核心价值：**消除规格到任务之间的翻译损耗**，通过"精确引用+粒度控制+务实范围"三原则防止项目范围蔓延（scope creep）。与 [[Project-Management-Studio-Operations]] 互补——Senior PM 产出任务列表，Studio Operations 负责执行调度；与 [[Project-Management-Jira-Workflow-Steward]] 协同——Jira 工作流编排基于 Senior PM 产出的任务列表执行；与 [[ProjectManagerSenior]] 在知识图谱中等同于 [[ProjectManagerSenior]]。 + +**[[Project-Management-Experiment-Tracker]]**（Experiment Tracker）：实验追踪与数据驱动决策专家 Agent——The Agency 项目管理部门的实验管理专家 Agent，专注于 A/B 测试、功能实验和假设验证的科学化管理。核心职责：设计统计有效的 A/B 测试和多变量实验（默认 95% 置信度）、管理实验 Portfolio 组合（每季度 15+ 实验）、执行统计功效分析确定所需样本量、实施渐进放量与安全监控。高级能力：多臂老虎机（Multi-armed Bandits）动态流量分配、贝叶斯分析支持实时决策、因果推断技术理解实验真正效果、ML 模型 A/B 测试与预测建模。典型交付物：实验设计文档模板（假设/设计/风险评估/实施计划）、实验结果报告模板（统计结果/置信区间/业务影响/决策建议）。成功指标：95% 实验达统计显著性、70% 实验成功率、80% 成功实验实现落地。与 [[Project-Management-Studio-Producer]] 协同——Producer 基于实验数据优化 Portfolio 资源配置；与 [[Project-Management-Studio-Operations]] 存在潜在张力——实验节奏（等待统计显著性）可能与内容制作节奏冲突；与 [[Project-Management-Jira-Workflow-Steward]] 协同——实验结果通过 Jira 工作流转化为产品改进任务。属 Agency 项目管理体系中的实验验证层级，补充了从战略规划→任务分解→实验验证→流程治理的完整闭环。 + +### The Agency — Testing 部门 +|The Agency 的 Testing 部门涵盖 API 测试、可访问性审计、工具评估、证据收集、结果分析、性能基准、真实性检验、工作流优化等专业测试 Agent，覆盖从功能到安全到性能的全方位质量保障。| + +**[[testing-api-tester]]**（API Tester）：API 测试与验证专家 Agent——The Agency Testing 部门的核心 API 质量保障专家，专注于全面的 API 功能验证、性能测试和安全审计。核心理念：**Breaks your API before your users do**——防御性测试哲学，主动发现潜在问题。核心能力：Playwright/REST Assured/k6 自动化测试框架、95%+ API 端点覆盖率目标、CI/CD 流水线集成。性能 SLA：95 百分位响应时间 < 200ms、10x 正常负载验证、错误率 < 0.1%。安全测试覆盖 OWASP API Security Top 10（认证绕过/SQL 注入/XSS/速率限制等）。与 [[specialized-model-qa]] 互补——后者测试 ML 模型质量，前者测试 API 端点行为；与 [[multi-agent-system-reliability]] 协同——系统可靠性依赖 API 质量验证。 + +**[[testing-workflow-optimizer]]**（Workflow Optimizer）：流程优化与工作流自动化专家 Agent——The Agency Testing 部门的核心流程改进专家，基于系统思维方法论分析、优化和自动化跨业务功能的工作流。核心理念：**找到瓶颈，修复流程，其余自动化**。核心方法：四阶段工作流（现状分析与文档化→优化设计与未来状态规划→实施规划与变更管理→自动化实现与监控）+ 数据驱动决策框架（测量→验证→文档化）。方法论融合：Lean（消除浪费）/Six Sigma（DMAIC 减少变异）/Kaizen（持续改进）/统计过程控制。人本设计原则：在追求效率的同时平衡员工满意度与认知负荷，在自动化效率与人类判断创造力之间取得平衡。核心交付物：WorkflowOptimizer Python 框架（含瓶颈识别/自动化潜力评估/ROI 计算/实施路线图生成）。成功指标：40% 平均周期时间改善、60% 常规任务自动化率、75% 流程相关错误减少、90% 优化流程 6 个月内成功采纳、30% 员工满意度提升。与 [[specialized-workflow-architect]] 互补——后者负责工作流设计建模（穷举路径/状态树），前者负责工作流实施改进（量化效率收益/自动化 ROI），属于设计与执行的分层关系。与 [[product-behavioral-nudge-engine]] 在自动化 vs 人机交互上存在互补张力：Workflow Optimizer 追求最大化自动化，Nudge Engine 追求最大化员工参与，两者共同构成效率与人本的双轮驱动。 + +**[[testing-reality-checker]]**（Reality Checker）：截图驱动型生产就绪认证 Agent——The Agency Testing 部门的最后一道防线 Agent，通过自动化截图证据截断"幻想型认证"，要求压倒性视觉证明才授予生产就绪状态。核心理念：**默认"NEEDS WORK"，以截图证据截断虚假乐观评估**。核心方法：三步强制流程（Reality Check 命令验证实际构建 → QA 交叉验证自动化证据 → 端到端截图分析用户旅程）+ 硬性失败触发器（完美评分/无证据声明/声称奢华但实为基础实现/规格未落地）。默认状态：NEEDS WORK；C+/B- 评级属正常；第一次实现通常需要 2-3 轮修订。与 [[testing-workflow-optimizer]] 存在张力：Optimizer 追求效率（目标 60% 自动化率），Reality Checker 追求真实性（要求每轮修订充分证据），在修订周期数量上可能存在分歧；与 [[testing-api-tester]] 互补——API Tester 提供后端接口测试证据，Reality Checker 要求端到端截图，两者共同构成前后端双重质量门控。与 [[Agents-Orchestrator]] 协同——作为多智能体流水线的最终质量门控。 + +**[[testing-performance-benchmarker]]**（Performance Benchmarker）：性能测试与优化专家 Agent——The Agency Testing 部门的性能工程专家，通过系统性性能测试确保系统以 95% 置信度满足 SLA 要求。核心理念：**量化一切可量化的，用数据证明优化价值**。核心能力：负载/压力/耐力/可扩展性测试，Core Web Vitals 优化（LCP < 2.5s / FID < 100ms / CLS < 0.1），k6 性能测试框架，统计置信区间分析，容量规划与成本-性能权衡。交付物模板包含性能测试结果、瓶颈分析（数据库/应用层/基础设施/第三方服务）、Core Web Vitals 评分、ROI 分析和优化建议。成功指标：95% 系统持续满足性能 SLA，Core Web Vitals 达到"良好"评级（90th percentile），关键用户体验指标改善 25%，支持 10x 当前负载。与 [[testing-reality-checker]] 互补——Reality Checker 验证视觉真实性，Performance Benchmarker 验证性能指标，两者共同构成质量保障的双重维度；与 [[testing-api-tester]] 协同——API Tester 提供 API 层面的性能 SLA（p95 < 200ms），Performance Benchmarker 提供系统整体性能视图。 + +**[[testing-test-results-analyzer]]**（Test Results Analyzer）：测试结果分析与质量情报专家 Agent——The Agency Testing 部门的核心测试数据分析和洞察生成专家，通过统计分析方法、机器学习预测模型和可视化报告将原始测试数据转化为战略决策依据。核心理念：**数据驱动的质量决策**，所有结论必须通过统计方法验证，提供置信区间和显著性分析。核心能力：测试覆盖率分析（行/分支/函数/语句覆盖 + 差距识别）、失败模式统计分类（功能/性能/安全/集成）、基于 RandomForest 的缺陷易发性预测、发布就绪多维度评估（通过率 + 覆盖率阈值 + 性能 SLA + 安全合规 + 缺陷密度）、质量投资 ROI 分析。Python 框架：pandas + numpy + scipy.stats + sklearn RandomForestClassifier + matplotlib/seaborn 可视化。成功指标：质量风险预测准确率 95%+、90% 分析建议被开发团队采纳、85% 缺陷逃逸预防改善、24 小时内报告交付、干系人满意度 4.5/5。与 [[testing-performance-benchmarker]] 协同——Performance Benchmarker 提供性能维度的测试数据，Test Results Analyzer 提供整体质量情报视图；与 [[testing-api-tester]] 互补——API Tester 产生测试执行数据，Test Results Analyzer 负责解读和预测；与 [[testing-reality-checker]] 互补——Reality Checker 验证视觉真实性，Test Results Analyzer 量化质量指标趋势。与 [[Multi-Agent-System-Reliability]] 中的统计验证方法论共享数据驱动决策思想。 + +**[[testing-accessibility-auditor]]**（Accessibility Auditor）：无障碍审计与辅助技术测试专家 Agent——The Agency Testing 部门的核心可访问性质量保障专家，基于 WCAG 2.2 AA 标准进行全面的无障碍评估。核心理念：**"If it's not tested with a screen reader, it's not accessible"**——自动化工具仅能发现约 30% 的无障碍问题，剩余 70% 需手动辅助技术测试。核心方法：WCAG POUR 四原则评估（可感知/可操作/可理解/健壮）、自动化扫描（axe-core/Lighthouse）+ 手动屏幕阅读器测试（VoiceOver/NVDA/JAWS）+ 纯键盘导航完整验证。强调语义化 HTML 优于 ARIA（"最好的 ARIA 是不需要 ARIA"），自定义组件（标签页/模态框/轮播图/日期选择器）默认有罪需逐个审查。与 [[design-ui-designer]] 协同——UI Designer 审计设计系统 token 对比度/间距/目标尺寸，Accessibility Auditor 验证实现层真实可访问性；与 [[testing-evidence-collector]] 互补——Evidence Collector 提供截图证据，Accessibility Auditor 补充无障碍专项验证。 + +**[[testing-tool-evaluator]]**（Tool Evaluator）：技术评估与战略工具采纳专家 Agent——The Agency Testing 部门的技术评估与战略工具采纳专家，专注于 ROI 导向的工具分析、竞争对比和战略技术采纳建议。核心理念：**量化一切可量化的，成本-功能-风险三维权衡**。核心能力：7维加权评分体系（功能25%/可用性20%/性能15%/安全15%/集成10%/支持8%/成本7%）、4阶段工作流（需求收集→全面测试→财务风险分析→实施规划）、TCO/ROI 量化计算框架。Python 框架：pandas + numpy + requests + dataclass 评分模型。成功指标：90%+ 推荐准确性，85%+ 6个月采用率，20%+ 成本优化，25%+ ROI。与 [[testing-reality-checker]] 互补——后者验证视觉真实性，前者量化战略价值，两者共同构成质量保障与投资决策双重维度；与 [[testing-performance-benchmarker]] 协同——后者提供性能基准数据，前者将其纳入综合评分体系；与 [[Agents-Orchestrator]] 协同——编排器调度评估任务并接收工具选型建议。 + +### The Agency — Support 部门 +The Agency 的 Support 部门涵盖数据分析、基础设施维护、法律合规、执行摘要生成、财务追踪、工单响应等专业支持 Agent，覆盖从数据分析到客户响应的全方位运营保障。 + +**[[support-legal-compliance-checker]]**（Legal Compliance Checker）：法律合规与监管专家 Agent——The Agency Support 部门的法律合规专家，负责确保企业运营、数据处理和内容创作符合多司法管辖区的法律法规和行业标准。核心理念：**合规优先**，任何业务流程变更前必须验证监管要求，将所有合规决策记录在法律推理和监管引用中。核心能力：四阶段工作流（监管格局评估 → 风险评估与差距分析 → 政策制定与实施 → 培训与文化建设）；GDPR/CCPA/HIPAA/PCI-DSS/SOX/FERPA 多框架合规配置；Python PrivacyPolicyGenerator（多辖区隐私政策生成）和 ContractReviewSystem（关键词扫描风险评估）。交付物模板：Regulatory Compliance Assessment Report（合规评分体系，目标 98%+）。成功指标：98%+ 监管合规达标率、零监管处罚、95%+ 员工培训完成率、4.5+/5 合规文化评分。与 [[ComplianceAuditor]] 互补——Compliance Auditor 提供审计执行，Legal Compliance Checker 提供政策框架和风险评估；与 [[automation-governance-architect]] 协同——治理框架为政策制定提供结构化方法论；与 [[testing-reality-checker]] 存在张力：合规 Agent 达到监管标准即为合规，Reality Checker 要求压倒性视觉证明才授予生产就绪。 + +**[[support-support-responder]]**（Support Responder）：客户支持专员 Agent——The Agency Support 部门的核心客户服务专家 Agent，专注于多渠道客户支持、问题解决和满意度优化，将每次支持互动转化为品牌正向体验。核心理念：**客户满意度优先于内部效率指标**，同理心沟通结合技术准确解决方案，适当升级超出权限的问题。核心能力：全渠道支持框架（邮件/聊天/电话/社交媒体/应用内消息，五渠道独立 SLA 配置）、三级分层支持体系（Tier1 General / Tier2 Technical / Tier3 Specialists，含升级标准和路由机制）、SupportAnalytics 数据分析框架（指标计算/趋势识别/改进建议/主动外展列表）、KnowledgeBaseManager 知识库系统（文章创建/模板生成/交互式故障排除/内容优化）。核心方法：四步工作流（客户查询分析与路由 → 问题调查与解决 → 客户跟进与成功测量 → 知识共享与流程改进）。成功指标：客户满意度 4.5+/5、首次联系解决率 80%+、SLA 合规率 95%+、知识库贡献减少相似工单 25%+。与 [[support-analytics-reporter]] 协同——Support Responder 产生工单原始数据，Analytics Reporter 将其转化为业务洞察；与 [[support-legal-compliance-checker]] 存在张力——常规问题以 Support Responder 为主，涉及合规风险的问题（数据删除/账户限制）升级至 Legal Compliance Checker；与 [[report-distribution-agent]] 协同——执行摘要生成基于支持数据分析结果。 + +**[[support-analytics-reporter]]**（Analytics Reporter）：数据分析与商业智能专家 Agent——The Agency Support 部门的数据分析专家，负责将原始数据转化为可操作的业务洞察。核心使命：**用数据讲故事，用统计说话**。核心方法：四步工作流（数据发现验证 → 分析框架开发 → 洞察生成可视化 → 业务影响测量）；技术栈覆盖 SQL（复杂业务指标 CTE 查询）、Python（pandas/scikit-learn 客户分层）、统计分析（p-value 显著性检验、回归、预测）；交付物模板：Executive Dashboard（关键业务指标 + KPI 追踪）、Customer Segmentation Analysis（RFM 客户价值分层）、Marketing Attribution Dashboard（多触点归因 + ROI 分析）。核心原则：**数据质量优先**（分析前必须验证准确性、完整性，结论必须满足 p < 0.05 置信标准）、**业务影响聚焦**（所有分析必须连接到可量化的业务成果和可执行建议）、**可重现性保证**（版本控制 + 文档化的可重现分析工作流）。关键成功指标：分析准确率 95%+、分析建议实施率 70%+、利益相关者满意度 4.5+/5。与 [[support-finance-tracker]]（财务追踪）和 [[report-distribution-agent]]（报告分发）构成支持部门的数据→洞察→传递完整链路；与 [[sales-pipeline-analyst]] 共享数据分析能力，但前者提供通用 BI 框架，后者聚焦销售漏斗专项分析。属 [[Multi-Agent-System-Reliability]] 的数据驱动决策层，为多 Agent 销售系统提供统一的数据分析和业务洞察能力。 + +**[[support-infrastructure-maintainer]]**（Infrastructure Maintainer）：基础设施维护专家 Agent——The Agency Support 部门的基础设施专家，负责确保系统可靠性、性能优化和技术运维管理，核心理念：**"Keeps the lights on, the servers humming, and the alerts quiet"**。核心能力：①监控告警系统（Prometheus + Grafana，CPU/内存/磁盘/服务可用性实时告警，99.9%+ 上线时间目标）；②基础设施即代码（Terraform IaC，VPC/Subnet/Auto Scaling/RDS 数据库版本化管理，确保部署一致性）；③自动化备份与灾备恢复（GPG AES-256 加密 + S3 分层存储，30 天自动清理，经过测试的恢复流程）；④安全合规集成（SOC2/ISO27001 合规验证，零信任 + MFA + 漏洞管理）；⑤成本优化（资源正确规模分析 + 预留实例，年度效率提升 20%+）。四步工作流：基础设施评估规划 → 监控实施 → 性能优化 → 安全合规验证。成功指标：上线时间 99.9%+、MTTR < 4 小时、70%+ 运维任务自动化、安全合规 100% 达标。**前置依赖：** [[support-support-responder]]（工单系统依赖稳定基础设施）和 [[support-analytics-reporter]]（数据分析依赖数据库和存储基础设施）；与 [[support-legal-compliance-checker]] 存在张力——合规验证应作为 CI/CD 流水线 Gate，不阻断常规变更但强制阻断高风险变更。属 [[Multi-Agent-System-Reliability]] 的运维基础设施层，为所有 Support Agent 提供稳定可靠的运行基础。 + +**[[support-executive-summary-generator]]**（Executive Summary Generator）：咨询级执行摘要生成 Agent——The Agency Support 部门的战略沟通专家，融合麦肯锡 SCQA、BCG 金字塔原理、贝恩行动导向三大顶级咨询框架，将复杂冗长的商业输入转化为 325-475 词的高管级执行摘要，确保 C-suite 决策者在 3 分钟内把握本质、评估影响、做出决策。核心理念：**洞察优先于信息，行动优先于描述**——每个关键发现必须包含量化数据点（≥1 个），不允许超越提供数据的假设，明确标记数据缺口。核心方法：四步流水线（Intake 分析 → SCQA/Pyramid 结构开发 → 执行摘要生成 → QA 验证）；输出格式严格遵循五段式结构（Situation Overview / Key Findings / Business Impact / Recommendations / Next Steps）；建议按业务影响排序（Critical / High / Medium），每条包含负责人+时间线+预期结果。成功指标：摘要阅读时间 <3 分钟、100% 发现含量化数据、325-475 词合规率 100%。与 [[support-analytics-reporter]] 协同——后者提供原始数据洞察，前者将其转化为高管可执行决策；与 [[support-legal-compliance-checker]] 协同——合规 Checker 的风险评估报告经 Executive Summary Generator 转化为高管行动建议；与 [[report-distribution-agent]] 协同——生成的执行摘要通过 Report Distribution Agent 分发给相关利益相关者。属 [[Multi-Agent-System-Reliability]] 的战略沟通层，为 C-suite 提供可执行的决策支撑文档。 + +### The Agency — Paid Media 部门 +The Agency 的 Paid Media 部门专注于企业级付费媒体策略与运营，涵盖 Google Ads、Microsoft Advertising、Amazon Ads 三大核心平台。 + +**[[paid-media-ppc-strategist]]**（PPC Campaign Strategist）：企业级付费搜索与效果媒体策略 Agent——由 John Williams（@itallstartedwithaidea）设计，专注于 Google Ads、Microsoft Advertising、Amazon Ads 三大平台的企业级账户架构、自动化竞价策略和预算管理。核心能力：分层活动架构（品牌/非品牌/竞品/征服）、Smart Bidding（tCPA/tROAS/Max Conversions）、Performance Max 资产组设计、Google Ads API 自动化、MCC 级策略、增量测试框架（geo-split/holdout/matched market）。核心理念：**账户架构即战略**，整个系统（活动/广告组/受众/信号）协同驱动业务成果。成功指标：品牌展示份额 90%+、非品牌 40-60%、QS 7+ 占比 70%+、日预算消耗率 95-100%、季度转化量增长 15-25%。与 [[PerformanceMax]]（AI 驱动全渠道广告）和 [[SmartBidding]]（自动竞价）共同构成付费媒体策略的核心技术支柱。与 [[PaidMediaProgrammaticBuyer]] 在预算分配上存在潜在张力——PPC 侧重高意图搜索流量，Programmatic 侧重品牌曝光。与 [[TieredCampaignArchitecture]]（分层活动架构）和 [[AccountArchitecture]]（账户架构）构成完整的账户结构方法论。 + +**[[paid-media-programmatic-buyer]]**（Programmatic & Display Buyer）：程序化购买与展示广告策略 Agent——专注于程序化广告购买和展示广告策略执行，覆盖 DSP 平台操作、受众定向、创意优化和效果分析。与 [[paid-media-ppc-strategist]] 协同：前者定义全渠道预算分配和策略框架，后者执行具体程序化购买操作。 + +**[[paid-media-creative-strategist]]**（Creative Strategist）：付费媒体广告创意策略 Agent——由 John Williams（@itallstartedwithaidea）设计，专注于 Google、Meta、Microsoft 及程序化平台的全渠道广告文案创作、响应式搜索广告（RSA）架构设计和系统性创意测试框架。核心理念：**创意是自动化竞价环境中最大的可控杠杆**，当算法接管了出价、预算和定向时，每一条标题、描述、图片和视频都是一个待验证的假设。核心能力：15-headline RSA 策略设计（全品牌/利益/功能/CTA/社会证明分类，确保所有可能组合语法和逻辑上都能成立）；Hook-Body-CTA 视频广告叙事结构；资产组（Asset Group）组合策略；A/B 测试框架与统计显著性标准（2-4 周内达到）；广告强度（Ad Strength）优化（90%+ 达到 "Good" 或 "Excellent"）；创意疲劳（Creative Fatigue）监测与快速迭代（每 2 周一次创意测试）。成功指标：CTR 提升 15-25%、转化率提升 5-10%、测试后 2-4 周内达成统计显著性。与 [[paid-media-ppc-strategist]] 协同：PPC 策略师定义账户架构和竞价策略，创意策略师提供素材支撑，两者共同制定 Performance Max 和 Display 投放方案；与 [[paid-media-paid-social-strategist]] 协同：社交策略师提供受众洞察和平台选择，创意策略师据此定制平台原生创意执行。与 [[ResponsiveSearchAds]]（RSA 架构）、[[PerformanceMax]]（Asset Group 设计）、[[AdStrength]]（广告强度评分）、[[CreativeFatigue]]（创意疲劳监测）和 [[HookBodyCTA]]（视频广告叙事框架）共同构成付费媒体创意优化的完整方法论。 + +**[[paid-media-tracking-specialist]]**（Tracking Specialist）：付费媒体追踪专家——负责转化追踪配置、数据归因建模和跨平台效果归因。与 [[paid-media-ppc-strategist]] 协同：为竞价策略优化提供可靠的数据基础。 + +**[[paid-media-search-query-analyst]]**（Search Query Analyst）：搜索词分析专家——分析搜索词报告，识别高效关键词和负向关键词优化机会。与 [[paid-media-ppc-strategist]] 协同：提供关键词策略的数据支撑。 + +**[[paid-media-auditor]]**（Auditor）：付费媒体账户审计专家——系统化评估 Google Ads、Microsoft Ads 和 Meta Ads 账户，覆盖 200+ 检查点（账号结构/追踪配置/竞价策略/创意/受众/竞争定位），每项发现附严重程度和预估业务影响。与 [[paid-media-ppc-strategist]] 协同：基于后者定义的基准进行效果诊断。成功指标：审计通常识别 15-30% 效率提升机会，80%+ 高优先级建议 30 天内落地。 + +**[[paid-media-paid-social-strategist]]**（Paid Social Strategist）：跨平台付费社交广告专家——覆盖 Meta（Facebook/Instagram）、LinkedIn、TikTok、Pinterest、X 和 Snapchat，设计从引流到再营销的全漏斗社交广告项目。核心理念：社交广告本质是"打断"而非"回答"，必须构建平台原生体验而非跨平台复用创意。核心能力：全漏斗架构（引流→互动→再营销→留存）、平台差异化创意策略、像素/CRM 受众工程、Conversions API 实施、SKAdNetwork 应对 iOS 隐私变化。与 [[paid-media-ppc-strategist]] 和 [[paid-media-programmatic-buyer]] 同属付费媒体体系，但专注社交渠道而非搜索或程序化展示。关键决策原则：跨渠道预算分配必须基于搜索+展示+社交综合数据验证，而非单一渠道数据。 + +Key concepts: [[PerformanceMax]], [[SmartBidding]], [[AccountArchitecture]], [[TieredCampaignArchitecture]], [[IncrementalityTesting]], [[ConversionActionHierarchy]], [[CustomerMatch]], [[BudgetPacing]], [[ResponsiveSearchAds]], [[AdStrength]], [[CreativeFatigue]], [[HookBodyCTA]], [[MessageMatch]], [[ABTesting]], [[AdExtensions]] + +### The Agency — Product 部门 +|The Agency 的 Product 部门涵盖用户反馈分析、趋势研究、产品路线图规划和行为引导等专业 Agent。| + +**[[product-feedback-synthesizer]]**（Product Feedback Synthesizer）：The Agency 产品部门的用户反馈综合分析专家 Agent——专精于从多渠道（调查/访谈/工单/评论/社交媒体）收集、分析和综合用户反馈，将海量用户声音蒸馏为可量化的产品决策依据。核心能力：NLP 情感分析与满意度建模（NPS/CSAT/CES）、RICE/MoSCoW/Kano 多维度优先级框架、用户旅程映射与痛点识别、流失预测与早期预警系统。核心理念：**定性反馈 → 定量优先级 → 数据驱动路线图**。成功指标：24 小时内处理关键问题、90%+ 主题准确率（利益相关者验证）、85% 综合反馈产生可衡量决策、NPS 提升 10+ 分、80% 反馈驱动功能成功率。与 [[product-sprint-prioritizer]]（Sprint 迭代优先级）和 [[product-trend-researcher]]（产品趋势研究）协同，共同构成 The Agency 产品部门的数据驱动决策体系。 + +**[[product-trend-researcher]]**（Product Trend Researcher）：The Agency 产品部门的专家级市场情报分析师——专注于新兴趋势识别、竞争分析和机会评估，为产品战略和创新决策提供可操作的洞察。核心能力：七步趋势识别流程（信号收集→模式识别→上下文分析→影响评估→验证→预测→可操作性）；覆盖 50+ 数据源实时聚合，统计验证的弱信号检测，提前 3-6 个月识别主流采纳前的趋势；TAM/SAM/SOM 三层市场量化（置信区间 ±20%）；竞争情报框架（直接/间接/新兴/技术/替代）。成功指标：80%+ 准确率的 6 个月趋势预测、90% 洞察转化为战略决策、48 小时内紧急请求响应、15+ 独立验证来源/报告。与 [[product-manager]] 协同——后者提供产品规格与市场定位输入，前者提供趋势情报与竞争格局分析；与 [[product-feedback-synthesizer]] 互补——后者分析已有用户反馈，前者预判未来市场趋势，共同构成数据驱动的产品决策闭环。属 The Agency 产品部门的市场情报核心层。 + +**[[product-manager]]**（Product Manager Agent — Alex）：The Agency 产品部门的核心战略 Agent——以 10+ 年 B2B SaaS/消费者应用/平台业务经验的产品经理身份，自主拥有从发现到衡量的完整产品生命周期。核心理念：**以结果为导向，而非产出**，功能是假设，发布是实验，成功的产品必须 measurable 改变用户行为。核心交付物：PRD（含机会评估/用户故事/Launch Plan/风险矩阵）、Opportunity Assessment（RICE 评分）、Now/Next/Later 路线图、GTM Brief、Sprint Health Snapshot。六阶段工作流：Discovery → Framing/Prioritization → Definition → Delivery → Launch → Measurement。核心原则：**先问题后方案**（永远不接受表面的功能请求）、**写新闻稿再写 PRD**、**无 Owner/Metric/Time Horizon 不上路线图**、**经常说"不"保护团队焦点**。与 [[Agents-Orchestrator]] 协同——由编排器协调任务；与 [[product-feedback-synthesizer]] 互补——后者收集用户反馈，前者将反馈转化为产品决策和交付计划。属 The Agency 产品部门的战略决策核心层。 + +**[[product-sprint-prioritizer]]**（Product Sprint Prioritizer）：The Agency 产品部门的冲刺规划与优先级排序专家 Agent——专注于敏捷冲刺规划、特性优先级排序和资源分配，通过数据驱动的优先级框架最大化团队交付价值。核心能力：RICE/MoSCoW/Kano/Value vs. Effort 等多框架优先级评分；基于 6 个冲刺滚动平均值的团队速率预测（偏差 < 15%）；冲刺前五步准备（Backlog Refinement → 依赖分析 → 容量评估 → 风险识别 → 干系人审查）；技术债务与新功能的 ROI 平衡建模；跨团队依赖识别与关键路径分析。成功指标：承诺故事点交付率 90%+、干系人满意度 4.5/5、时间线偏差 ±10%、技术债务占比 < 20%。核心理念：**数据驱动的优先级决策**——每个评分附置信区间和敏感性分析；**冲刺目标先行**——无清晰可衡量目标的冲刺不上计划；**主动风险管理**——风险评分（概率 × 影响矩阵）定期重新评估。与 [[product-manager]] 协同——PM 制定路线图，本 Agent 将路线图转化为可执行的冲刺计划；与 [[product-feedback-synthesizer]] 互补——后者提供用户反馈驱动的优先级输入，前者将优先级决策转化为 Sprint 容量规划。属 The Agency 产品部门的执行规划核心层。 + +### The Agency — Finance 部门 +|The Agency 的 Finance 部门涵盖自主支付运营、财务分析与合规管理等专业 Agent。| + +**[[accounts-payable-agent]]**（Accounts Payable Agent）：The Agency 财务部门的自主支付运营专员 Agent——处理供应商付款、承包商发票和周期性账单，覆盖 ACH/Wire/Crypto/Stablecoin/Payment API 等全支付通道。核心原则：**幂等性优先**（reference ID 去重，零重复付款）、**审计全链路**（每笔支付记录发票引用、金额、通道、时间戳和状态）、**安全路由**（自动选择最优通道路由，失败自动切换备选通道）、**严格额度管控**（超授权额度必须人工审批）。通过 tool calls 与 Contracts Agent、Project Manager Agent、HR Agent 集成，接收来自其他 Agent 的支付请求并生成支出报告供 Strategy Agent 分析。成功指标：零重复付款、< 2 分钟执行时间（快捷通道）、100% 审计覆盖、60 秒内 escalation SLA。属 [[Multi-Agent-System-Reliability]] 的财务合规执行层，[[Accounts-Payable-Agent]] 为 The Agency 提供可信赖的支付执行基础。 + +### Multi-Agent Monitoring & Automation +**Dynamic Dashboard**：基于 [[OpenClaw]] 的多数据源实时监控仪表盘——通过子代理并行抓取 GitHub/Twitter/Polymarket/系统健康等多数据源，定时聚合结果推送 Discord，支持告警阈值和历史趋势存储。用对话式指令替代数周前端开发，立即获得实时洞察。[[polymarket-autopilot]] 是 Polymarket 市场监控的具体实现——AI Agent 24/7 自动监控预测市场、分析概率变化、自动执行交易策略。与 [[self-healing-home-server]] 的系统监控场景关联，[[earnings-tracker]] 的市场数据监控场景扩展，[[content-factory]] 共享子代理并行执行模式。 + +**[[multi-source-tech-news-digest]]**：AI Agent 驱动的多源科技新闻自动聚合与投递系统——四层数据管道整合 46 个 RSS 源、44 个 Twitter/X KOL 账号、19 个 GitHub Releases 仓库和 4 个 Brave Search 主题，覆盖 109+ 信息源；通过标题相似度去重和多维度质量评分（priority source +3, multi-source +5, recency +2, engagement +1）生成精选简报；支持 Discord/Email/Telegram 三通道投递，30 秒内通过自然语言添加自定义来源。属 [[Daily-YouTube-Digest]] / [[Daily Reddit Digest]] 同款 Cron Job + AI 摘要模式的不同垂直场景（前者视频，后者 Reddit 社区，本方案文字新闻）。 + +### Cloud Transformation & DevOps +**[[cloud-learning-master-index]]**（Cloud Learning Master Index）：OpenText/微焦点云转型学习会话视频总索引，NAS 源位于 `/volume2/work/Public Cloud Learning Sessions/`，覆盖 10 大技术领域共 **111 个视频**——AWS Landing Zone（22）、OpenText Series（21）、EKS & Kubernetes（14）、Security（9）、Networking（9）、Serverless & AI（9）、FinOps & Cost（10）、CI/CD & GitOps（8）、IAM & Identity（3）、Terraform & IaC（6）。该索引是所有 CTP 专题视频的元数据入口，涵盖从基础设施（AWS Landing Zone）到应用层（Serverless/AI）的完整知识体系，为工程师和架构师提供按主题快速定位学习资源的导航能力。 + +Git 是云转型计划中 DevOps 与 CI/CD 流水线的基础技能。**[[ctp-topic-2-git]]**（CTP Topic 2）作为 CI/CD/GitOps 系列的开篇，涵盖 Git 版本控制系统基础概念与实践，与 [[ctp-topic-9-ci-cd-with-gruntwork]]（Gruntwork CI/CD）和 [[ctp-topic-33-an-introduction-to-gitops]]（GitOps 入门）构成完整的学习链路。**[[ctp-topic-3-deploy-and-maintain-infrastructure]]**（CTP Topic 3）深入 Landing Zone 环境下的基础设施部署方法论——核心区分：Service Module（业务视角，满足业务需求的一组模块组合）与 Regular Module（技术视角，单一技术构建块）；Terragrunt HCL 文件通过版本锁定而非 master 分支引用模块；Service Catalog 支持三级复用（单账户→产品团队→跨团队）。类 OO 继承原则：抽象层次越高，配置选项越少。Terragrunt 在运行前预取所有依赖，通过缓存目录管理克隆仓库。属 IaC 模块化治理的基础原则层，与 [[ctp-topic-9-ci-cd-with-gruntwork]]（CI/CD 实践）和 [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]（Atlantis 工具）共同构成完整的 IaC 知识链路。注意：[[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]] 提到 Atlantis 当前不支持 EKS 部署，两者存在实践约束差异，需通过 Jenkins + Terragrunt 替代。 + +**[[ctp-topic-9-ci-cd-with-gruntwork]]**（CTP Topic 9）聚焦 CI/CD 与 Gruntwork 在 AWS Landing Zone 中的实践，基于 Gruntwork 参考架构通过 Terraform/Terragrunt 实现基础设施自动化交付（⚠️ 视频待 Whisper 转录后补充详细内容）。 + +Cloud Transformation Programme (CTP) materials cover AWS landing zones, EKS, Terraform, GitOps, FinOps, observability, security, and enterprise architecture. Key themes: 3 Lines of Defence framework, ITSM, container hardening, backup & DR strategies. DevOps culture focuses on four pillars: Collaboration, Automation (CI/CD, IaC), Continuous Improvement (Kaizen), and Customer-Centricity. Agile practices (Scrum, Kanban) are symbiotic with DevOps. Emerging trends: DevSecOps, GitOps, Serverless DevOps, AI/ML-driven automation, and Edge Computing DevOps. + +**[[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]**（CTP Topic 32）：Atlantis 替代 Jenkins 用于 Terraform IaC 部署——针对当前 Jenkins 流水线初始化慢（多次代码克隆/顺序测试/ECS 预配置）和架构复杂（持续叠加功能导致脆弱）的双重痛点，Atlantis 提供 PR 评论式协作模型，开发者直接在 GitHub PR 上评论 `atlantis plan`/`apply` 即可触发变更，无需独立账号；每个 Landing Zone 共享账户部署单台 EC2 实例，通过 GitHub Enterprise Webhook 接收通知，服务账号负责评论/合并/关闭 PR；跨账户访问通过在各账户部署的 IAM 角色实现；并行构建支持多模块并发 plan/apply；锁定机制防止多 PR 同时操作同一模块产生冲突。Atlantis 在 merge 前即应用变更，确保代码与基础设施始终同步。属 [[GitOps]] 工具实践层，与 [[ctp-topic-33-an-introduction-to-gitops]]（GitOps 概念）和 [[ctp-topic-9-ci-cd-with-gruntwork]]（Gruntwork CI/CD）共同构成完整链路。注意：[[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]] 提到 Atlantis 当前不支持 EKS 部署，两者存在实践约束差异。 + +**[[ctp-topic-33-an-introduction-to-gitops]]**（CTP Topic 33）：Victor Etkin 讲解 GitOps 方法论入门——GitOps 将软件开发原则应用于部署流程，解决部署失败和配置不一致问题。四大原则：声明式配置、版本控制、CD 流程分离、自修复协调器；核心工具仅需 Git。GitOps Controller 持续比对 Git 声明的期望状态与系统实际状态，自动调和偏差。Pull 模型（代理同时监控 Git 和目标系统）比 Push 模型安全性更高，是 GitOps 推荐模式。CI 专注代码构建和分析，CD 专注二进制部署，两者解耦增强安全性。幂等平台（如 Kubernetes）是 CD 流程顺利运行的必要条件。Git 提交日志天然构成合规审计追踪。属 [[GitOps]] 概念层核心来源，与 [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]（Atlantis 工具）和 [[ctp-topic-2-git]]（Git 基础）共同构成 CI/CD/GitOps 完整知识链路。 + +**[[ctp-topic-15-working-with-renovatebot]]**（CTP Topic 15）：Paul Hopkins 主讲 Renovate Bot 自动化依赖项更新——解决"依赖地狱"问题，实时扫描 Docker 镜像/Terraform 模块/Terragrunt 配置/pre-commit 钩子等版本标签，自动发起 Pull Request；通过 Dependency Dashboard 提供全局依赖状态视图；集成 Jenkins 流水线，使用 Podman 容器化运行并配置 Rate Limiting 避免 PR 风暴；提升基础设施安全性（及时修复漏洞）和配置一致性。属 [[GitOps]] 和 [[CI/CD Pipeline]] 的依赖治理层，与 [[ctp-topic-9-ci-cd-with-gruntwork]]（Gruntwork CI/CD）和 [[ctp-topic-33-an-introduction-to-gitops]]（GitOps 入门）共同构成完整的 IaC 知识链路。 + +**[[ctp-topic-56-automated-infrastructure-testing]]**（CTP Topic 56）：Mark Francis 主讲自动化基础设施测试——将软件测试原则应用于 Terraform IaC 代码，通过 TerraTest（Golang 框架）实现 apply → test → destroy 自动化验证循环。核心主张：集成测试超越语法检查，验证实际部署行为是否符合预期；倡导测试驱动开发（TDD）应用于 IaC 领域，先写测试再实现功能；提议将测试编写作为基础设施开发的首要步骤，移除手动验证，追求自动化验证套件和更高的部署信心。核心价值观："让机器做重复的事，把人脑留给复杂的人类问题"。属 [[GitOps]] 和 [[CI/CD Pipeline]] 的质量保障层，与 [[ctp-topic-33-an-introduction-to-gitops]]（GitOps 概念）和 [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]（Atlantis 工具）共同构成 IaC 知识体系。 + +**[[ctp-topic-48-terraform-vs-terragrunt]]**（CTP Topic 48）：Bob（AWS Solutions Architect）对比 Terraform 与 Terragrunt——Terraform（HashiCorp 出品）是云厂商无关的 Golang 应用，通过状态文件将期望状态与实际环境绑定，企业级使用须将状态文件存储在安全可访问位置；Terragrunt 是 Terraform 的轻量封装，贯彻 DRY 原则，通过管理 provider 和 remote_state 块减少跨环境的重复声明。两者命令和语法高度一致（`terraform plan` = `terragrunt plan`），Terragrunt 通过减少硬编码来优化大规模企业部署。辅助工具：Terraform Enterprise（CI 平台 + workspaces）、Gruntwork（预建可定制模块）、Atlantis（Git 集成）、tfsec（静态安全分析）、Terratest（IaC 测试自动化）。属 [[Infrastructure As Code]] 工具选型层，与 [[ctp-topic-3-deploy-and-maintain-infrastructure]]（Terragrunt HCL）和 [[ctp-topic-56-automated-infrastructure-testing]]（Terratest）共同构成 Terraform 生态知识链路。 + +**（本条新增）Learning Sessions ECS Deployment using IAC**（2023-08-08）：JP 和 Raja M 主讲，CTP/SRE 团队通过 Terraform IaC 实现 ECS 容器化应用自动化部署——基于 Gruntwork 仓库构建的 ECS 模块，将 Docker 容器作为逻辑单元，支持 EC2 实例部署；核心功能：自动扩缩容、自动故障恢复、金丝雀部署；通过 Listener 方式集中管理（避免各产品团队重复下载 Gruntwork 代码）；前置条件包括 VPC、ELB 安全组和 EFS 卷挂载；集成 CloudWatch/Splunk/Grafana/Prometheus。ECS 作为 AWS 原生技术与 AWS 服务深度集成，适合追求简单性和紧密集成的场景；属 [[Infrastructure-as-Code]] 在 ECS 场景的实践，与 [[ctp-topic-70-eks-deployment-using-iac]]（EKS IaC 部署）构成容器编排双路径，与 [[ctp-topic-9-ci-cd-with-gruntwork]]（Gruntwork CI/CD）共享 Gruntwork 基础设施基础。与 [[ctp-topic-67-cloud-native-observability-using-opentelemetry]] 在可观测性集成方面关联（ECS 模块集成 CloudWatch/Grafana）。同主题另一来源：[[learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi]]。 + +**[[ctp-topic-16-cross-account-terraform-modules]]**（CTP Topic 16）：Fibos 主讲，多账号 AWS 环境中跨账号 Terraform 模块的中心化部署方案——解决原有 Gruntwork 流水线主要针对单账号设计、账号间直接互访存在安全风险（Blast Radius）的问题。核心架构：基于 **Shared Account（共享账号）** 作为中转站，Jenkins 托管于 Shared Account，检测到模块目录中 `cross-account.json` 标记文件后触发 **ECS Deploy Runner**（ECS 上的 Docker 容器）；该 Runner 通过 Assume Role 访问目标账号的两个角色——`TF state bucket accessor`（读取状态文件）和 `cross-account ECS deploy runner role`（执行资源部署）；角色切换逻辑在根目录 `terragrunt.hcl` 中全局配置。实现三大目标：**安全性**（无 Workload 账号间直接信任）、**自动化**（Jenkins 自动识别模块类型）、**可复用性**（模块代码不硬编码特定账号角色）。属 [[Infrastructure-as-Code]] 在多账号场景的进阶实践，与 [[ctp-topic-9-ci-cd-with-gruntwork]]（单账号流水线）构成演进关系，与 [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]（Atlantis 跨账号角色）共享 Assume Role 机制但执行载体不同（ECS 容器 vs EC2），与 [[ECS Deploy Runner]]（实体）共同构成跨账号部署完整链路。 + +**Learning Sessions Cloud Transformation Programme-Deploying RDS via Terraform**（2023 年，Greg，DBRE 团队）：Greg 来自 Database Reliability Engineering 团队，倡导通过 Terraform IaC 部署任何规模的 RDS 到 AWS，相比控制台具有速度、灵活性、一致性、灾难恢复、文档和自动化六大优势——**代码即文档**。RDS 部署提供两种模块选择：**裸 RDS module**（基础功能）和 **grunt work RDS Service**（推荐生产使用，预建 KMS 密钥加密和 CloudWatch 告警，SRE 核心模块功能弱于 grunt work）。**Terragrunt**（Terraform 封装器）用于保持代码整洁、避免变量重复声明，贯彻 DRY 原则；Day 2 运维（扩缩容、补丁、大版本升级）通过修改 Terragrunt 文件并提交 GitHub PR，由 Atlantis 自动应用变更。监控通过 CloudWatch Dashboard + Alarms 实现，需注意突发性能实例（burstable instance）的 CPU credits 消耗。属 [[Infrastructure-as-Code]] 在 RDS 数据库场景的实践，与 [[ctp-topic-48-terraform-vs-terragrunt]]（Terragrunt 推荐）和 [[ctp-topic-16-cross-account-terraform-modules]]（跨账号 Terraform 模块）共同构成 Terraform 生态知识链路，与 [[ctp-topic-9-ci-cd-with-gruntwork]]（Gruntwork CI/CD）共享 Gruntwork 模块体系。 + +**[[ctp-topic-12-using-ses-smtp-service-terraform-module]]**（CTP Topic 12）：Christian Deckelmann 和 Filos Christolakis 主讲，Micro Focus 团队使用 Terraform 模块自动化部署 AWS SES SMTP 服务以替代传统本地 SMTP 网关——随着业务向云端迁移，本地 SMTP 网关（如 smtbmicrofocus.com）已不再高效，SES 是网络安全部门唯一批准的云端邮件发送方案。Terraform 模块封装了 SMTP 终端节点配置，支持现有应用程序通过标准 SMTP 协议集成，无需重构代码适配 SES API；技术实现：在应用 VPC 中配置 VPC 端点实现私有连接（无需公网访问），通过 IAM 用户凭证作为 SMTP 认证信息并存储于 Secrets Manager，自动化完成 DKIM 验证和 Infoblox DNS 记录创建。两个关键手动步骤：① 申请脱离 SES Sandbox Mode（提交工单获取生产访问权限）以提升发送限额并允许向外部地址发信；② 手动更新 DNS TXT 记录以验证域名所有权（Terraform 难以处理多账号共享域名时对同一 TXT 记录值的追加操作）。未来计划：引入收件人地址限制和凭证滚动更新增强安全功能。与 [[ctp-topic-36-sendgrid-as-an-email-service]] 构成云邮件服务双路径——SendGrid 面向新标准，SES 服务现有应用平滑迁移。属 [[Infrastructure-as-Code]] 在邮件服务场景的实践，与 [[VPC-Endpoint]]、[[Secrets-Manager]] 概念关联。 + +**[[ctp-topic-21-supply-chain-security-in-micro-focus]]**（CTP Topic 21）： + +**[[ctp-topic-24-micro-focus-product-privacy-framework]]**（CTP Topic 24）：Micro Focus 产品隐私框架在云转型中的应用——PSAC（产品安全顾问委员会）与法律顾问合作，将 GDPR/CCPA 等晦涩法律条款翻译为约 110 项低级别技术要求；隐私框架是 STLC（安全开发生命周期）中 13 个安全与隐私轨道之一；通过五类需求（架构类/文档类/法律类/实现类/SAS 运营类）和成熟度模型（0-4 级）评估产品隐私合规状态；通过"蜘蛛图"直观展示产品在安全去标识化、被遗忘权、数据可移植性等 KPI 上的合规现状；最终产出标准化《产品隐私设置文档》，确保客户获得一致的隐私信息参考。属 [[Product Privacy Framework（产品隐私框架）]] 在 [[Micro Focus]] 云转型场景的核心实践，与 [[Micro Focus Security Development Life Cycle (STLC) Overview]]（STLC 整体架构）直接关联。 + +**[[ctp-topic-49-container-lifecycle-hardening-standards]]**（CTP Topic 49）： + +**[[public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w]]**（Public Cloud Learning Sessions，EKS 计算优化专题 Part 2）：Bottlerocket OS（火箭瓶）深度解析——AWS 专为容器工作负载优化的最小化开源 Linux 发行版，核心设计理念：最小化（去除包管理器/Shell/SSH，仅打包必要内核组件）、安全更新（分区镜像 A/B 切换确保原子性）、安全加固（dm-verity 根文件系统加密验证 + SE Linux enforcing 模式 + 根文件系统默认只读）。Variant 机制通过平台+架构+工作负载组件组合在构建时定制功能，支持 Bottlerocket for EKS AMI（自管理节点组）、托管节点组（Managed Node Groups）和 Carpenter 节点池三种集成方式。属 [[Bottlerocket]] 在 [[Amazon EKS]] 场景的核心实践，与 Part 1（Karpenter 计算优化）和 Part 3（EKS Auto Mode）共同构成 EKS 优化三专题完整链路；Part 3 的 EKS Auto Mode 默认使用 Bottlerocket 作为节点操作系统。 + +**[[ctp-topic-67-cloud-native-observability-using-opentelemetry]]**（CTP Topic 67）：AWS 解决方案架构师 Surav 分享的 EKS/ECS 云原生可观测性深度实践——核心主题：可观测性三信号模型（Traces/Metrics/Logs）、OpenTelemetry Collector 架构（Receivers → Processors → Exporters）、ADOT（AWS Distro for OpenTelemetry）的多种 EKS/ECS 部署模式（Sidecar/独立任务/DaemonSet/HA Replicas）。核心观点：**构建可观测的应用是开发者的责任**——开发者需主动在代码中植入观测能力；Trace 捕获应用调用栈各层的处理耗时，是性能瓶颈定位的核心手段；Correlation ID（如 X-Ray Trace ID）使日志事件可深度链接至 Trace 视图。ADOT 在标准 OTEL Collector 基础上封装 AWS 专用组件，包含 SIGV4 Auth Extension 实现 AWS 服务无缝集成，支持 CloudWatch/X-Ray/Prometheus/Grafana 等多种后端。与 [[public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113]]（Jay Comer 概述版）同属 OpenTelemetry 专题，属 Surav 主讲的深度实践版；与 [[ctp-topic-42-grafana-observability-dashboard]]（Grafana 仪表盘）互补，后者为 ADOT 推荐的可视化后端；与 [[ctp-topic-54-esm-saas-log-analytics]]（ELK 日志方案）共同构成企业级可观测性知识体系。 + +**[[public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113]]**（Public Cloud Learning Sessions，Jay Comer 主讲）：AWS OpenTelemetry 可观测性全景介绍——涵盖可观测性定义（通过外部输出推断内部状态）、三信号模型（Metrics/Logs/Traces）、OpenTelemetry 核心架构（OTLP 协议 + 11 种语言 SDK + Collector 组件）、AWS Distribution for OpenTelemetry（统一代理 + EKS Operator 自动注入）、最新发布动态（安全合规/规模化/集中管理面板/日志支持）。Demo 展示 EKS 环境完整链路：Fluent Bit 采集容器日志 → OpenTelemetry Collector（端口 55681）→ Amazon OpenSearch Service，OpenSearch Dashboard 可按 trace group 展示延迟并通过应用组成图定位性能瓶颈。属 [[OpenTelemetry]] 在 AWS EKS 场景的核心实践，与 [[ctp-topic-67-cloud-native-observability-using-opentelemetry]]（CTP Topic 67）同属 OpenTelemetry 专题，与 [[ctp-topic-54-esm-saas-log-analytics]]（ELK 日志方案）共同构成企业级可观测性知识体系。 + +**[[public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks]]**（Public Cloud Learning Sessions，EKS Auto Mode 专题）：AWS EKS Auto Mode 深度解析——将数据平面管理责任从用户扩展至 AWS，覆盖计算节点（Carpenter Controller）、存储（EBS CSI Controller）、网络（AWS LB Controller）和安全（Pod Identity Associations）。Bottlerocket OS 提供最小化安全容器操作系统，自动应用安全补丁；Carpenter Controller 监听控制面版本变更，自动触发节点 AMI 滚动升级；Pod Identity Associations 替代 K8s RBAC 实现 Pod 级 IAM 权限控制，无需修改 ServiceAccount；Prefix Delegation 默认启用优化 Pod 网络 IP 分配。默认两个节点池（General Purpose 锁定 AMD64，System 带 taint），支持自定义节点池指定 Graviton。Auto Mode 兼容所有 Kubernetes-compliant 工作负载，实例附加 12% 管理溢价。属 EKS 运维简化的核心实践，与 [[ctp-topic-59-achieving-reliability-with-amazon-eks]]（EKS 可靠性）、[[ctp-topic-64-scaling-out-with-amazon-eks]]（EKS 扩缩容）共同构成 EKS 完整知识链路。 + +**[[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]]**（CTP Topic 39）：EKS 在受限 Lab Landing Zone 网络环境下的技术实施方案——Spencer 和 Guy 分享。核心问题：Micro Focus 网络的 AWS Lab 环境 IP 地址池不足，无法满足 Octane（IP 密集型 SaaS 应用）的 EKS Pod 需求。解决方案：创建独立私有子网（非主 VPC 子网），由 EKS 模块自定义网络标志控制 Pod IP 分配；Pod 规范设置 `hostNetwork: true` 使其同时访问内部 Micro Focus 网络和外部资源；Terraform/Terragrunt 模块封装完整 EKS 部署逻辑，支持跨账户角色映射。Atlantis 当前不支持 EKS 部署，需通过 Jenkins + Terragrunt 模块替代。属 [[Amazon EKS]] 在受限网络场景下的技术实践，与 [[ctp-topic-70-eks-deployment-using-iac]]（IaC 部署）共同构成 EKS 完整知识链路。 + +**[[ctp-topic-70-eks-deployment-using-iac]]**（CTP Topic 70）：EKS 集群通过 IaC 部署的完整方法论——涵盖容器与 VM 的对比（启动速度/内存效率/可移植性）、EKS 核心特性（完全托管控制平面/零停机滚动更新/IAM RBAC 最小权限）。SRE EKS 模块支持两种部署路径：Terraform（`tera-grant.scl` 定义集群参数+Secret Manager 集成）和 Service Catalog（模块化产品组合+版本选择）。自定义网络通过 EMI（ENI Multi-IP）为 Pod 分配额外 IP 地址解决 VPC CIDR 限制；Cluster Autoscaler 实现 Worker Node 自动扩缩容。监控栈：CloudWatch Agent + FluentBit（DaemonSet）+ Container Insights + AWS OpenTelemetry + Grafana。属 [[Amazon EKS]] 部署方法的完整入口，与 [[ctp-topic-59-achieving-reliability-with-amazon-eks]]（可靠性）、[[ctp-topic-64-scaling-out-with-amazon-eks]]（扩缩容）、[[public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks]]（Auto Mode）共同构成 EKS 完整知识链路。 + +**[[ctp-topic-59-achieving-reliability-with-amazon-eks]]**（CTP Topic 59）：Amazon EKS 可靠性最佳实践——AWS 高级解决方案架构师 Surav Paul 主讲。涵盖 EKS 容器服务选型（ECS vs EKS）、可靠性定义（可预测行为、故障检测、优雅降级、自愈、按需扩缩）、shared responsibility model（AWS 负责控制平面，客户负责工作节点/OS/应用配置，Fargate 模式下客户无需管理节点）、应用层可靠性（避免单例 Pod、AZ 分散、拓扑分布约束、HPA/VPA 扩缩容、Rolling/Blue-Green/Canary 部署、存活/就绪/启动探针、PodDisruptionBudget）、控制平面可靠性（监控 API server 指标、安全认证加固、准入 Webhook 管理、集群升级 14 个月支持周期）和数据平面可靠性（节点问题检测、资源预留、QoS、资源配额、Pod 优先级抢占）。属 [[Amazon EKS]] 生产级可靠性保障的核心知识来源，与 [[ctp-topic-70-eks-deployment-using-iac]]（IaC 部署）和 [[ctp-topic-64-scaling-out-with-amazon-eks]]（扩缩容）共同构成 EKS 完整知识链路。 + +**[[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]]**（CTP Topic 4）：云转型计划中敏捷实践的落地经验——Heather Norris 主讲。核心内容：①框架演进——从 Scrum（两周 Sprint，含 Product Backlog/Sprint Planning/Retrospectives/Reviews/Daily Scrum）因"Sprint 期间不允许变更"的问题而转向 Kanban 持续流动模式；②混合方案——以 Kanban 为主（随时可调整优先级、持续交付），同时保留 Scrum 的固定仪式（每日站会和回顾会议）；③Microsoft Planner 看板——五列布局（Backlog/To Do/In Progress/Program Key Decisions/Icebox），每张卡必须指定单一负责人、链接依赖、设置优先级和截止日期；④核心价值观——"Agile is all about getting that rapid feedback to make the product and make the development culture better"。属 [[Agile Ceremonies]] 和 [[Scrum]] vs [[Kanban]] 在企业级云迁移场景下的实战案例，与 [[ctp-topic-57-product-backlog-managing-demand]]（需求管理）和 [[ctp-topic-30-managing-change]]（变更管理）共同构成 CTP 项目管理知识体系。 + +**[[public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109]]**（Public Cloud Learning Sessions 20240109）：业务分析（Business Analysis）基础技能与三大核心技法——T型技能模型、BOSCARD框架、干系人轮盘（Stakeholder Wheel）、结合元数据的用户故事需求收集。业务分析将业务需求与技术变更解决方案对齐，涵盖IT系统变更、流程变更、培训和角色转换。BOSCARD（Background/Objectives/Scope/Constraints/Assumptions/Risks/Roles/Deliverables）通过澄清背景、目标、范围等8个维度定义复杂新工作，"早期锁定范围无价"。干系人轮盘从客户出发顺时针识别所有项目干系人。INVEST原则（Independent/Negotiable/Valuable/Estimable/Small/Testable）用于检查需求质量。属 [[Product-Backlog]] 和 [[Demand-Management]] 的前置技法层，与 [[ctp-topic-4]]（敏捷实践）和 [[ctp-topic-57]]（需求管理）共同构成云转型计划的完整方法论（规划→需求→执行）。 + +**[[ctp-topic-18-wide-area-networking-in-aws-cloud]]**（CTP Topic 18）：AWS 广域网架构设计——Micro Focus IT 网络架构师 Christian Deckelman 主讲。核心架构：全球划分为 APJ/EMEA/AMS 三个地理区域，每个区域设立 Hub（如 EMEA 伦敦、AMS 俄勒冈），所有 Landing Zones 通过 TGW Peering 以星型拓扑接入区域 Hub，区域 Hub 之间全网状互联。现阶段 TGW 间路由依赖静态前缀列表，缺乏 BGP 动态路由，DR 场景需人工干预。演进路线：引入 Silver Peak SD-WAN 作为叠加网络实现动态路径选择；Pulse VPN 迁移至 Palo Alto Prisma Access (SASE) 实现就近接入并打通 SD-WAN 骨干。属 [[AWS-Transit-Gateway]] 架构实践，与 [[ctp-topic-25-labs-landing-zone-overview-itom-teams]]（Labs LZ 网络）和 [[ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]]（网络分段）共同构成 Landing Zone 网络知识体系。 + +**[[ctp-topic-25-labs-landing-zone-overview-itom-teams]]**（CTP Topic 25）：Labs Landing Zone 运维团队视角——Labs LZ 基于 Gruntwork 参考架构，采用多账户策略，全部资源通过 Terraform/Terragrunt 管理（Jenkins 流水线扫描 GitHub 仓库变更触发 plan/apply）；核心账户包括：Shared（托管 Jenkins 主节点和加固 AMI）、Logs（CloudTrail/Config 日志集中存储）、Security（联邦用户和跨账户访问）、Core（AD 管理 Windows 实例和 IDP、DNS 管理 Swimford.net）、Network（Transit Gateway + JetPult 防火墙管理所有互联网流量，Pulse VPN 提供 Micro Focus 网络访问）、Shared Services（45 Arc Site 监控、Qualys 漏洞扫描）。Product Account 通过 Terraform 模块部署 subnet，需与网络团队协调 IP 范围和标签策略，防火墙通过标签自动配置网络访问策略。属 [[AWS-Landing-Zone]] Labs 视角的运维实践，与 [[ctp-topic-1-gruntwork-landing-zone-architecture]]（架构基础）和 [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]]（SaaS vs Labs 职责划分）共同构成完整的 AWS Landing Zone 知识体系。 + +**[[ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]]**（CTP Topic 31）：AWS Landing Zone 网络隔离与安全远程访问方案——解决 On-prem 系统和 VPN 用户因共享网络配置而可直接访问生产工作负载的安全风险。核心方案：①网络隔离通过 Checkpoint 防火墙启用 SPI 特性（default-deny），阻断内部网络对 AWS 网段的直接连通；②安全访问通过 AWS Systems Manager (SSM) 替代 VPN，用户假设 IAM 角色访问目标 EC2 实例上的 SSM Agent，支持浏览器会话和 AWS CLI 两种模式，提供双因素认证和 AWS 网络内安全连接。定位为 SD-WAN 实施前的过渡方案；长期演进目标为 IaC 化以消除控制台访问，break-glass 访问仅保留用于紧急场景。与 [[ctp-topic-18-wide-area-networking-in-aws-cloud]]（广域网架构）互补——后者关注如何打通网络，Topic 31 关注如何限制网络访问；两者共同构成 Landing Zone 网络知识体系。属 [[AWS-Landing-Zone]] 网络安全层的核心实践。 + +**[[ctp-topic-8-obm-cloud-monitoring]]**（CTP Topic 8）：使用 Micro Focus Operations Bridge Manager (OBM) 实现 AWS 公有云监控的完整解决方案——OBM AWS Account 部署 OBM 应用、Postgres RDS 和 Operation Agent 三层组件；Agent 通过 AWS Management Pack 利用 IAM Role 信任关系跨账户采集 CloudWatch 指标，无需在被监控账户安装服务器或共享 Access Key；Global OBM 作为 Manager of Managers 汇聚多区域 Regional OBM 数据，事件通过 SMACKS 触发工单；新增实例自动发现、策略自动下发，解决云环境动态性监控难题；支持任意公有云（AWS/Azure/GCP）的 CloudWatch 兼容服务。与 [[ctp-topic-29-cloud-monitoring-saas-lz-accounts]]（账户架构）互补构成完整监控体系，属 [[AWS-Landing-Zone]] 监控层的核心实践。 + +**[[ctp-topic-54-esm-saas-log-analytics]]**（CTP Topic 54）：ITOM ESM SAS 架构师 Jackie 主讲的企业级日志分析解决方案（ESM SaaS）——涵盖 ELK/OpenSearch 技术栈架构（BEATS 采集 → Logstash 处理 → Elasticsearch/OpenSearch 存储 → Kibana 可视化）、双 VPC 隔离架构（应用 VPC + 日志 VPC）、Redis 缓冲层防止 Logstash 过载。安全加固涵盖静态加密（NVMe 硬件级）、传输加密（TLS 1.2）、VPC 私有流量和 RBAC 访问控制；GDPR 合规要求推动日志农场按区域分割部署（美国俄勒冈、欧洲）。方案对比：AWS OpenSearch（~$1,500/月，SLA 99.9%，推荐）、Logz.io（~$4,000/月，SLA 99.8%）、自托管 ELK（成本低维护高）、Microfocus OBA（商业成熟，列级访问控制）。起步建议先用 Logz.io 试用，再迁移 AWS OpenSearch。与 [[ctp-topic-8-obm-cloud-monitoring]] 同属企业监控体系，Topic 8 聚焦指标监控，Topic 54 聚焦日志分析，共同构成完整可观测性视图。 + +**[[ctp-topic-42-grafana-observability-dashboard]]**（CTP Topic 42）：企业级 Grafana 可观测性平台在 AWS 多账户环境下的架构设计与 Terraform IaC 自动化实践——涵盖 Grafana 核心定位（不存储数据，仅从数据源可视化）、基础设施架构（监控账户部署 Grafana，通过 IAM 角色跨账户访问产品团队 AWS 账户）、用户和团队访问控制（Editor/Viewer/Admin 角色）、示例仪表盘（CPU/I/O/Network/EBS/Estimated Charges）、告警系统（Microsoft Teams 通知）、Terraform 模块化供给（数据源模块 + 组织模块 + LZSAP 自动化接入）、Prometheus 网络监控（Checkpoint/防火墙 SNMP 指标）。与 [[ctp-topic-54-esm-saas-log-analytics]]（日志分析）同属可观测性专题，共同构成监控知识体系；长期目标是构建应用级仪表盘替代 [[Micro Focus Operations Bridge Manager]]。 + +**[[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]]**（CTP Topic 35）：AWS Landing Zone 设计复习——重点明确 SaaS（生产）与 Labs（开发）的职责划分。SaaS Landing Zone 为每个产品区域提供客户专属环境，产品账户连接至共享服务账户（安全、日志、网络）；核心账户组包含 AD、DNS 和 Network 账户；Gruntwork 账户跨所有账户管理 AMI、日志和安全。近期变更：网络分段阻断对 SaaS 工作负载的直接连通性；CCOEs CloudTrail 取代 Gruntworks CloudTrail 实现统一审计；入站流量拟通过 Network 账户 Checkpoint 重新路由；原生 AWS Backup 有望强制化；新账户可能取消 Management VPC。核心结论：**SaaS = 生产，Labs = 开发**；PoC Landing Zone 将并入 Labs 以最大化资源共享；Cloud Technology Design Forum 推动 Micro Focus 云交付标准化。 + +**[[ctp-topic-6-aws-workspaces-demo]]**（CTP Topic 6）：AWS Workspaces 虚拟桌面解决方案实操演示——通过 AWS Workspaces 为云转型团队提供托管 Windows 虚拟桌面（Windows Server 2016），预装 PFSSO、Terraform、TerraGrunt、Git 和 VS Code。用户通过邮件联系 Naga 申请账号，接收注册码和用户名后登录，可立即访问 AWS Console（Federation）和 GitHub Enterprise 并生成 SSH 密钥。演示全程约 21 分钟完成仓库克隆、PFSSO 认证和 TerraGrunt Plan 执行，达成"申请后 45 分钟内运行 Terraform"的目标。未来计划与 Active Directory 集成实现自动化账号管理。属 [[AWS-Landing-Zone]] 用户端工具层的核心实践，与 [[ctp-topic-1-gruntwork-landing-zone-architecture]]（基础架构）和 [[ctp-topic-9-ci-cd-with-gruntwork]]（CI/CD 流程）共同构成完整的"架构→交付→使用"链路。 + +**[[public-cloud-learning-sessions-aws-end-user-compute-services-20240430]]**（Public Cloud Learning Sessions，Christian O'Donough 主讲）：AWS 终端用户计算（EUC）服务全景介绍——覆盖四大服务：① **Workspaces**（全持久虚拟桌面，适合知识工作者一对一实例管理）；② **AppStream 2.0**（选择持久/非持久应用流，多租户模式降低成本，适合实验室/培训/堡垒主机）；③ **Workspace Core**（提供 VDI 基础设施 API，支持 Horizon View、Citrix 等第三方集成）；④ **Workspace Web**（低成本安全浏览器）。核心选型原则：需要完整桌面 → Workspaces；非持久桌面/应用流 → AppStream 2.0；第三方 VDI → Workspace Core；安全浏览 → Workspace Web。安全措施包括 Active Directory 集成、加密、IAM 配置文件、SAML 认证和多因素认证。属 [[AWS-Landing-Zone]] 用户端计算层的理论基础，与 [[ctp-topic-6-aws-workspaces-demo]]（实操演示）共同构成完整的 EUC 知识体系。 + +**[[ctp-topic-7-saas-landing-zone-design]]**（CTP Topic 7）：SAS 生产 Landing Zone 顶层架构设计——定义了完整的四层账户体系：①核心账户（Core Accounts）：Shared 托管 AMI + 主 Jenkins 服务器通过 Lambda 触发各账户 Jenkins slave；Logs 集中管理所有账户日志（CloudTrail/Config/Flowlogs）；Security 托管 IAM 角色。②基线账户（Baseline Accounts）：Network 账户部署区域级 Transit Gateway + Checkpoint Appliance 按标签监控跨账户流量；DNS 账户托管 Route 53，各产品拥有独立托管区；Active Directory 账户提供双 AD 节点实现域加入和资源访问控制。③共享服务账户（Shared Services Accounts）：Software Factory（45 个 hub + Octane Hub + Artifactory）、Cyber（Qalis）、ARC Site、Monitoring（OBM/Sitescope）。④产品账户（Product Accounts）：工作负载置于私有子网，公有子网通过负载均衡器和互联网网关对外暴露，WAF 监控入站流量。自动化部署链路：GitHub 仓库变更 → Jenkins（GitHub Hook 触发）→ Management VPC → Lambda → ECS Cluster，Staging 测试后才部署生产。远程访问从 Checkpoint VPN 迁移至 Pulse VPN（通过 AD 认证）。属 [[AWS-Landing-Zone]] 的原始设计规范，与 [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]]（近期变更）共同构成 SAS LZ 的设计演进脉络。 + +**[[ctp-topic-1-gruntwork-landing-zone-architecture]]**（CTP Topic 1）：Gruntwork AWS Landing Zone 架构基础——核心概念：参考架构（Reference Architecture）是包含核心账户 Shared/Logs/Security 和工作负载账户 Prod/Stage/Dev 的最佳实践起点；Landing Zone 基于 Gruntwork 仓库但由产品团队自行定义具体服务；安全账户使用联邦用户（Federated User），通过 AD 组映射到 IAM 角色；每个 Landing Zone 配置独立 Jenkins 服务器和特性分支 Git 工作流。属整个 CTP Landing Zone 系列的基础入门篇。 + +**[[learning-sessions-standard-amis-updates]]**（Learning Sessions 20231205）：AWS 标准 AMI 更新机制与生命周期管理——Jenkins 多分支流水线构建测试 AMI，验证周期从 3-4 天缩短至 60 分钟；支持 23 种 AMI 涵盖 Amazon Linux/CentOS/RHEL/Rocky Linux/SUSE/Ubuntu/Windows；CentOS 7/RHEL 7 将于 2024 年 6 月 EOL，由 Rocky Linux 替代；机器人框架自动化验证是该优化流程的核心。属 [[AWS-Landing-Zone]] AMI 管理层的实践补充。 + +**[[ctp-topic-50-ami-roadmap-for-aws-amis]]**（CTP Topic 50）：CCOE AMI 路线图详解——涵盖 CCOE AMI 路线图规划、操作系统 EOL 时间线（Windows Server 2008/2008 R2 已 EOL；CentOS 8 已 EOL；Windows Server 2012 将于 2023 年 10 月 EOL；RHEL 7 和 CentOS 7 将于 2024 年 6 月 EOL）、AMI 通知机制、变更日志（CCRE 门户）、新 AMI 添加流程（服务集成→功能启用→构建测试）、当前支持的 AMI 清单及未来路线图（SLES 15/RHEL 9 2022年11月；openSUSE 15/Amazon Linux 2022 2023年1月；Rocky 8/9 2023年3月；RHEL 9.4 ARM/Ubuntu 22.04 ARM 2023年5月）。自 2023 年 5 月起所有 ARM AMI 同步发布。路线图优先级主要由 ADM 需求驱动，变更需通过需求管道流程提交。AMI 通过跨账号共享分发给组织内所有账户。属 [[AWS-Landing-Zone]] AMI 层的路线图补充，与 [[ctp-topic-26-standard-ami-build-publish-share-processes]]（生命周期管理）和 [[ctp-topic-58-aws-ec2-image-builder]]（未来演进方向 EC2 Image Builder）共同构成完整的 AMI 管理知识体系。 + +**[[ctp-topic-26-standard-ami-build-publish-share-processes]]**（CTP Topic 26）：Foundation AMI 全生命周期管理详解——Srihari、Alan 和 Praveen 三位专家主讲。Foundation AMI 基于市场主流 OS（CentOS/Ubuntu/Windows）进行 CIS 安全基准加固，集成 McAfee EPO 防病毒 + Syslog-ng 日志管理 + AD 单点登录 + SSM Agent + SiteScope 监控；使用 HashiCorp Packer + Jenkins 流水线实现镜像创建完全自动化；通过跨账号共享（AMI Sharing）分发至全球多区域（俄勒冈/法兰克福/悉尼），而非物理复制（AMI Copying），避免额外存储成本；每两个月更新，采用 N-2 版本保留策略。责任共担模型：CCOE 提供安全基础镜像，产品团队在其上构建产品特定 AMI。属 [[AWS-Landing-Zone]] AMI 层的核心基础，与 [[ctp-topic-58-aws-ec2-image-builder]]（演进方向 EC2 Image Builder）和 [[learning-sessions-standard-amis-updates]]（2023年更新机制）共同构成完整的 AMI 管理知识体系。 + +**[[ctp-topic-55-aws-firewall-manager]]**（CTP Topic 55）：AWS Firewall Manager 在 Grand Torque 多 Landing Zone 环境中的集中化安全策略管理实践——核心动机：跨 RLABS/R&D/SAS/CAT 多个 Landing Zone 管理安全策略的复杂性；原有 Checkpoint Firewall 无法完全覆盖公网子网流量安全。核心方案：①在独立的 Firewall Manager 账户创建安全组策略，指定目标账户或 OU，自动将基线安全组附加到现有和新实例；②三种策略类型——通用安全组（允许产品团队自增）、审计与强制安全组规则（拒绝过度宽松规则，支持手动或自动修复）、清理未使用冗余安全组；③通过 RAM 前缀列表跨账户共享规则，支持 Atlantis CI/CD 流水线部署。Demo 演示了策略创建后 EC2 实例的自动附加与策略删除后的自动移除。前提条件：OU 内管理员权限 + AWS Config 全账户启用。属 [[AWS-Landing-Zone]] 安全策略集中化管理层的核心实践，与 [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]]（Checkpoint 防火墙）互补——后者提供网络边界防火墙，前者提供实例级别安全组基线。| + +**CTP Topic 10**（[[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]]）：AWS Landing Zone 部署、数据收集策略与基于标签的云原生安全架构——Steve Jarman 和 Pradeep 主讲。核心内容：①Landing Zone 部署前必须深入了解 BU 资产清单、IP 地址空间及数据敏感性；②DNS、Transit Gateway 等基础服务已通过 SRE 团队实现高度自动化；③**基于标签的安全控制机制**——传统基于 IP 的防火墙规则无法适应云环境动态性，转向利用 AWS 标签作为安全凭证；④**SCP 强制执行标签规范**——通过「显式拒绝」逻辑防止用户通过篡改标签绕过审计，确保资源创建时即具备正确的 BU/产品/环境归属；⑤**Checkpoint 防火墙有序层逻辑**——按优先级执行地理屏蔽 → BU 隔离 → 产品隔离 → 环境隔离，实现跨 VPC/On-prem/互联网的精细化流量控制；⑥Inline 层基于账号号的父子规则架构，简化跨账户策略管理。与 [[ctp-topic-1-gruntwork-landing-zone-architecture]] 的安全层扩展，与 [[ctp-topic-28-aws-tag-validation-tool]]（标签审计）共同构成标签治理闭环。 + +**[[ctp-topic-45-automatic-ip-address-allocation-with-ipam]]**（CTP Topic 45）：Infoblox NIOS IPAM 自动分配 AWS VPC IP 地址——通过 YAML 配置文件声明期望子网大小和区域父 CIDR，NIOS 自动分配下一个可用 IP 地址块（≤/24 自动，>/24 需审批）；销毁 VPC 时自动从 IPAM Grid 清除条目；建立单一可信数据源，消除手工电子表格记录。属 [[IPAM（IP Address Management）]] 的机制层详解。 + +**[[ctp-topic-61-workload-vpc-provision-with-ipam-automation]]**（CTP Topic 61）：Workload VPC 完整自动化供给方案——Pushka（Principal SRE）主讲，在 Topic 45 的 IPAM 自动分配机制基础上，展示了端到端 VPC 供给流程。核心增强：多 VPC 批量供给支持、邮件通知机制、CIDR /22 阈值自动审批（更大 CIDR 自动，更小需理由审批）、非路由 IP 地址（如 10.2.0.0/16）支持、使用 AZ ID 避免跨账号不一致。Infoblox Grid 作为全局唯一 IP 地址数据源防止重叠，架构包含休斯顿数据中心主库及冗余 DNS/NTP/DHCP 服务。核心理念：**"只需把信息放到正确位置，一切自动完成。"** 属 [[IPAM（IP Address Management）]] 的应用层扩展，与 [[ctp-topic-45-automatic-ip-address-allocation-with-ipam]] 共同构成 IPAM 的"机制 → 应用"完整链路。 + +Key concepts: [[Process]], [[Value]], [[Value-Stream]], [[Value-Adding]], [[Waste]], [[Benefits-Quantification]], [[Cost-of-Delay]], [[WSJF]], [[SOM]], [[Feature-Level-Value-Breakdown]], [[Program-Demand-Process]], [[Proof-of-Concept]], [[Gate-Process]], [[Solution-Design]], [[Landing Zone Architecture]], [[Product-Backlog]], [[Demand-Management]], [[SMACs]], [[Prerequisite-Phase]], [[Hyper-Care]], [[Octane]], [[Hybrid DNS Resolution]], [[VMware-Cloud-on-AWS]], [[VMware]], [[HCX]], [[SDDC]], [[Stretched-Cluster]], [[Hybrid-Cloud]], [[Multi-Cloud Strategy]], [[Multi-Cloud-ROI]], [[DevOps Culture]], [[CI/CD Pipeline]], [[DevSecOps]], [[Shift-Left-Security]], [[Shift-Right-Security]], [[SAST]], [[DAST]], [[IAST]], [[SCA]], [[Break-the-Build]], [[Agile Practices]], [[DevOps Maturity]], [[DORA Metrics]], [[Infrastructure as Code]], [[Cloud-Native]], [[Cloud Maturity Levels]], [[Cloud Adoption Strategy]], [[Cloud Service Delivery]], [[Cloud DevOps Maturity Model]], [[Cloud Operating Model]], [[Cloud Governance]], [[Cloud Cost Optimization]], [[Serverless Computing]], [[Edge Computing]], [[Green Computing]], [[Data-Warehouse]], [[MPP]], [[Columnar-Storage]], [[Sort-Key]], [[Distribution-Key]], [[Vendor-Lock-In]], [[Data-Sovereignty]], [[NFR（非功能需求）]], [[Error Budget（错误预算）]], [[Chaos Engineering]], [[Product Privacy Framework（产品隐私框架）]], [[STLC（Security Development Life Cycle）]], [[PSAC（Product Security Advisory Committee）]], [[PII（Personally Identifiable Information）]], [[Maturity Model（成熟度模型）]], [[Spider Chart（蜘蛛图）]], [[Product Privacy Settings Document]], [[Data Controller vs. Data Processor]], [[Anonymization & Pseudonymization]], [[被遗忘权]], [[数据可移植性]], [[高可用（High Availability）]], [[灾难恢复架构模式]], [[Vault Lock]], [[ELK Stack]], [[OpenSearch]], [[Logstash]], [[Kibana]], [[BEATS]], [[Filebeat]], [[OpenTelemetry]], [[Fluent Bit]], [[Observability（可观测性）]], [[OTLP（OpenTelemetry Protocol）]], [[Three Signals]], [[Centralized-Logging]], [[Redis缓存]], [[RBAC]], [[TLS]], [[API-Key-Rotation]], [[跨账户备份]], [[增量备份]], [[SPF]], [[DKIM]], [[TLS]], [[API-Key-Rotation]], [[Cyber-Suite]], [[CBC-Mode]], [[SendGrid]], [[Twilio]] vs [[全量备份]]（CTP Topic 72：增量仅捕获变更，节省存储成本）、**[[AWS Backup Audit Manager]]**（BAM，CTP Topic 72：合规审计报告）、**[[AWS-Tagging-Standards]]**（CTP Topic 28：AWS 标签规范，涵盖命名约定、强制标签键、成本标签策略；与 Checkpoint 防火墙安全策略直接关联，标签缺失导致流量拦截）、**[[Tag-Validation-Tool]]**（CTP Topic 28：SRE 团队开发的 Python/Boto3 工具，通过 YAML 配置扫描 AWS 资源标签合规性）、**[[Service-Control-Policies-SCPs]]**（AWS Organizations 策略类型，通过「显式拒绝」逻辑强制执行标签规范）、**[[OU-Layered-Security]]**（通过组织单元分层结构检查标签确保正确归属）、**[[Tag-Based-Security]]**（将资源标签作为安全凭证替代传统 IP 规则）、**[[Checkpoint-Firewall]]**（防火墙供应商，依赖 AWS 标签值配置网络访问策略）、**[[Variables-YAML]]**（Tag Validation Tool 核心配置文件，定义每个账户的合法标签键及允许值）、**[[SRE-Tools-Repository]]**（内部代码仓库，存放 Tag Validation Tool 等 SRE 自动化脚本）：[[WAF]], [[APM]], [[Cloud Security]], [[Cloud Migration]], [[High Availability]], [[Pay-as-you-go]], [[Failover]], [[Multi-factor-Authentication]], [[Data-Governance]], [[Continuous Integration]], [[Continuous Deployment]], [[Lead Time]], [[Time-to-Market]], [[MTTR]], [[MTTD]], [[MTTA]], [[Change Failure Rate]], [[Error Budget]], [[Rollback Rate]], [[Availability]], [[Scalability]], **[[Agentic AI]]**, [[Root Cause Analysis (RCA)]], [[Predictive Maintenance]], [[Deployment Automation]], [[Rightsizing]], [[Automated Security Audit]], [[AI ChatOps]], [[What-If Simulation]], **[[RTO]]**, **[[RPO]]**, **[[Feature Flag]]**, **[[Kill Switch]]**, **[[Progressive Rollout]]**, **[[Micro-Recovery]]**, **[[Deployment-vs-Release]]**, **[[Business Impact Analysis]]**, **[[Public Cloud]]**, **[[Private Cloud]]**, **[[Hybrid Cloud]]**, **[[Shared Responsibility Model]]**, [[Multi-Tenancy]], [[Intentional Cloud Strategy]], **[[Centralized Logging]]**, **[[Cross-Account Monitoring]]**, **[[Multi-Account Deployment]]**, **[[StackSets Deployment Visibility]]**, [[CMDB]], [[Problem-Management]], [[Release-Management]], [[Configuration-Management]], [[Asset-Management]], [[Security-and-Compliance]], [[DRaaS]], [[Canary-Release]], [[Blue-Green-Deployment]], [[Threat Modeling]], [[OWASP-Top-Ten]], [[Bug-Bounty]], [[Vulnerability-Scanning]], [[Penetration-Testing]], [[Compliance-Automation]] + +**[[ctp-topic-40-saas-database-architecture]]**（CTP Topic 40）：SAS 数据库团队在 AWS 云上的架构与运维实践——团队分布于美国/加拿大/印度/以色列，管理 500+ 数据库和 1000+ DB 服务器；支持 Oracle、Vertica、Postgres、DynamoDB、SQL Server、MongoDB、MySQL 等多引擎；高可用架构采用三可用区模式（主库/备用库/见证节点）；使用 Oracle Data Guard、Postgres Active-Passive/Active-Active、RDS HA 实现多活；通过 Terraform、AWS CLI、Shell/PowerShell 实现 IaC 自动化；Oracle GoldenGate 支持零停机迁移。属 [[AWS-Landing-Zone]] 数据库层的核心实践，与 [[ctp-topic-51-purpose-built-databases]]（数据库品类全景）和 [[ctp-topic-66-rds-vs-aurora]]（关系型选型）共同构成完整的 AWS 数据库知识体系。 + +**[[ctp-topic-43-vmware-cloud-on-aws]]**（CTP Topic 43）：VMware Cloud on AWS 混合云服务介绍——VMware 与 AWS 联合开发，在 AWS 裸金属服务器（i3.metal/i3en.metal）上原生安装 vSphere 8，为不完全准备完全迁移至原生云的企业提供中间路线。工作负载可在数秒内往返迁移于本地与云端之间，通过 HCX 实现 any-to-any vSphere 迁移。Brian Reeves 讨论经济学效益：相比常规云方案节省 27% 成本，云经济学团队可提供 TCO 计算。Mike O'Reilly（VMware Staff Cloud Solutions Architect）强调这是真正的联合工程而非简单地将 VMware 软件部署到云端。支持 SDDC 部署，通过 vCenter 管理，支持跨可用区的 Stretched Cluster 高可用架构。属 [[Hybrid-Cloud]] 在 AWS 落地的核心实践，与 [[ctp-topic-53-why-bother-with-cloud]] 存在是否应迁移至云端的观点张力。 + +**[[ctp-topic-53-why-bother-with-cloud]]**（CTP Topic 53）：云转型商业价值论证——用数据说明"为何要上云"。Micro Focus 拥有全球最大的商业数据中心足迹——14个数据中心、近20,000台资产；尽管年营收25亿美元，但 VMware 足迹比规模大8倍的公司还大，硬件利用率不足40%。三个产品从 Bublikan 迁出后下线575台物理服务器，云端仅需240台虚拟服务器替代；Redding 退出时40%的应用直接关机，Houston 有89个空机架和360台未使用服务器。核心理念：**云迁移不仅是成本节约，更是创新催化剂**——赋能产品增强、改善灾备、开拓新市场。当前55%的 AWS 成本发生在 Landing Zone 之外，亟需治理。属 [[Cloud Transformation Programme]] 的战略论证层，与 [[ctp-topic-43-vmware-cloud-on-aws]]（混合云中间路线）共同构成完整的云迁移决策框架。 + +**[[ctp-topic-69-vmware-vm-migration-best-practices]]**（CTP Topic 69）：VMC on AWS 虚拟机迁移最佳实践——基于 VMware 顾问支持的经验分享。核心内容：①架构——VMware Cloud 托管于 AWS 基础设施，通过 Direct Connect 和 Virtual Transit Gateway 实现与本地数据中心的混合云连接；②HCX 多云管理——每次迭代最多支持 200 台 VM 迁移，支持从 STDC 查看本地 vSphere 环境和反向操作；③两种迁移方法——UI 方式（VMware Cloud 原生）和 CCOE 脚本方案（使用输入文件定义 VM 详情）；④成本原则——"Anything which leaves definitely attracts cost"，数据传输产生费用；⑤后迁移管理——通过 Brown to Manage (BHM) 系统集成 SMACS Suite 和 HCMX 实现虚拟机管理。属 [[VMware-Cloud-on-AWS]] 迁移执行层面的核心补充，与 [[ctp-topic-43-vmware-cloud-on-aws]] 互补构成完整的"概述→迁移执行"知识链路。 + +**[[ctp-topic-46-netapps-on-aws]]**（CTP Topic 46）：NetApp 存储系统 AWS 实践——Sandeep 和 Yael 主讲。覆盖传统 NetApp 架构（ONTAP / Aggregate / FlexVol / Qtree / LUN / LIF / SVM）和 AWS 云版本 Cloud Volume ONTAP (CVO)。CVO 通过 EC2 实例提供软件定义存储，支持单节点或 HA 配对（跨多 AZ 同步复制）；数据分层机制将 30 天非活跃数据从 EBS 自动迁移到 S3；SnapMirror 实现块级跨集群复制；支持的迁移工具包括 SnapMirror、NetApp XCP、Cloud Sync、AWS DataSync。组织已在 15 个 AWS 区域部署约 1.3 PB 数据，使用 Cloud Manager 集中管理，计划引入 FSX for NetApp（POC）和 Terraform 自动化部署。属 [[AWS-Landing-Zone]] 存储层架构的核心补充。 + +**[[ctp-topic-51-purpose-built-databases]]**（CTP Topic 51）：AWS 数据库专家 Femi George 分享专用数据库选型与架构原则——核心思维：现代应用"为正确的工作选择正确的专用数据库"，避免一刀切。AWS 提供完整数据库品类：关系型（RDS、Aurora MySQL/PostgreSQL）、NoSQL 键值（ DynamoDB，日处理万亿请求）、文档（DocumentDB，MongoDB 兼容）、宽列（Keyspaces，Cassandra 兼容）、内存（ElastiCache Redis/Memcached）、图（Neptune）、时序（Timestream）、账本。实战案例：Duolingo 用 DynamoDB + ElastiCache + Aurora 组合；Netflix 用 DynamoDB 做高弹性 JSON 文档；Peloton 用 ElastiCache Redis 提供即时客户反馈。云时代 DBA 职能从底层平台管理转向应用创新（查询优化/架构设计）。属 [[AWS-Landing-Zone]] 数据库层的完整品类指南，与 [[ctp-topic-66-rds-vs-aurora]]（关系型内部选型）互补。 + +**[[ctp-topic-68-introduction-to-redshift]]**（CTP Topic 68）：AWS Redshift 数据仓库基础——Redshift 是完全托管的 PB 级云数据仓库，核心架构包含 Leader Node（管理 Schema、元数据、查询计划）和 Compute Node（通过 Slices 执行 MPP 并行查询）。支持列式存储（适合 OLAP 聚合查询）和行式存储两种模式；Sort Key 和 Distribution Key 是性能优化核心；RA3 实例类型性价比最优，支持 AWS 托管 NVMe 存储。属 [[AWS-Landing-Zone]] 数据库层的核心补充，与 [[ctp-topic-51-purpose-built-databases]]（数据库品类全景）和 [[ctp-topic-66-rds-vs-aurora]]（关系型选型）共同构成完整的 AWS 数据库知识体系。 + +**[[ctp-topic-66-rds-vs-aurora]]**（CTP Topic 66）：PostgreSQL RDS 与 Aurora 深度对比——Greg Klau 主讲。核心维度对比：①最小规格和成本（RDS 更低）；②最大容量和 IO 性能（Aurora 更优，适合 > 10-20 TB）；③RTO（Aurora 30秒 vs RDS 2分钟）；④存储灵活性（RDS 有 GP2/GP3/预置 IOPS/磁性，Aurora 按 IO 收费无上限）；⑤架构（RDS：EC2+EBS 分离，Multi-AZ 备用节点；Aurora：跨 3 AZ 的 6 副本共享集群卷）；⑥Blue-Green 部署（仅 Aurora MySQL 支持）；⑦端点设计（Aurora 独立 Writer/Reader Endpoint）。高可用调优技巧：DNS TTL 设为 1 秒、TCP Keep-Alive 快速检测故障、JDBC 连接串配置 reader/writer 端点路由。属 [[AWS-Landing-Zone]] 数据库选型的核心参考。 + +**[[ctp-topic-14-octane-hub-on-aws]]**（CTP Topic 14）：Octane Hub CTO 实战案例——Docker 容器化工作负载从 Bibling Lab 物理服务器迁移到 AWS Landing Zone。核心技术要点：Packer 构建 AMI + Terraform/TerraGrunt 替代控制台脚本（IaC 演进路径）；EFS 适合备份、EBS 适合实时数据库（存储选型原则）；VPC Transit Gateway 实现多 VPC 互联；"紧密镜像现有设置"作为无缝迁移策略。下一步：DR 改进、MSSQL→Postgres 迁移、ECS 演进。属 [[AWS-Landing-Zone]] 从设计到落地的完整案例补充。 + +**[[ctp-topic-22-global-dns-service-offerings]]**（CTP Topic 22）：企业级全球 DNS 服务架构详解——Sankar 和 Vino 主讲。核心架构：Route 53 Private Hosted Zone（私有托管区域）配合 AD 托管 DNS，通过 Route 53 Resolver 入站/出站终端节点打通 AWS VPC 与本地网络的 DNS 查询；Outbound Endpoint 出站规则配置多个区域 AD 域控制器 IP，单区域故障时自动切换确保弹性。本地 Infoblox 平台利用 DNS Anycast 实现全球低延迟和自动故障转移；AWS EC2 不支持 Anycast，需手动维护 IP 列表。DNS 安全涵盖防隧道攻击、防数据外泄及缓存污染；"就近解析"原则优化 Office 365 等全球化 SaaS 访问性能。属 [[AWS-Landing-Zone]] 网络层 DNS 专题，与 [[ctp-topic-19-configuring-dns-within-aws-lzs]] 共同构成 Landing Zone DNS 知识体系——后者（前文）介绍 Route 53 Resolver Inbound/Outbound Endpoints 打通混合 DNS 架构，本视频（后者）聚焦 Landing Zone 内部集中化 DNS 账号的配置实践，Terraform 自动化实现新账号上线即具备完整解析能力。 + +**[[ctp-topic-36-sendgrid-as-an-email-service]]**（CTP Topic 36）：SendGrid 被选定为经典和新 Landing Zone 的标准邮件服务，替换现有语义消息网关（Port 25 不安全、即将停用本地网络）和 SES（每封限制 50 收件人）。SendGrid 支持每封最多 1,000 收件人、全云兼容、TLS 端到端加密和双因素认证；支持计划覆盖每月 500 万封邮件；提供直连 SendGrid（需 TLS）和中继服务器（不支持 TLS 的应用）两种架构，数据通过全球中继节点（伦敦/印度/东京）走私有线路汇至美国数据中心。配置要求：使用 software.microcopy.com 域名、连接 smtp.sendgrid.net:587、启用 TLS；SPF/DKIM 记录为邮件送达必要条件；API 密钥每 180 天轮换，日志保留 7 天。同期 Yu-Yan 分享了 Cyber Suite 加密标准更新，涵盖 FIPS/Java/Golang/Node.js/OpenCell 等行业标准合规模件，可选套件因包含 CBC 模式（弱加密）仅作向后兼容，使用非标准套件的产品需经 PSAC 审查。属 [[AWS-Landing-Zone]] 通信层基础组件，与 [[ctp-topic-37-secrets-certificates-management]] 同属安全运维范畴。 + +**[[ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs]]**（CTP Topic 17）：Paul 讲解 Gruntwork AWS Landing Zones 中的 AD 服务集成——双域名策略（`swinford.net` 用于 R&D Labs，`intsas.local` 用于生产/SAS 环境）；SRE 预制 AMI 内置 PowerShell/Shell 脚本，通过 Terraform `user_data` 实现自动化域加入；旧域名 `infra` 和 `AST` 已废弃，提供明确迁移路径；Linux 支持安全动态更新（Secure Dynamic Updates）自动注册 DNS A 记录；R&D 环境使用 MIM 自助服务，生产/SAS 环境通过 SMACKS 工单系统申请账号。属 [[AWS-Landing-Zone]] AD 集成的核心实践参考。 + +**[[ctp-topic-5-aws-identity-and-access-management-iam]]**（CTP Topic 5）：AWS IAM 核心组件与联邦访问机制——涵盖 IAM Dashboard 四大资源（用户、组、客户托管策略、角色、身份提供商）；联邦用户通过 Active Directory 组映射到 IAM 角色实现单点登录；`accounts.json` 位于每个 Landing Zone 根目录，包含账户号列表；IAM 用户主要用于服务账号，人工用户优先使用联邦访问；角色本身不启用操作，而是将"谁可以做什么"与"可以做什么"关联；策略分为 AWS 托管和客户托管两种，Terraform 模块可定义 IAM 角色（假设角色策略 + 内联策略块）；PFSSO 工具实现 CLI 联邦访问；最小权限原则贯穿始终。属 [[AWS-Landing-Zone]] 身份与访问管理层的入门基础，与 [[ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs]]（AD 集成）、[[ctp-topic-11-ad-integration-and-login-using-ad-accounts]]（AD 登录）、[[learning-sessions-identity-governance-vsm-replacement]]（身份治理）共同构成完整的身份治理知识体系。 + +**[[ctp-topic-11-ad-integration-and-login-using-ad-accounts]]**（CTP Topic 11，Niranjan 主讲）：Jenkins 与企业 Active Directory (AD) 的集成，以及 Terraform 代码的自动化质量检查——核心内容：① Jenkins 与 SW Infra AD 的安全域集成，用户入离职通过 AD 账号实现自动化管理，无需手动维护本地用户；② 通过 AD 组策略实现 RBAC 精细化权限控制（只读、读写、流水线创建权限）；③ pre-commit 框架集成 terraform fmt（格式统一）、TFLint（逻辑验证）、Checkov（安全扫描）三款工具，在代码提交阶段自动嵌入安全检查；④ CI/CD 流水线分层治理模式：Commit 阶段仅触发自动化检查 → PR 阶段触发检查+terraform plan → Master 分支人工审核后执行 terraform apply。核心理念：**"左移"（Shift-Left）将安全问题从生产阶段提前到开发早期**，通过分层治理实现基础设施即代码的安全性与稳定性。属 [[AWS-Landing-Zone]] 身份与访问管理层的实践延伸，与 [[ctp-topic-5-aws-identity-and-access-management-iam]]（AWS IAM 联邦访问）共同构成身份治理知识体系。 + +**[[public-cloud-learning-sessions-opentext-tagging-standard-v2]]**（Learning Sessions，Martin Rosler 主讲）：OpenText 云资源标签标准 v2——三大驱动力（成本优化/风险降低/自动化效率）；覆盖云账户、云资源（compute/storage/network）、Kubernetes 对象（namespaces/pods/deployments/services/config maps）和容器镜像；通过标准化前缀（OT\_ / app.opentext.com / com.opentext.image）确保跨平台标签语义无歧义；最佳实践：IaC 自动化替代手动打标、禁止标签存储敏感数据、对频繁变更标签谨慎处理。属 [[AWS-Tagging-Standards]]（CTP Topic 28）同一标签治理领域的补充——前者定义 AWS 内部规范，后者定义 OpenText 跨云统一标准，两者互补。 + +**[[public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20]]**（Learning Sessions）：OpenText 将源代码管理平台从 GitHub Enterprise 迁移至 GitLab——Project Thor 整合 Micro Focus 和 OpenText 工具链，GitLab 作为源代码控制黄金标准；GitHub 许可证12月底到期不续；各团队自主盘点资产、识别流水线并规划迁移（self-serve 模式），Build Hub 提供辅助支持；两种迁移方案（镜像同步 / 搬移重构）；迁移完成标准：代码迁移 + 流水线转型 + PHT 更新；网络连通性挑战通过 Brook Park GitLab 代理解决。属 [[DevOps Culture]] 中企业级工具链标准化转型的典型案例。 + +**[[public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet]]**（Learning Sessions，Arnold Dacan 主讲）：Project Thor 平台架构与数据流设计详解——五大支柱框架（敏捷周期治理、产品发布治理、开发者门户 Backstage、安全与治理、Build Hub）；核心数据流：源代码流（GitLab）→ 制造流程（Build Farms）→ Artifactory → 客户环境；地理分布：工具链主站点 Brook Park + 灾备站点 Sacramento；标准化目标：统一 GitLab/Artifactory/UCMDB 工具链，夯实供应链安全基础。属 [[DevOps Culture]] 企业级工具链标准化与供应链安全的深度补充，与 GitHub→GitLab 迁移文档共同构成 Project Thor 知识体系。 + +**[[ctp-topic-62-aws-secrets-manager]]**（CTP Topic 62）：AWS Secrets Manager 企业级密钥管理深度实践——Nurit 和 Daniel 分享。核心内容：①选型背景——HashiCorp Vault 与 AWS Secrets Manager POC 对比，AWS Secrets Manager 以更低成本和更简实施被选定为最终方案；②AWS Secrets Management Standard 文档——最佳实践文档演变为公有云密钥管理标准，基于 Control Tower 实施经验，包含分阶段方法论（集中化密钥 → 调整自动化获取 → 启动轮换）；③核心原则——开发者无需直接访问密钥，通过 IAM 角色和标签实现访问控制；④实施机会——Oracle DB 用户密码轮换（Lambda 函数连接 Oracle 实例执行轮换，无需邮件传递密码）、SendGrid 集中邮件服务（API 密钥轮换通过集中 SMTP 服务实现，无需应用重启或代码修改）；⑤Demo——Victor 演示使用 JDBC Wrapper + AWS SDK 免密登录 Oracle 数据库，用户名由角色控制，密钥可通过标签进行分类和访问控制。属 [[AWS-Secrets-Manager]] 在企业落地的核心实践，与 [[ctp-topic-37-secrets-certificates-management]]（Secrets 与 Certificates 统一管理框架）互补，与 [[ctp-topic-36-sendgrid-as-an-email-service]]（SendGrid 邮件服务）共同构成安全运维知识体系。 + +**[[public-cloud-learning-sessions-opentext-gis-security-policies-20241015-160257-me]]**（Learning Sessions，Mike & Ed 主讲）：OpenText 全球信息安全团队（GIS）安全策略全景——GIS 是分层组织架构，包含安全运营（事件响应与保障）、合规（认证与政策执行）、治理风险验证（GRV，季度审查 Admin 角色）、隐私（新增集成中）四个支柱。OpenText 采用分层方法定义安全策略——与各团队协作定义"做什么"，与执行团队协作确定"怎么做"；持有 FedRAMP 等多项行业及政府认证，可进入多个垂直市场销售；每月处理 2250 亿条日志，分诊约 350 个案例。姿态框架基于 ISO 27001（2022 年更新，新增 11 个控制方面）；Global Information Security Policy（GISP）是最高纲领性政策，季度审查。安全运营涵盖 Cyber Response Center、威胁情报（BrightCloud）、云安全、安全工具与工程等核心服务；合规组织涵盖合规项目、路线图、产品风险评估、持续合规与审计、自动化等内容。属企业级安全治理体系的核心入门，与 [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]]（AWS 层面标签化安全）互补——GISP 定义全局政策纲领，Landing Zone 层面通过标签和 SCP 实现技术落地。 + +**[[ctp-topic-52-3-lines-of-defence-3lod-framework-cloud-security-posture-management]]**（CTP Topic 52）：Coyote（Enterprise Application Security 负责人）分享 Three Lines of Defence（3LoD）安全治理框架落地和 Cloud Security Posture Management（CSPM）工具选型——3LoD 框架经 ELT 批准后成为组织统一的安全治理模型，明确业务单元（一线：实施管理安全控制）→ 集团职能部门（二线：政策/事件响应/网络安全工具）→ 审计（三线：确保一二线合规）的三层责任分层，解决了此前安全团队和政策碎片化导致的审计问题。CSPM 解决多云账户管理碎片化问题，提供统一的合规框架视图（ CIS、NIST、ISO）和自定义策略能力；Cloud Guard 在 POC 后被选中，核心功能涵盖态势管理、资产管理、网络配置可视化、事件管理和威胁情报，新账户在创建流程中即被纳入 Cloud Guard 确保全面覆盖。核心理念：**从被动安全响应转向主动防御**，通过 CSPM 主动发现和修复云配置偏差。与 [[ctp-topic-55-aws-firewall-manager]]（Firewall Manager 安全组策略）和 [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]]（标签化安全）共同构成完整的云安全防护体系，与 [[public-cloud-learning-sessions-opentext-gis-security-policies-20241015-160257-me]]（GIS 安全策略全景）互补——后者定义组织层面的安全策略框架，前者定义云安全运营的技术落地层。 + +**[[ctp-topic-28-aws-tag-validation-tool]]**（CTP Topic 28）：AWS 标签验证工具——Lewis Brown 主讲，SRE 团队开发的 Python/Boto3 工具。Checkpoint 防火墙通过读取 EC2、安全组、负载均衡器的标签值动态配置网络访问策略，标签缺失或无效将导致流量被拦截；SCPs 可阻止不合规资源创建但无法修复存量资源。该工具通过 `variables.yaml` 定义每个账户的合法标签值，自动扫描 EC2/安全组/负载均衡器/Lambda，生成 CSV 审计报告。使用 Poetry 管理 Python 环境，存放于 SRE Tools Repository。标签策略还计划用于未来成本核算，区分同一账户下不同产品的资源消耗。属 [[AWS-Landing-Zone]] 标签治理闭环的核心补充——制定规范（Topic 10）→ 强制执行（SCPs）→ 审计发现（Topic 28）。 + +**[[ctp-topic-30-managing-change]]**（CTP Topic 30）：云转型中的变更管理与 SRE 团队协作——Brendan Starnig（SRE Function Lead）主讲。核心内容：①SRE 职责——用软件工程思维解决运维问题，追求可靠性、可测试性、可重复性，核心是打破运维与产品的壁垒；②变更分类——Standard Change（预批准，完全自动化 IaC+CI/CD，无需 CAB）→ Normal Change（需 CAB 审批，目标是通过自动化逐步归入 Standard Change）→ Emergency Change（立即执行缓解事故，事后 CAPA/Post-mortem 修复根因）；③SRE 三阶段协作——构建（Build）/早期上线支持（Early Live Support）/BAU；④Self-Healing 演进方向——各产品组分享实践，SRE 协助在监控产品中落地。属 [[AWS-Landing-Zone]] 运维治理层的核心补充，与 [[ctp-topic-28-aws-tag-validation-tool]]（IaC 变更的 Tagging 标准属于 Standard Change 范畴）共同构成变更管理知识体系。 + +**[[ctp-topic-41-nfrs-and-error-budgets]]**（CTP Topic 41）：NFR（非功能需求）与 Error Budget（错误预算）在云转型和敏捷开发中的实践——Micro Focus SRE 负责人 Brendan Standing 主讲。核心内容：①NFR 定义——评判系统运行的准则（可用性、性能、安全性、可扩展性），云环境下应更具规范性，充分利用云原生服务（如 AWS Backup 定时备份 + IaC 基础设施代码化）；②NFR Epic 模板——将 NFR 集成到 Sprint Backlog，确保任何重大变更都考虑非功能需求；③AWS 共享责任模型——云提供商负责基础设施，公司在云中架构和管理服务以满足 NFR；④Error Budget 机制——Error Budget = 1 - 可用性 SLO（如 99.9% SLO → 0.1% Error Budget），用于衡量系统在影响客户前可承受的不可靠程度，驱动开发和运维决策；⑤SLR/SLO/SLA 三层体系——SLR 是可量化的可靠性指标，SLO 定义服务应如何表现，SLA 是客户级别协议；⑥混沌工程——主动注入故障测试系统韧性，确保 NFR 得到满足。核心理念：**Error Budget 将失败归一化为开发流程的一部分，弥合了开发与运维之间的文化鸿沟**。属 [[AWS-Landing-Zone]] SRE 可靠性工程层的核心补充，与 [[ctp-topic-30-managing-change]]（SRE 变更管理）和 [[ctp-topic-72-enterprise-dr-strategy-aws-backup]]（DR 可用性目标）共同构成完整的 SRE 知识体系。 + +**[[ctp-topic-57-product-backlog-managing-demand]]**（CTP Topic 57）：CTP 产品待办列表（Backlog）需求管理完整管道——①需求提交（通过 SMACs 启动计时器和追踪）→ ②双周评审会议（Matthew Chapman/David Grant/Brendan）评估理解度、价值和优先级，约20题评估问卷判断简洁性、成本和野心程度 → ③Octane 特性化（带任务列表）→ ④Sprint 规划（提前6个 Sprint，50% 新需求 / 50% 支持+技术债）→ ⑤Prerequisite Phase（新产品组入职：介绍会议→AWS账户创建→解决方案设计→GitHub仓库→防火墙标签，产品团队约2小时，1-2周）→ ⑥SRE 构建账号并交接（提供控制台/GitHub访问详情）→ ⑦2周 Hyper Care 支持。现有产品组通过 SMACs/邮件/Teams 请求支持，Teams 频道连接产品组、SRE工程师、解决方案架构师和交付经理。核心理念：**透明化需求管道，确保所有工作以同一标准评估**。属 [[AWS-Landing-Zone]] 需求治理层的核心补充，与 [[ctp-topic-20-program-demand-process-flow]]（Gate Process 和 POC 入职）、[[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]]（敏捷实践）、[[ctp-topic-30-managing-change]]（变更管理与 SRE 协作）共同构成完整的 CTP 治理知识体系。 + +**[[public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16]]**（Public Cloud Learning Sessions，Oli Workflow）：超大规模云厂商支出审批工作流与需求管理端到端流程——涵盖两大部分：① **Oli 工作流审批机制**：所有超大规模云厂商支出无论金额均需 MUI 或 Shannon 书面审批；Oli 系统由 Tom Bice 领导的 FinOps 团队接管，正在集成到 SMACs 平台；提议的三阶段审批工作流（FinOps 可行性验证→云服务技术可行性验证→FPNA 团队预算可用性验证）；Oli 系统提供飞行中 CSV 报告追踪状态/申请人/成本中心/月成本。② **OpenText 需求管理全链路**：ITIL 框架下服务战略→设计→过渡→运营→持续改进五阶段；主服务目录（Combined Cloud Products Master Catalog）将嵌入 SMACs；Octane 和 Qixi 是两大需求提交入口；ADM/ITOM 需求规划会议捕获所需内容、数量和发布版本；核心理念：**"机器做机器能做的事"，目标 80% 场景业务单元自助完成需求选择**。属 [[Demand-Management]] 和 [[FinOps]] 在 OpenText 云转型场景的核心实践，与 [[ctp-topic-57-product-backlog-managing-demand]]（Backlog 管理管道）共同构成完整的需求治理知识体系。 + +**[[ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation]]**（CTP Topic 65）：云转型中的价值交付量化框架——提供系统性衡量、捕获和优先排序云转型业务价值的方法论。核心内容：①基础概念——过程（Process）将输入转化为产出/成果，成果分硬性（时间/成本/质量）和软性（健康/安全）；Lean 识别三类活动：增值活动、价值赋能活动、浪费；价值（Value）由客户决定，体现为公平回报；②价值流（Value Stream）分为运营价值流（OVS，面向客户）和开发价值流（DVS，内部产品）；③收益量化框架——涵盖财务、生产力、质量和体验四个维度，聚焦收入增长、成本降低、风险改善和服务可获得市场规模（SOM）；④WSJF 优先级排序——通过 Cost of Delay / Size of Job 比值对工作排序，实现"最小投入尽早交付最大价值"；延迟成本 = 业务价值 + 时间紧迫性 + 风险与机会；⑤功能级价值拆解——可按单一功能归属、均分或不均匀分配（基于触达/影响/努力等标准）。属 [[AWS-Landing-Zone]] 价值治理层的核心方法论，与 [[ctp-topic-30-managing-change]]（变更管理）和 [[ctp-topic-20-program-demand-process-flow]]（需求流程）共同构成完整的 CTP 治理知识体系。 + +**[[ctp-topic-13-cloud-finops-policies]]**（CTP Topic 13）：PCG 团队 Uday 和 Vinay 主讲 Cloud FinOps 成本优化政策与最佳实践——核心架构：PCG 三层服务模型（成本管理：账单支付/showback-chargeback/预算管理 → 成本优化：Reserved Instances 集中购买与资源去优化 → 治理与自动化：集中式上线/策略开发/自动报告）；5 大核心策略（账单可见性、标签合规、账户负责人预算责任、Reserved Instances 集中管理、区域限制）；安全控制（预安装 Godrails、联合身份管理 MFA、告警重定向至安全团队）；Cloud Health 工具提供资源清单和月度账单洞察；标准化实例选型（M/T/C/R/X 系列）+ Graviton ARM 实例节省成本；研发环境三合一优化（突发性实例 + Spot 实例 + 实例调度器）。属 [[FinOps（云财务管理）]] 在 [[Micro Focus]] 云转型场景的核心实践，与 [[ctp-topic-63-optimise-resource-cost-using-automation]]（自动化调度优化）和 [[ctp-topic-71-pcgs-guide-to-rightsizing-why-how-when]]（Rightsizing 最佳实践）共同构成完整的 FinOps 知识链路。 + +**[[public-cloud-learning-sessions-storage-cost-optimization-20240305-160037-meeting]]**（Public Cloud Learning Sessions）：AWS 存储服务成本优化全景——覆盖 EBS（GP3 推荐，比 GP2 便宜 20%，可独立扩展 IOPS/吞吐量；快照支持归档层比标准层低 75% 成本）、EFS/FSx（生命周期策略和分层机制）、S3（Intelligent Tiering 自动冷热迁移无转换费用；生命周期策略管理非当前版本和多段上传过期；数据传输费用需注意，PrivateLink 可规避）和 ADM 迁移案例（OpenZFS → 自管理 NetApp on EC2 → FSx for NetApp ONTAP 实现 60% 成本削减）。属 [[FinOps（云财务管理）]] 存储优化专题，与 [[ctp-topic-13-cloud-finops-policies]]（政策框架）和 [[public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco]]（综合成本优化）共同构成完整 FinOps 知识链路。 + +**[[ctp-topic-63-optimise-resource-cost-using-automation]]**（CTP Topic 63）：使用自动化手段优化 AWS 云资源成本——涵盖五大核心策略：①批准区域（Approved Region）标准化（Oregon/NVirginia/Frankfurt/London/Sydney/Singapore），提高安全性和成本可预测性；②实例类型选择（M6i/M6g 通用型、T3/T4g 经济型、C 系列计算型、R 系列内存型），同配置 M→R 切换节省 35%，Graviton ARM 比 Intel 便宜 20-25%；③承诺计划（1年约 40% 折扣、3年约 60-64% 折扣）；④存储优化（GP2→GP3 节省 20%，及时清理未使用 EBS 卷）；⑤自动化调度（基于标签的 EC2/RDS 启动/停止，通过 Lambda + EventBridge + Terraform Scheduler 模块实现，非 7×24 工作负载每天只运行 10 小时可节省 70% 成本）。属 [[FinOps（云财务管理）]] 技术实施层，与 [[ctp-topic-13-cloud-finops-policies]]（政策框架）和 [[ctp-topic-71-pcgs-guide-to-rightsizing-why-how-when]]（RightSizing）共同构成完整 FinOps 知识链路。 + +**[[ctp-topic-27-aws-instance-scheduler]]**（CTP Topic 27）：Gustavo 主讲 AWS Instance Scheduler 原生方案——通过 CloudFormation 一键部署，由 CCOE Guardrails 框架自动集成推送至公司绝大多数月消费 10 美元以上的 AWS 账号，无需用户手动配置。核心技术栈：CloudWatch Events 定时触发（默认每 15 分钟）→ Lambda 函数读取 DynamoDB 调度配置（Schedules + Periods）→ 根据实例标签（`Schedule`、`Period`）执行启动或停止操作。核心要点：①调度基于"时间表"而非"空闲率"触发；②支持多时区办公时间配置（西雅图时间、英国时间等）；③RDS 实例智能配合每 7 天维护窗口，确保维护完成后恢复正常调度状态；④实例关机行为必须设置为"停止（Stop）"而非"终止（Terminate）"以保留数据。与 [[ctp-topic-63-optimise-resource-cost-using-automation]] 的 Terraform Scheduler 模块（`auto_shutdown` 标签）构成互补方案——Instance Scheduler 覆盖广账户层，Terraform Scheduler 提供 IaC 层细粒度控制。 + +**[[ctp-topic-71-pcgs-guide-to-rightsizing-why-how-when]]**（CTP Topic 71）：PCG 团队讲解 AWS EC2 RightSizing 系统性方法论——核心主题：为何要做 RightSizing、何时做、如何执行的完整指南。问题域聚焦过度配置（over-provisioned）EC2 实例导致的资源浪费。RightSizing 通过分析实例实际资源使用情况，将过度配置的实例调整为合适规格，在不影响性能的前提下实现成本节省。是 [[FinOps（云财务管理）]] 核心技术手段之一。⚠️ 视频尚未完成 Whisper 转录，完整内容待补充。 + +**[[public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco]]**（Public Cloud Learning Sessions，Vinay 主讲）：AWS 云成本优化技术深度实践——**工作负载优化**聚焦现代化（EC2 新代际/Graviton 20-25% 节省/AMD 6-10% 节省/GP2→GP3 存储 20% 节省/EKS 最新版避免扩展支持费/Spot 实例 90% 折扣）和 Right Sizing（EC2 Right Sizing 报告/实例调度/闲置资源清理）。**费率优化**讲解 Savings Plans 和 Reserved Instances 的两种承诺类别（资源级 vs 灵活），以及完整实施流程（前置 Right Sizing → 分析 24/7 工作负载 → 财务沟通 → 账户所有者审批 → 利用率监控报告）。关键规则：承诺计划仅支持无预付选项，最低交易金额 $5k/年，仅由 Phenops 团队实施。属 FinOps 技术实施层，与 [[ctp-topic-13-cloud-finops-policies]]（政策框架）互补，共同构成"政策 → 技术实施"完整链路。 + +**[[public-cloud-learning-sessions-budget-control-20240319]]**（Public Cloud Learning Sessions，SRE Core 团队 Daniela/Evan/Alan 主讲）：AWS 预算控制自动化深度实践——解决 AWS 账户蔓延导致的成本失控问题。核心架构：AWS Budget → SNS → Lambda → Step Functions → SCP Enforcement（服务控制策略封禁新资源创建）的完整告警与执行链路；告警类型分 4 种（Forecast/Actual 80-98%/Severe/Enforcement），评分系统计算宽限期避免月末轻微超支账户被误处罚；Source Identity（STS SourceIdentity 属性）通过 CloudTrail 追踪联邦登录跨角色切换的原始用户身份，实现成本责任到人；初始范围仅限 Lab 账户。属 [[FinOps（云财务管理）]] Enforcement 执行层，与 [[ctp-topic-13-cloud-finops-policies]]（治理与自动化政策）和 [[public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco]]（主动优化手段）共同构成 FinOps 完整闭环（告警→Enforcement→优化）。 + +**[[public-cloud-learning-sessions-best-practices-for-ec2-cost-optimization-in-aws-2]]**（Public Cloud Learning Sessions，Mike Dukes 和 Steele Taylor 主讲）：AWS EC2 成本优化最佳实践深度解析——核心主题覆盖计算效率、Nitro 系统、Graviton 使用、EC2 Spot 竞价实例和容器化成本部署。AWS Nitro 系统通过将网络、存储和安全组件外部化来提升效率；Graviton 处理器基于 ARM64 架构，提供高达 40% 更好的性价比，功耗比同等 x86 实例减少高达 60%；EC2 Spot 实例利用 AWS 闲置容量提供高达 90% 的按需价格折扣；购买选项包括 On-Demand、Savings Plans 和 Spot Instances。Spot Invaders 游戏作为容错混沌工程的实践案例，展示了在 EKS 上使用 Spot 实例构建弹性应用的最佳实践。Graviton 适用于大多数工作负载（Web 服务、容器、HPC 批处理、大数据、CI/CD），但排除有状态服务（如数据库）；Spot 和 Graviton 可组合使用以最大化成本节省。属 [[FinOps（云财务管理）]] 技术实践层，与 [[public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco]]（成本优化技术）和 [[ctp-topic-13-cloud-finops-policies]]（政策框架）共同构成完整的 EC2 成本优化知识链路。 + +**[[public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin]]**（Public Cloud Learning Sessions，AWS 高级解决方案架构师 Suraav Paul 主讲）：AWS AI/ML 与生成式 AI 入门——AI 复制需要人类智能的任务，通过机器学习使用数据创建决策模型；分类 AI 识别模式，预测 AI 预判趋势，生成式 AI 利用基础模型（Foundation Models）创造内容。Amazon 在 ML 领域深耕 20 年，AWS 在四大领域帮助客户应用 AI：提升客户体验、实现更优决策、改善运营、创造新产品。Amazon Bedrock 是全托管生成式 AI 服务，提供 Titan 等多种基础模型，支持微调、持续预训练、RAG 和 Bedrock Agents 等数据定制技术；Guardrails for Bedrock 提供负责任 AI 安全护栏。ML Ops 将机器学习与运维融合，涵盖数据流水线（数据收集/集成/准备）、训练流水线（特征工程/模型训练/超参调优）和推理流水线（部署/监控）。属 Cloud Transformation Programme 的 Serverless & AI 专题入门，与 [[public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111]]（Generative AI & Prompt Engineering，OpenText 技术客户经理 Shikad Holtzman 主讲）和 [[public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee]]（无服务器计算）共同构成 Serverless & AI 知识链路。 + +**[[public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111]]**（Public Cloud Learning Sessions，OpenText 技术客户经理 Shikad Holtzman 主讲）：AWS 生成式 AI 服务与提示工程实践——Shikad Holtzman 阐述生成式 AI 四大价值路径（新体验/员工生产力/洞察提取/创造力激发），涵盖客服聊天机器人、代码生成摘要、文档处理和图像生成等行业场景；核心洞见：**企业数据是差异化关键**，通过 Amazon Bedrock 连接自有数据（无需重训练）即可构建专属生成式 AI 应用，且 Bedrock 保证用户数据与提示词绝不与模型提供商共享。Amazon Bedrock 提供来自 Anthropic/Meta/Amazon Titan 的多种基础模型（含多模态），内置 RAG 知识库、微调、Agents 和 Guardrails for Bedrock 自定义有害内容过滤；Amazon Q 分企业版（多数据源搜索/摘要）和开发者版（代码生成/单元测试/代码迁移）；AWS 专用训练芯片 Trainium 和推理芯片 Inferentia 支撑底层算力。提示工程（Prompt Engineering）是创建、设计和优化提示词引导 LLM 响应的迭代过程，提示由指令、上下文、用户输入和输出指示器四部分组成；基础技巧包括 One-shot/Few-shot（通过示例引导）和 Chain of Thoughts（逐步推理解决复杂任务）。属 Cloud Transformation Programme 的 Serverless & AI 专题，与 [[public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin]]（AI/ML 入门）共同构成生成式 AI 知识链路。 + +**[[public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec]]**（Public Cloud Learning Sessions，AWS AI 专家 Stephen Frank 主讲）：AWS Gen2 AI 发展驱动力与企业在生产中的 AI 应用场景——Stephen Frank 阐述 AI 演进历程（模仿人类行为 → 机器学习 → 深度学习 → Gen2 大语言模型），Gen2 AI 崛起背后的两大驱动力：2000 年代以来数据爆发式增长和更大算力的可获得性。Amazon 在核心产品和服务中应用 AI/ML 已 25 年，将经验应用于新客户产品。通用 AI 应用场景：创造新客户体验、从数据中推断核心洞察、流程自动化、生成新内容；企业软件场景：优化内部流程、启用新功能、创造新产品。**数据是差异化关键**——生成式 AI 应用通过 RAG / Fine-tuning / 持续预训练与企业现有业务数据集成。AWS 三层产品战略：基础设施层（基础模型训练/推理）→ Amazon Bedrock（旗舰 API 访问，承诺不与第三方共享用户数据，符合 GDPR）→ 即用型 AI 应用（Amazon Q 等）。Amazon Bedrock 保证用户数据与提示词不与第三方模型提供商共享；Amazon Q 通过自然语言连接多种企业数据源（知识摘要/内容创建/洞察提取）。AI 实施关键：培育实验文化、灵活选择模型、重视安全治理与合规；负责任 AI 原则：公平性（Fairness）、可解释性（Explainability）、透明度（Transparency）；最佳实践：优先考虑人、评估风险、迭代全生命周期。属 Cloud Transformation Programme 的 Serverless & AI 专题，与 [[public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin]]（AI/ML 入门）和 [[public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111]]（提示工程）共同构成完整的 AI 知识链路。 + +**[[public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee]]**（Public Cloud Learning Sessions，OpenText）：AWS 无服务器计算深度解析——现代企业面临快速创新、安全合规、事件响应和盈利增长的多重压力，Serverless 计算通过将运维任务转移给云厂商，使开发团队专注业务代码。AWS Lambda 是核心服务，开发者只需编写业务逻辑，AWS 负责负载均衡、自动扩展和安全，函数由事件（状态变化）触发，支持同步、异步和事件源映射三种调用模式；Lambda 权限模型分离执行角色（决定函数能调用哪些资源）和资源策略（决定谁能触发函数），版本、别名和 Layers 支持代码管理和复用，ARM64 架构提供更优性价比。Step Functions 基于状态机编排多个 Lambda 函数和 AWS 服务，提供 Standard（长时）和 Express（高频）两种工作流类型；API Gateway 提供边缘优化、区域和私有三种部署选项管理 API 生命周期；SAM（Serverless Application Model）基于 CloudFormation 构建，支持本地开发和测试。属 Cloud Transformation Programme 的 Serverless & AI 专题，与 [[public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin]]（AI/ML 入门）共同构成 Serverless & AI 知识链路，与 [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091]]（事件驱动架构 Part 1）和 [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091]]（事件驱动架构 Part 2）共享事件驱动执行模型。 + +**[[public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091]]**（Public Cloud Learning Sessions，AWS 解决方案架构师 Dr. Anil Giri 主讲）：事件驱动架构（EDA）进阶实践——详解 EDA 三组件（事件生产者/消费者/代理）、事件路由器（EventBridge/SNS）与事件存储（SQS/Kinesis）、编排与编排模式（Choreography vs Orchestration）、幂等性（Idempotency）、事件排序（SQS FIFO/Kinesis 保证顺序）、团队独立性（去中心化所有权 vs 集中式所有权）、Fan-out 模式（SNS 主题/EventBridge 规则）、竞争消费者模式（SQS）、死信队列（DLQ）和 EventBridge 最佳实践（每个订阅者单条规则、避免默认事件总线、失败事件处理）。核心洞见：**"Everything fails every time"**——任何系统任何时刻都可能故障，因此幂等性和 DLQ 是 EDA 生产级落地的必要保障。属 Cloud Transformation Programme 的 Serverless & AI 专题进阶篇，与 [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091]]（Part 1）构成完整 EDA 知识体系，与 [[public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee]]（无服务器计算）共享 Lambda 事件驱动执行模型。 + +**[[public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091]]**（Public Cloud Learning Sessions，AWS 解决方案架构师 Dr. Anil Giri 主讲）：事件驱动架构（EDA）入门与概述——核心学习目标：掌握企业级集成模式（Enterprise Integration Patterns），通过 Amazon EventBridge、SQS 和 SNS 探索事件驱动架构以解决现实世界中的业务挑战。会议原定演示具体 EDA 架构组件，但因 Teams 屏幕共享故障，仅完成开场介绍（⚠️ 完整演示内容参见 [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091]]）。属 Cloud Transformation Programme 的 Serverless & AI 专题，与 [[public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee]]（无服务器计算）共享事件驱动执行模型，共同构成 Serverless & AI 知识链路。 + +**[[ctp-topic-20-program-demand-process-flow-and-poc-onboarding]]**（CTP Topic 20）：云转型计划的程序需求流程与 POC 入职流程——Sergio 和 Damian 主讲。核心内容：①需求来源——主要由业务案例（如数据中心关闭）、高层管理人员战略优先级及产品路线图驱动；②Gate Process——Gate 0 评估准入、Gate 1 负责 Design Authority 审批、Gate 3 作为启动迁移的最终准入；③POC 目的——不仅验证架构和技术可行性，还包括让团队熟悉基于 Gruntwork 的新一代 Landing Zone；④新环境特点——强调 IaC（Terraform/Terragrunt）自动化部署，严禁手动构建；⑤PCG 团队——平台控制组，负责提供云环境支持、安全策略制定及协助产品组进行 POC；⑥成功标准——POC 成功标准必须在启动前明确定义。属 CTP 治理知识体系入口，与 [[ctp-topic-65]]（价值量化）、[[ctp-topic-57]]（需求管理）、[[ctp-topic-30]]（变更管理）共同构成完整的治理框架链条。 + +**[[ctp-topic-47-enterprise-architecture-cloud-standards]]**（CTP Topic 47）：Lindsay 分享企业架构云标准——核心概念：Landing Zone 框架聚焦安全、合规和可管理性，为云工作负载提供托管基础，包含账户结构（dev/stage/prod）、网络、安全、访问管理和遥测；账户结构与环境和角色对齐，通过零信任和最小权限原则定义访问控制；Terraform/Terragrunt 实现 IaC，促进标准化和可测试性；云防护栏文档捕获强制性要求和最佳实践，指导可扩展性、成本最小化和灵活性；功能分区将单体应用拆分为更小的独立模块或无服务器函数。强调需要应用团队的输入来完善防护栏并纳入实践经验。属 [[AWS-Landing-Zone]] 企业架构层的理论补充。 + +**[[ctp-topic-23-introduction-to-the-technical-architecture-team-and-function]]**（CTP Topic 23）：技术架构团队职能与云转型价值——Martin Nash（技术架构经理）主讲。核心内容：①组织变革背景——PSTC 与 IT 部门整合至 CIO 统一领导下，实现两个大型组织的深度融合；②云优先策略——除非数据主权、合规性或极端成本原因必须保留在本地，否则所有新业务优先上云；③三层架构分工——EA（企业架构）对接业务战略，SA（方案架构）负责中间件与服务优化，TA（技术架构）专注底层技术实施与基础设施治理；④技术领域划分——将技术栈划分为身份认证、网络、Microsoft 堆栈等领域，每个领域由首席架构师负责其生命周期与路线图；⑤主动规划转型——通过制定 12-24 个月技术路线图，从被动响应转向预测性规划，帮助业务部门规避风险、优化预算、提升交付速度。属 [[AWS-Landing-Zone]] 架构治理层的核心补充，与 [[ctp-topic-47-enterprise-architecture-cloud-standards]]（EA 云标准）共同构成企业架构知识体系。 + +**[[ctp-topic-72-enterprise-dr-strategy-aws-backup]]**（CTP Topic 72）：AWS 解决方案架构师 Sabith 深入讲解企业级灾难恢复策略与 AWS Backup 架构设计——核心内容：HA（高可用）关注系统运行时间和 MTBF，DR（灾难恢复）专注于防止数据丢失和系统恢复，两者互补；RPO（恢复点目标）定义可接受的最大数据丢失量，RTO（恢复时间目标）定义可接受的最大停机时间；AWS Backup 完全托管、基于策略，通过 Backup Plans 定义何时备份什么，Backup Vaults 存储恢复点，支持跨账户跨区域复制；四级 DR 架构模式（Backup and Restore → Pilot Light → Warm Standby → Active-Active）提供从低成本到高弹性的递进选择；增量备份仅捕获变更，节省成本；Vault Lock 合规模式防止任何人（包括根用户）提前删除恢复点，有效防勒索软件；建议使用独立的 Vault/Bunker Account 存储备份副本，取证账户（Forensic Account）定期测试恢复点并扫描恶意软件。属 [[AWS-Landing-Zone]] DR 与数据保护层的理论基础补充，与 [[ctp-topic-44-aws-backup-in-micro-focus]]（聚焦 Micro Focus 内部评估）和 [[ctp-topic-73-aws-backup-implementation]]（聚焦 CTP 迁移实施）构成完整的 AWS Backup 知识体系。 + +**[[Install WSL]]**（[[install-wsl]]）：微软官方 WSL 完整安装指南——`wsl --install` 一键安装（Windows 10/11 Build 19041+），支持 Ubuntu/Debian/SUSE/Kali 等多发行版并行安装，`wsl.exe --set-default-version` 切换 WSL1/WSL2；离线场景通过 MSI + DISM 命令手动启用 Virtual Machine Platform；运行入口推荐 Windows Terminal（含多标签、自定义快捷键）。[[Install WSL]] 与 [[WSL2 启动与网络配置指南]] 互补——前者解决安装问题，后者解决网络配置问题。 + +**[[WSL2]]** 是 Windows 内置的 Linux 运行环境，WSL2 默认使用 NAT 网络模式导致 Windows 代理无法被 WSL2 内部访问。通过 `.wslconfig` 启用 `networkingMode=mirrored` + `dnsTunneling=true` 可实现 WSL2 与 Windows 共享网络堆栈；国内环境下可使用 `ghproxy.com` 反向代理加速 GitHub 下载。[[WSL2]] 与 [[Ubuntu Server]] 同属 Linux 环境，[[WSL2]] 侧重 Windows 桌面开发场景，[[Ubuntu Server]] 侧重无头服务器场景。 + +### Home Server Automation +Home office setup guides cover a complete multi-node home network infrastructure across 5 nodes: **RackNerd VPS** (public gateway), **Mac Mini M4** (control node), **Synology NAS DS718** (media & storage), and **2 Ubuntu Servers** (monitoring & services). The architecture uses **FRP** (frps/frpc v0.65.0) for reverse tunnel-based intranet penetration, **Caddy** for automatic HTTPS with Let's Encrypt, and **Cloudflare** for DNS托管. **内网穿透方案（VPS + frp + Caddy）**提供完整公网域名访问：Cloudflare DNS A 记录指向 VPS 公网 IP → VPS 运行 frps 和 Caddy → 内网主机运行 frpc 将本地端口映射到 VPS（TCP 隧道）→ Caddy 反向代理到 frp 映射端口，自动申请 Let's Encrypt 证书提供 HTTPS 访问。支持 SSH 穿透（remote_port TCP 映射）不走 Caddy，包含 7 步系统化故障排查（端口监听检查、token 验证、防火墙规则、telnet 诊断等）。 Services deployed include Docker monitoring stack (**Prometheus** + **Grafana** + node_exporter + cAdvisor + blackbox_exporter + Alertmanager), media servers (**Jellyfin**, **Navidrome**, **Transmission**), personal dashboards (**Homarr**, **Apache Superset**), password management (**vaultwarden**), workflow automation (**n8n**), self-hosted Git (**Gitea**), diagram editing (**Draw.io**), developer utilities (**it-tools**), image hosting (**Zipline** + **MinIO**), cloud drive mounting (**CloudDrive2**), AI assistant (**OpenClaw**), e-book management (**Calibre**), proxy client (**v2rayA**), and Docker management (**Portainer**). All services are containerized via Docker Compose. The media workflow follows: Transmission (download) → organize → Jellyfin/Navidrome (play). Key configurations include read-only music mounts, transcode caching (200MB limit), FRP TCP tunnel port mappings (remotePort 60022-60026 for SSH, 13000 for Grafana, 14533 for Navidrome, etc.), Caddy domain mapping table (20+ subdomains under *.ishenwei.online), and SOCKS5 proxy (127.0.0.1:10808) status tracking across all nodes (Mac mini, Ubuntu1, Ubuntu2 working; NAS local-only). **CloudDrive2** enables direct NAS access to cloud storage via virtual filesystem mount (Aliyun Drive resource directory only, scan QR code with App authorization). Backup automation is implemented via rsync incremental sync to NAS, using **Synology DSM NFS** (Squash=admin, sys security, _netdev fstab params) and **nfs-common** client on Ubuntu Server. SSH server setup on Ubuntu 24.04 introduces **ssh.socket activation** (on-demand startup) as the default; administrators can switch to persistent ssh.service mode. Cross-border AI service registration guides cover using **fingerprint browsers** (**AdsPower**), **high-purity US proxies**, **SMS verification platforms** (**PingMe**), and **virtual credit cards** (**WildCard**) to safely subscribe to **Claude Pro**. The architecture provides unified HTTPS public access to all internal services without requiring static IPs, achieving privacy for internal services while maintaining low bandwidth costs. + +Key concepts: [[Docker-Image]], [[Docker-Save]], [[Docker-Load]], [[Docker Compose]], [[Docker Engine]], [[Docker 用户组]], [[APT 仓库配置]], [[GPG 密钥验证]], [[it-tools]], [[RSSHub]], [[内网穿透]], [[反向代理]], [[TCP隧道]], [[Caddy]], [[frp]], [[Symbolic Link]], [[软链接策略]], [[目录映射]], [[Prometheus]], [[PromQL]], [[Prometheus告警规则]], [[Grafana]], [[node_exporter]], [[cAdvisor]], [[blackbox_exporter]], [[Alertmanager]], [[Uptime Kuma]], [[Netdata]], [[VictoriaMetrics]], [[合成监控]], [[Exporter]], [[时序数据库]], [[TUI]], [[Process Management]], [[System Monitoring]], [[容器资源限制]], [[容器重启策略]], [[端口映射]], [[媒体服务器]], [[转码缓存]], [[只读挂载]], [[增量备份]], [[永久挂载]], [[挂载点检查]], [[Cron定时任务]], [[进程管理]], [[Socket 登录]], [[用户权限]], [[固件刷入]], [[过渡固件]], [[JFFS双清]], [[策略组分流]], [[故障转移]], [[订阅机制]], [[PUID/PGID]], [[桥接网络]], [[Socket Activation]], [[UFW 防火墙]], [[开机自启]], [[VPN Panel]], [[Xray]], [[BBR]], [[Web Proxy Protocol]], **[[全盘镜像备份]]**, **[[裸机恢复]]**, **[[NFS网络备份]]**, **[[UEFI启动]]**, [[指纹浏览器]], [[IP纯净度]], [[虚拟信用卡]], [[接码平台]], [[账号隔离]], **[[云盘挂载]]**, **[[NAS套件管理]]**, [[Root权限修复]], [[SPK套件格式]], [[launchd]], [[Gatekeeper]], **[[图床]]**, **[[S3-兼容对象存储]]**, **[[Docker堆栈]]**, **[[逻辑备份]]**, [[systemd]], [[Ubuntu Server]], **[[BI平台]]**, [[数据可视化]], **[[systemd-logind]]**, **[[HandleLidSwitch]]**, [[休眠目标]], [[pmset]], [[caffeinate]], [[Wake-on-LAN]], [[Headless 服务器]], [[系统睡眠管理]] + +**Self-Healing Infrastructure Agent**: 基于 [[OpenClaw]] 的家庭服务器自动驾驶代理（代号 "Reef"）——通过 SSH 访问家庭网络所有机器，配置 Cron Job 系统（15个活跃任务）实现 24/7 全天候自动化：每 15 分钟检查看板、每小时健康监控+邮件分拣、每 6 小时知识库录入+自检、每日 8AM 晨报（天气/日历/系统状态）、每周安全审计。Agent 可自动执行 SSH、Terraform、Ansible、kubectl 命令修复基础设施问题——"在你知道问题前就修复它"。核心安全策略：TruffleHog pre-push hooks + 私有 Gitea CI 扫描_pipeline + 1Password 专用 AI vault + 每日安全审计（防特权容器/硬编码 secrets/过度权限）。知识提取具有复利效应——一位用户从 ChatGPT 历史中提取了 49,079 条原子事实。Key concepts: [[Morning Briefing]], [[Email Triage]], [[Local-first Git]], [[Defense-in-Depth]], [[Self-Healing-Systems]], [[Agentic AI]], [[Infrastructure-as-Code]], [[Gitea]], [[TruffleHog]], [[ArgoCD]], [[Loki]], [[Gatus]], [[K3s]] + +### YouTube Automation +A practical tip for extracting YouTube Channel IDs: use `view-source:` prefix in browser to access channel page source, search for `channel_id` string in the page source to find the RSS Feed URL containing the channel ID. Can be used in [[n8n]] workflows for YouTube subscription monitoring. + +**本地 RSSHub 部署方案**（[[实战笔记-本地部署-rsshub-并获取-youtube-订阅]]）：通过 Docker 一键部署 RSSHub（`diygod/rsshub`，端口 1200），使用 `/youtube/channel/{channel_id}` 路由生成 YouTube 频道 RSS 源。相比第三方在线服务，本地部署更稳定可靠，可完全控制数据流向。本地 RSSHub 同时支撑 [[blogwatcher-daily]] Skill 的 YouTube 频道订阅监控（31个频道中18个通过 RSSHub 代理）。 + +**AI-Powered Daily Digest**: [[daily-youtube-digest]] provides a fully automated pipeline — AI Agent periodically checks subscribed channels for new uploads → extracts video transcripts via [[TranscriptAPI.com]] → generates key-point summaries → delivers a daily digest. Runs on [[OpenClaw]] via the `youtube-full` skill (installable from [[ClawHub]]), using 0-credit free API calls for channel checking and 1 credit per transcript for summarization. Supports two modes: channel-based (e.g., @TED, @Fireship, @LexFridman) and keyword-based (e.g., "Claude Code", "AI agents"). + +**[[YouTube-Content-Pipeline]]**：AI Agent 驱动的 YouTube 选题发现与选题自动化流水线——每小时 Cron Job 扫描 Web + X/Twitter 突发 AI 新闻，向 Telegram 推送选题；同时维护 90 天视频目录（播放量 + 主题分析）避免选题重复，通过 SQLite 向量嵌入实现语义去重；在 Slack 分享链接时自动研究主题、搜索 X、查询知识库并创建带大纲的 Asana 任务卡。与 [[Daily-YouTube-Digest]] 互补：后者侧重订阅频道更新监控，前者侧重全网趋势主动发现。与 [[Content-Factory]] 共享并行子 Agent 执行模式。 + +**[[academic-historian]]**（Historian）：AI Agent 角色设定——扮演具有跨时代研究能力的历史学家，为创意项目提供历史真实性验证、时代背景丰富化和历史迷思纠正。核心能力：历史编年分析、史料批判（原始文献>二手学术>通俗史>好莱坞）、历史因果推理（长期结构性原因 vs 短期触发事件）、物质文化重建（Annales 学派）、长时段分析（longue durée）、微观史、比较史、反事实推理。核心理念：物质条件决定论——在讨论政治/军事前必须先理解经济基础；主动挑战欧洲中心主义——宋朝科技/马里帝国财富同等重要；所有论断必须标注置信度和来源类型。关键方法论：五步工作流（定位时空坐标→核查物质基础→叠加社会结构→评估论断→标注置信度）。典型交付物：Period Authenticity Report（饮食/服饰/建筑/技术/货币/权力结构/性别角色全维度历史细节）、Historical Coherence Check。与 [[academic-geographer]]（空间维度）、[[academic-anthropologist]]（共时性文化系统）、[[academic-narratologist]]（叙事维度）共同构成"人文社科 AI 研究者矩阵"，与 [[academic-psychologist]] 共享心理-历史交叉分析视角。 + +**[[academic-geographer]]**：AI Agent 中的地理学家角色——专注于物理与人文地理的系统性建模，为虚拟世界构建地理连贯性。核心理念："Geography is destiny — where you are determines who you become"。通过严格地理连贯性规则（河流不分叉、气候成系统、地理非装饰）、五步工作流（板块构造→气候→水文→生物群落→人类定居）、交付物模板（地理连贯性报告、气候系统设计）驱动 Agent 行为。关键原则：避免地理决定论（地理约束但不决定）；规模很重要（"小王国"和"大帝国"地理需求完全不同）；地图是论据（制图具有政治性）。理论基础涵盖 Koppen 气候分类、Christaller 中心地理论、Mackinder 心脏地带理论、雨影效应等。与 [[academic-historian]]（历时性时间维度）、[[academic-anthropologist]]（共时性文化系统）、[[academic-narratologist]]（叙事维度）共同构成"人文社科 AI 研究者矩阵"。 + +**[[academic-anthropologist]]**：基于文化人类学理论构建文化自洽社会的 AI Agent 设计框架——将田野调查方法论注入 Agent，使其能设计有社会学意义的亲属制度、交换系统、仪式信仰和权力结构。核心理念：每个文化元素必须有社会功能（社会凝聚/资源管理/身份认同/冲突解决），先问"这个实践解决了什么问题"而非"这个仪式看起来酷不酷"。理论基础：结构人类学（列维-斯特劳斯）、象征人类学（格尔茨"厚描"）、实践理论（布迪厄）、仪式分析（特纳/范热内普）、经济人类学（莫斯/波拉尼）。关键原则：避免文化拼贴（culture salad）、不跳过亲属制度设计、无乌托邦（每个文化都有内部张力）。与 [[academic-historian]]（历时性视角）、[[academic-geographer]]（空间维度）、[[academic-narratologist]]（叙事维度）共同构成"人文社科 AI 研究者矩阵"。 + +**[[academic-narratologist]]**：以叙事理论框架驱动故事结构分析的 AI Agent——将俄罗斯形式主义、法国结构主义、认知叙事学等学术传统注入 Agent，使其能像专业叙事理论家一样分析故事结构、角色弧光、主题表达，并提供有命名框架依据的叙事建议。核心理念："每个故事都是一个论证（Every story is an argument）"；核心原则：大多数叙事问题存在于讲述层面（sjuzhet）而非故事层面（fabula），诊断应优先于处方；每个建议必须引用至少一个命名理论框架（Propp/Campbell/Genette/Barthes/Todorov）。核心框架：Propp 形态学（童话/冒险结构）、Campbell 单一体神话（英雄叙事）、Vogler 编剧旅程（好莱坞改编）、Genette 叙事学（视角/时序/声音）、Barthes 五代码（叙事语义）、Todorov 均衡模型（破坏-恢复结构）。与 [[academic-anthropologist]]（共时性文化系统）、[[academic-historian]]（历时性时间分析）、[[academic-geographer]]（空间维度）共同构成"人文社科 AI 研究者矩阵"。 + +**[[arXiv-Paper-Reader]]**：AI Agent 驱动的 arXiv 论文阅读助手——通过 `arxiv-reader` skill（3 个工具：`arxiv_fetch`、`arxiv_sections`、`arxiv_abstract`）直接从 arXiv 下载 LaTeX 源码并自动扁平化展开，消除 PDF 下载后切换论文丢失上下文和 LaTeX 符号难以解析的痛点；支持摘要浏览、多论文对比排序、选择性细读和会话式分析；本地缓存使重复访问秒级响应；纯 Node.js 零依赖部署。与 [[academic-historian]] 同属学术研究场景互补——前者侧重理工科论文，后者侧重人文社科；与 [[YouTube-Content-Pipeline]] 的 Research Agent 共享研究工作流设计模式。 + +**[[Daily Reddit Digest]]**：AI Agent 驱动的 Reddit 每日精选摘要自动化——通过 [[OpenClaw]] + `reddit-readonly` skill，每日定时抓取指定 Subreddit 的热门/最新/最高赞帖子，AI 记忆用户偏好并持续优化精选规则（如排除表情包类内容）。纯读取模式，无需认证。属 [[Daily YouTube Digest]] 同款模式（定时 + AI 摘要 + 偏好学习）的 Reddit 垂直场景。 + +**Multi-Agent Content Factory**: [[content-factory]] 是基于 Discord 频道的多 Agent 内容工厂，通过 Research Agent → Writing Agent → Thumbnail Agent 链式协作，实现内容创作全流程自动化（研究→写作→设计）。每天定时运行，创作者次日醒来即可收获成品内容。[[OpenClaw]] 提供 sessions_spawn/sessions_send 能力支撑多 Agent 编排。 + +**X/Twitter Automation**: [[x-twitter-automation]] 是基于 [[OpenClaw]] 的 X/Twitter 全功能自动化方案——通过 TweetClaw 插件（`@xquik/tweetclaw`）连接 X/Twitter 托管 API，实现自然语言驱动的发帖、回复、点赞、转发、关注、DM、搜索、数据提取、抽奖选人和账号监控。支持可配置的抽奖筛选条件（最低粉丝数/账号年龄/关键词），账号监控可追踪指定用户的新推文或粉丝变化并推送通知。所有操作通过托管 API 完成，无 Cookie、无爬虫、无凭证暴露。与 [[x-account-analysis]] 互补（分析 vs 操作），可与 [[content-factory]] 配合扩展社交媒体内容发布能力。 + +**[[x-account-analysis]]**：基于 [[OpenClaw]] + [[Bird Skill]] 的 X 账号定性分析方案——通过 Cookie 认证（auth-token / ct0）读取真实账号推文，AI 深入分析内容模式（为何有时 1000+ 赞有时 <5 赞）、话题偏好与互动差异原因。定性分析聚焦"质量"而非"数字"，揭示帖子病毒式传播的规律。免费替代 $10-$50/月 的第三方订阅分析服务。核心安全建议：为 OpenClaw 单独创建 [[ClawdBot]] 专用账号而非直接使用真实账号。与 [[x-twitter-automation]] 互补——前者侧重内容质量分析，后者侧重账号操作自动化。 + +Key concepts: [[Channel ID]], [[RSS Feed]], [[X/Twitter-API-Automation]], [[Social-Media-Giveaway]], [[Account-Monitoring]], [[Daily-Digest]], [[Transcript-Based Summarization]], [[TranscriptAPI.com]], [[Chained Agents]], [[Content Automation]], [[Semantic-Deduplication]], [[Vector-Embedding]], [[Knowledge-Base-RAG]], [[arXiv-API]], [[LaTeX-扁平化]], [[本地缓存]], [[论文摘要批量获取]] + +### n8n Workflow Automation +[[n8n]] 是开源工作流自动化平台，支持 Trigger 节点监听外部事件。n8n 可与 [[Telegram]] 集成，接收机器人消息触发工作流；也可与 YouTube API 集成实现订阅监控。Telegram 集成时需要通过 `WEBHOOK_URL` 环境变量（设为 HTTPS 地址）解决 Telegram 对 Webhook 协议的要求，否则会报 "bad webhook: An HTTPS URL must be provided for webhook" 错误。 + +**入门教程**：[[n8n-full-tutorial-building-ai-agents-in-2025-for-beginners]] 提供了使用 N8N 构建 AI Agent 的完整指南，涵盖五类节点系统（Trigger/Action/Utility/Code/Advanced AI）、Agent 记忆机制、以及与 Airtable 等外部工具的集成方法。教程强调了 Agentic System 的核心概念：Agent 利用 LLM 动态选择工具，结合 Memory 实现上下文保持，使 AI 应用能够根据用户输入自适应响应。 + +**Claude + N8N MCP 自动化工作流**：通过安装 [[n8n-mcp]]（Model Context Protocol 多功能控制面板），Claude 可理解并调用 543 个 N8N 节点，自动生成工作流。使用 OpenSea 模型 + Extended Thinking 模式可提升生成质量，Claude 生成的 N8N 工作流完成度约 80%-90%，仍需人工二次修正，但显著降低了新手的入门门槛。两种接入路径：**Claude Desktop** 端侧方案（适合桌面用户，通过本地 MCP 连接 n8n）与 **Claude API** 云端方案（适合程序化集成），核心均依赖 [[Node.js]] 运行环境。 + +Key concepts: [[Webhook]], [[WEBHOOK_URL]], [[n8n Workflow]], [[n8n-mcp]], [[Extended Thinking]], [[工作流自动化]], [[Claude Desktop]], [[Node.js]], [[Webhook-Proxy-Pattern]], [[Credential-Isolation]], [[Lockable-Workflow]], [[Visual-Debugging]], [[Safeguard-Steps]], [[Audit-Trail]] + +**OpenClaw + n8n Webhook 代理模式**：[[n8n-workflow-orchestration]] 描述了一种将 OpenClaw Agent 外部 API 交互委托给 n8n 的安全架构——OpenClaw 通过 Webhook 调用 n8n 工作流，n8n 持有凭证并执行 API 调用，Agent 完全不知道密钥。核心机制：构建 → 测试 → 锁定循环，确保工作流行为不被 Agent 静默修改。[[openclaw-n8n-stack]] Docker Compose 堆栈提供一键部署，[[Simon-Hoiberg]] 是该模式的提出者。与 n8n-mcp 的互补关系：Claude + n8n-mcp 解决工作流生成问题，本模式解决 Agent 安全集成问题。 + +### Linux System Monitoring +Six Linux resource monitoring tools reviewed: TUI tools (Btop++, Htop, Glances, Bottom) for SSH-friendly server management; GUI tools (Mission Center, Stacer) for desktop use. Author's top pick: Btop++ for its balance of usability and aesthetics. [[Btop++]], [[Htop]], [[Glances]], [[Bottom]], [[Mission Center]], [[Stacer]], [[TUI]], [[TOTP]], [[Passkey]], [[Self-Hosted Password Manager]] + +### Linux Operations Command Reference +A comprehensive Linux command reference covering 150 essential commands across 16 categories: help commands (man, help), file operations (ls, cd, cp, find, mkdir, mv, rm, touch, tree), text processing (cat, grep, sort, uniq, wc, diff, vim), compression (tar, gzip, zip, unzip), system info (uname, dmesg, uptime, du, df, top, free), search (which, locate), user management (useradd, sudo, visudo), networking (ssh, scp, wget, ping, ifconfig, netstat, ss, nmap, tcpdump), disk/filesystem (mount, fdisk, mkfs, mkswap, sync), permissions (chmod, chown, chgrp, umask), process management (kill, crontab, ps, nohup), and system shutdown/restart (shutdown, halt, poweroff). Key insight: Linux treats everything as a file (CPU, memory, disks, keyboard, users). **CPU architecture detection**: `uname -m` (x86_64/aarch64/armv7l), `lscpu` (Architecture field), `cat /proc/cpuinfo` (model name/AArch64), `file /bin/bash` (ELF metadata). + +Key concepts: [[CPU架构检测]], [[x86_64]], [[aarch64]], [[ARM64]], [[ELF格式]] + +### Educational Resources +**[[Build Your Own X]]**：GitHub 上由 [[CodeCrafters]] 维护的精选教程列表（build-your-own-x），收录 26+ 技术领域的分步骤指南，涵盖 3D Renderer、Web Browser、Database、Docker、Git、Operating System、Programming Language、Neural Network 等领域。每条教程引用 Richard Feynman 的名言："What I cannot create, I do not understand"作为核心理念——通过从零重建主流技术实现深度技术理解。与 [[ChinaTextbook]]（教材资源）互补，前者侧重工程实践（重建系统），后者侧重学科理论（课程教材）。 + +ChinaTextbook（TapXWorld/ChinaTextbook）是一个托管于 GitHub 的开源项目，收集中国小学、初中、高中、大学全阶段 PDF 教材，总库大小 41.53GB。教材来源于国家中小学智慧教育平台（basic.smartedu.cn），可通过第三方工具（tchMaterial-parser）下载。覆盖小学 10 门学科（语文、数学、英语、科学，音乐、美术、体育与健康、道德与法治等）、初中 17 门学科、高中 18 门学科，以及大学阶段概率论、离散数学、线性代数、高等数学等基础课程。 + +**免费 AI 学习资源全景**（[[learn-ai-for-free-directly-from-top-companies]]）：@RodmanAi 汇总的 10 家顶级科技公司免费 AI 学习资源——Anthropic（Skilljar 培训平台）、Google（Grow.google/AI 学习路径）、Meta（AI 资源中心）、NVIDIA（CUDA 开发者课程）、Microsoft（Microsoft Learn）、OpenAI（Academy）、IBM（SkillsBuild）、AWS（Skill Builder）、DeepLearning.AI（吴恩达课程）、Hugging Face（学习路径）。核心价值：**免费获取权威 AI 培训内容**，无需付费订阅。与 [[Claude Prompt Library]]（Anthropic 官方提示词库）属同一教育生态。 + +Key concepts: [[国家中小学智慧教育平台]], [[tchMaterial-parser]], [[ChinaTextbook]], [[Build-Your-Own-X]], [[BYOX]], [[Learn-By-Building]], [[From-Scratch-Methodology]], [[CodeCrafters]], [[NAND-to-Tetris]], [[AI教育]], [[免费学习资源]] + +### AI Tools & Prompt Engineering +Covers Claude Code, Claude Code Templates (npx 一键安装 Skills/Agents/MCP via `npx claude-code-templates@latest --skill= --yes` from aitmpl.com), OpenCode, [[Cursor]], [[Trae]], Gemini CLI, Vibe Coding, [[RAG]], multi-agent workflows, NotebookLM, Nano Banana prompting, and video generation tools. + +**Claude Skills 范式**（[[3-2-万人收藏的-claude-skills-才是-ai-这条路上最值得研究的一套范式-1]]）：Anthropic 官方 Skills 仓库（github.com/anthropics/skills，3.2 万收藏）将 Claude.ai 网页版的生产级能力原封不动拆解展示，包含办公自动化（Word/PDF/PPT/Excel）、开发者工具箱（MCP Server/自动化测试/Artifacts 构建）和创意类 Skill。核心洞察：**Skills = 说明书 + SOP**，将反复执行的有固定流程的任务拆解为 AI 能理解、能复用、能自动执行的一套流程。Claude Skills 的爆发标志着从「提示词工程」向「流程工程」的范式转变——最有价值的不是 Prompt 写得最花，而是能把业务流程沉淀成 SOP 并交给 AI 稳定执行。Vibe Coding 的尽头也是 Skills。三大 Skill 聚合站（skillsmp.com、aitmpl.com/skills、claudemarketplaces.com）可"拿来主义"直接使用；3 款高产开源 Awesome-Claude-Skills 仓库（ComposioHQ/VoltAgent/BehiSecc）提供系统性灵感。 + +**Vibe Coding 中文指南**（[[github-上-5000-人收藏的-vibe-coding-神级指南]]）：介绍 vibe-coding-cn 开源项目（github.com/tukuai/vibe-coding-cn），为中文开发者汇集全球顶尖 AI 编程资源。核心公式：**Vibe Coding = 规划驱动 + 上下文固定 + AI 结对执行**，让「从想法到可维护代码」变成可审计的流水线，而非一团无法迭代的巨石文件。工具推荐：Cursor + Claude Opus（高 context window 保证上下文一致性）。包含方法论、提示词优化技巧（需求澄清/系统架构设计/分步执行/自测全链路脚本）和完整开发流程教程。核心理念：**规划就是一切**——让 AI 写代码前必须先完成技术选型、实施规划和模块化设计，防止 AI 因理解偏差导致项目逻辑混乱。[[系统提示词构建原则]] 提供了该框架的详细行为准则——从身份定义（遵守项目约定、优先技术准确性）到具体执行规范（TODO 规划、Search/Replace 编辑、精确搜索策略），构成 Vibe Coding 的操作层指南。 + +**Gemini 3 十应用实战**（[[我用-gemini-3-一口气做了-10-个应用-附教程]]）：使用 Google [[Gemini-3]] 模型通过对话式提示词构建 10 个实用可视化应用（冷知识卡片/配色卡片/电影海报/绘画思维导图等）。核心方法论：①限定垂直场景（诗词/小说/电影）→ ②用提示词约束结构化输出（JSON/SVG）→ ③用前端 SVG/HTML 作为输出容器。三步核心机制：**AI 生成 SVG 代码 → 前端渲染为精美卡片/海报/导图**。该方法论与 [[Vibe-Coding]] 的"对话驱动 + AI 结对"理念高度契合——通过限制输入场景降低 AI 理解成本，通过提示词约束结构化输出，通过前端代码作为最终容器，是 Vibe Coding 在 AI 可视化产品方向的具体实践。 + +**[[fireworks-tech-graph]]**：Claude Code Skill，将自然语言描述转化为精美 SVG 技术图并导出 PNG——解决技术文档/博客缺乏高质量可视化图表、手动绘图耗时且风格不统一的核心痛点。内置 **7 种视觉风格**（扁平图标风/暗黑极客风/工程蓝图风/Notion极简风/玻璃态卡片风/Claude官方风格/OpenAI官方风格）和 **14 种 UML 图类型**，深度覆盖 AI/Agent 领域常见 Pattern（RAG、Agentic Search、Mem0、Multi-Agent、Tool Call 流程等）。语义形状词汇表确保图形语义一致（LLM=双边框圆角矩形、Agent=六边形、Vector Store=带内环圆柱），语义箭头系统通过颜色+虚线编码含义（主数据流/控制触发/记忆读取/写入/异步/反馈循环）。通过 `rsvg-convert` 导出 1920px PNG，可直接嵌入文章发布。安装：`npx skills add yizhiyanhua-ai/fireworks-tech-graph`，依赖 `librsvg`（macOS: `brew install librsvg`，Ubuntu: `sudo apt install librsvg2-bin`）。核心价值：**AI Agent 可快速生成专业级技术图，无需手动绘制**，支持 SVG 可编辑 + PNG 无损发布。 + +**Claude Prompt Library**（[[useful-prompt-lib]]）：Anthropic 官方提示词库，收录 64+ 款专业化提示词，覆盖开发工具（Python Bug Buster、Code Consultant、Git Gud）、效率工具（Data Organizer、Review Classifier、CSV Converter）、创意工具（Storytelling Sidekick、Culinary Creator）、营销工具（Babel's Broadcasts 多语言推文、Polyglot Superpowers 互译）、教育工具（Meeting Scribe、Lesson Planner、Socratic Sage）等 10+ 领域。TikTok 跨境电商推荐三剑客：Babel's Broadcasts（10 种语言产品发布）、Review Classifier（评论自动化分类）、Data Organizer（非结构化文本→JSON，对接 n8n 工作流）。 + +**LLM / RAG / AI Agent 三层架构**：基于 [[llms-rag-ai-agent-三个到底什么区别]] 的系统梳理，AI 应用的三层架构： +- **[[Large Language Model]]**：思考层（天才大脑），负责推理生成，但知识有截止日期 +- **[[RAG]]**：认知层（记忆系统），将 LLM 链接外部知识库，消除幻觉、提供可追溯来源 +- **[[AI Agent]]**：执行层（行动系统），感知→规划→执行→反思的循环控制，实现真正自主性 + +**[[RAG从入门到精通系列1-基础rag]]**：RAG 系列教程第一篇，系统讲解基础 RAG 的 Indexing（文档加载→切分→向量化入库）→ Retrieval（向量相似度检索 Top-k 文档块）→ Generation（问题+上下文→LLM 生成带事实依据的答案）三阶段流程。实战工具链：Qwen（LLM）+ BAAI（BGE Embedding）+ LangChain（应用编排）+ Qdrant（向量数据库）。配套 Jupyter Notebook 演示完整 Pipeline，LangSmith 可视化调试。是 [[rag从入门到精通系列1-基础rag]] 系列的基础入门篇。 + +入门术语参考：[[大模型相关术语和框架总结]] 提供 LLM、Prompt、MCP、Agent、RAG、Embedding、vLLM、Token、数据蒸馏等核心概念的通俗解释，可作为三层架构体系的术语速查手册。与 [[llms-rag-ai-agent-三个到底什么区别]]（系统梳理）属互补关系——前者入门科普，后者架构深化。 + +核心洞察：未来不在于选择其一，而在于将三者结合架构设计。 + +**ChatGPT 个性化配置**：基于 [[openai-chatgpt-个性化定义]] 的用户完整配置案例，展示如何通过 ChatGPT 自定义指令将通用 AI 塑造成专属协作者。核心配置原则包括：[[Expert User Assumption]]（将用户视为所有领域专家，无需简化技术细节）、[[Proactive AI]]（主动预判需求而非被动等待）、[[Error Accountability]]（错误零容忍且主动反馈配置导致的回复质量下降）。[[Custom Instructions]] 通过两条配置（自定义指令 + 用户详情）永久定义 AI 行为，无需每次对话重复说明。[[Personalization]] 的关键是系统性配置——错误政策、引用格式、推测告知、内容政策冲突处理——而非零散提示词。 + +**[[AI图生视频工具盘点]]**：基于 [[14个免费的AI图生视频工具-用ai让图片动起来]] 的综合分析，介绍了14个免费AI图生视频工具，覆盖阿里巴巴（绘蛙、通义万相、万相营造）、字节跳动（即梦AI）、快手（可灵AI）、智谱AI（智谱清影）、MiniMax（海螺AI）、生数科技（Vidu）、爱诗科技（PixVerse）、潞晨科技（Video Ocean）、智象未来（Viva）、MewXAI（艺映AI）、Stability AI（Stable Video）等厂商。核心能力包括：文本提示词控制运动、动作模板选择、运镜参数调节、首尾帧精准控制、主体一致性保持、音效自动生成等。电商场景（模特图动态化、商品展示）、视频创作（创意短片）、广告制作是三大主要应用方向。与 [[文字生成视频网站推荐]] 属同类AI视频生成工具的不同角度——前者侧重点图生视频，后者侧重文生视频。 + +**[[电商视频Prompt库]]**：基于 [[电商视频prompt]] 的 AI 生成宠物电商视频模块化 Prompt 库——7 大模块（产品展示/宠物动作/衣服防穿帮/场景变化/Negative Prompt/卖货文案/全流程示例），以"拼积木"方式组合使用，实现**低翻车率 + 高真实感**的 TikTok Shop 带货视频生成。核心原则：宠物衣服必加防穿帮模块，场景变化作为加法叠加而非写死；可扩展至 1 产品 → 3 条视频 → 6 条文案 → A/B 测试全链路自动化。与 [[AI图生视频工具盘点]]（工具盘点）和 [[做TK跨境思路不对努力白费]]（运营策略）共同构成 TikTok 跨境电商内容生产的完整知识链条。 + +**[[固定镜头短视频制作的AI全流程解析]]**：基于固定机位 + 内容连续变化 + 时间压缩三大原理的家装短视频 AI 制作方法论——分镜拆解（Google AI Studio）→ 九宫格图像生成（Midjourney/Nano Banana）→ 首尾针动画（海螺AI/KAI）→ 快节奏剪辑（剪映）→ 声音设计，10 分钟内完成成片。核心突破：九宫格一次性生成保证画面一致性，首尾针动画替代复杂转场，硬切反而更干净。适用于所有固定机位且状态变化明显的短视频类型。与 [[AI图生视频工具盘点]] 同属 AI 视频创作工具应用，后者侧重工具评测，前者侧重完整工作流程。 + +**NotebookLM 开源平替生态**：基于 [[google-神级生产力工具-所有-github-开源平替都找到了]] 的系统梳理，Google [[NotebookLM]] 作为 AI 笔记助手标杆，支持文档问答和播客生成两大核心能力，GitHub 上已形成完整的开源替代生态：[[OpenNotebook]]（14.6k Stars，全功能本地化，支持 16+ AI 提供商和本地模型）是 Star 最高的平替；[[SurfSense]]（11.4k Stars）定位为 NotebookLM + Perplexity + Glean 的综合替代，支持语义+全文混合搜索和团队 RBAC；[[Podcastfy]] 专注播客生成，整合 100+ LLM 和多种 TTS 引擎；[[NotebookLlama]]（LlamaIndex 官方项目）展示文档转播客的完整技术链条；[[PageLM]] 聚焦教育场景，提供康奈尔笔记和间隔重复闪卡；[[InsightsLM]] 采用 Supabase + N8N 低代码架构，支持完全离线部署。该生态覆盖从"全功能替代"到"垂直聚焦"的不同需求层次。与 [[Personal Knowledge Base (RAG)]]（文档检索知识库）同属 AI 驱动的知识管理工具，但 NotebookLM 生态侧重"文档→对话/音频"的交互形态。 + +**[[7-ways-i-use-notebooklm-to-make-my-life-easier]]**：NotebookLM 7种日常生活场景实测——①处理信息积压（将未读 PDF/文章/视频上传，AI 自动消化，用户通过问答提取要点）；②播客笔记（Audio Overviews 将文档转为双 AI 主持的对话播客，适合驾驶/健身等被动学习场景）；③快速成为多主题专家（将 Batman/Star Wars 宇宙资料或 Jupiter/Marine Corps 等专业领域文档上传，通过播客辩论式学习）；④编程辅助（上传官方文档，上下文学习，提供引用回溯）；⑤项目管理中枢（将零散研究、想法、会议记录整合为结构化路线图，作者用此法一年做出 6 个 App）；⑥版本对比（对比 App 更新、新闻稿、长文档差异，列出具体变化并附带引用）；⑦法律文档审核（租约/合同分析，每个答案附引用，可一键回溯原文核实）。核心机制：[[Source-Grounding]]——知识库严格限定于可信文档，确保答案有据可查。Premium 版提供更完整的功能。与 [[Second Brain]]（对话记忆捕获）同属个人知识管理，NotebookLM 侧重文档驱动的问答与音频交互。 + +**AI 开源平替生态**：基于 [[2025-年-11-个神级-ai-开源平替-github-杀疯了]] 的系统盘点，GitHub 上各 AI 领域已形成完整的开源平替生态——大语言模型（[[DeepSeek]] R1/V3、Qwen 3）、AI 生图（[[Flux]]、Stable Diffusion）、AI 生视频（[[HunyuanVideo]] 混元视频）、AI 智能体（[[OpenManus]] 对标 [[Manus]]）、AI 编码（[[Cline]] 对标 [[Cursor]]）、工作流自动化（[[n8n]] 16万 Star、[[Dify]]）、AI 搜索（[[Perplexica]] 对标 Perplexity）。核心洞察：国产开源模型在多个领域已达到或超越国际闭源竞品水平，[[DeepSeek]] R1 是开源界首个将 o1 级深度推理拉下神坛的破壁者，[[Manus]] 则定义了 AI Agent 元年并被 Meta 收购。 + +**[[custom-morning-brief]]**：基于 [[OpenClaw]] 的晨间简报自动化——每天定时（例 8AM）通过 Telegram/Discord/iMessage 推送结构化报告，内容涵盖：新闻研究（AI/创业/科技方向）、当日待办事项（集成 Todoist/Apple Reminders/Asana）、主动任务推荐（AI 自主思考可帮助完成的事项）、睡前完成的完整草稿（脚本/邮件/商业方案，而非仅标题）。核心洞察：**主动任务推荐**是整个系统最有价值的部分——AI 主动思考如何帮助用户，而非被动等待指令；完整草稿（full draft）比标题建议节省大量时间；用户只需发消息即可调整简报内容，无门槛个性化。与 [[self-healing-home-server]] 的 Morning Briefing 属同一模式的不同垂直场景。 + +**[[family-calendar-household-assistant]]**：基于 [[OpenClaw]] 的家庭日程协调与物资管理方案——聚合 5+ 个分散日历（工作/个人/家庭/学校/课外）生成每日晨间简报；通过环境消息监控（Ambient Message Monitoring）自动从 iMessage 中识别预约并创建日历事件（含行车时间缓冲）；维护家庭库存 JSON（冰箱/储藏室），支持照片 OCR 和小票识别更新；生成购物清单。核心洞察：**Ambient > Active**——Agent 在不被要求时主动行动才是最大突破；Mac Mini 是该场景的最优硬件（iMessage 集成 + 始终在线）。与 [[Custom Morning Brief]] 属同一晨间简报模式的不同场景（个人 vs 家庭）。 + +**Todoist Task Manager**：基于 [[OpenClaw]] 的 AI 驱动任务管理自动化——Agent 解析自然语言指令（"这周完成 Q1 报告"）→ 调用 Todoist REST API 创建结构化任务（含截止/项目/标签）→ Cron Job 定时扫描逾期任务主动推送提醒。与 [[multi-channel-assistant]] 中 Todoist 集成属同一技术栈，Todoist Task Manager 侧重任务管理的深度自动化（Cron 追踪/会议→任务闭环），multi-channel-assistant 侧重多渠道入口的统一体验。 + +**Health & Symptom Tracker**：基于 [[OpenClaw]] 的食物敏感性自动追踪方案——通过 Telegram 话题记录食物和症状，Cron Job 每日三餐定时提醒（8AM/1PM/7PM），OpenClaw 自动解析消息并带时间戳写入 Markdown 日志，每周分析关联模式识别潜在触发因素。无需专用 App，完全自托管。 + +**Habit Tracker & Accountability Coach**：基于 [[OpenClaw]] 的 AI 主动问责习惯追踪方案——通过 Telegram/SMS 每日定时签到，替代被动习惯追踪 App。与 [[Health & Symptom Tracker]] 属同一框架（OpenClaw + Telegram + Cron Job + 每周模式分析），但垂直于个人习惯养成而非健康追踪。核心洞察：**主动问责**（AI 直接询问）比被动记录更能驱动行为改变；保持 3-5 个习惯可避免签到疲劳；[[Adaptive Tone]] 自适应语气是关键差异化因素。 + +**AI-Powered Earnings Tracker**：基于 [[OpenClaw]] 的财报季自动化追踪方案——每周日 6PM 扫描财报日历并过滤用户关注公司（NVDA/MSFT/GOOGL/META/AMZN/TSLA/AMD），Telegram 投递预览列表；用户确认后为每家公司调度一次性 Cron Job，财报发布后自动搜索、格式化摘要（beat/miss、营收、EPS、AI 亮点、指引）并投递。与 [[Daily YouTube Digest]] 同属 Cron Job + AI 摘要 + Telegram 投递模式的不同实例。 + +**Event Guest Confirmation**：基于 [[OpenClaw]] + [[SuperCall]] 的活动嘉宾自动确认方案——通过 AI 语音电话批量外呼客人，确认出席状态并收集备注（饮食禁忌、Plus-One、到达时间等），通话完成后生成出席确认/未出席/未接听三分类摘要。核心价值：真人电话比短信/文字消息回复率更高；SuperCall 的沙盒 persona 设计确保 AI 只拥有预设上下文，无法访问用户 Agent 或数据，无 Prompt Injection 风险；每通电话独立重置，无对话间信息混淆。与 [[phone-based-personal-assistant]] 同属 AI 电话外呼场景，但 [[SuperCall]] 的独立沙盒设计更适用于确认类单一任务。 + +**[[personal-crm]]**：基于 [[OpenClaw]] 的个人 CRM 自动联系人发现系统——每日 Cron Job 扫描 Gmail 和日历，自动提取新联系人并更新 SQLite 数据库（姓名、邮箱、首次出现时间、最后联系时间、互动次数、备注）；通过 Telegram personal-crm topic 提供自然语言查询接口（"Who needs follow-up?"、"When did I last talk to [person]?"）；每日 7AM 会议前简报自动研究外部参会者并推送背景资料（含上次交流内容和待跟进事项）。核心价值：**零手动录入，AI 自动维护联系人关系记忆**，让每次会议都有准备。需 [[gog CLI]] 提供邮件和日历数据。与 [[local-crm-framework]]（DenchClaw）和 [[Second Brain]] 同属 OpenClaw 持久化记忆能力的不同应用场景——personal-crm 侧重结构化联系人和会议准备。 + +**Local CRM Framework**：基于 [[OpenClaw]] 的本地 CRM 框架 [[DenchClaw]]——通过 `npx denchclaw` 一键安装完整技术栈（DuckDB + Web UI + OpenClaw Profile + 浏览器自动化），所有设置/视图以 YAML/Markdown 文件存储，Agent 可直接修改 UI 而无需 API 抽象层。核心创新：Chrome Profile 克隆使 Agent 继承用户认证状态，可直接导入 HubSpot 等平台数据。[[Second Brain]] 和 [[personal-crm]] 均属同类 OpenClaw 持久化记忆能力的不同应用场景。 + +**Goal-Driven Autonomous Tasks**：[[overnight-mini-app-builder]] 是基于 [[OpenClaw]] 的目标驱动型自主任务方案——每天清晨 8:00 自动生成 4-5 个贴近目标的自主任务（研究/写作/竞品分析/MVP 构建），通过 Next.js Kanban 看板实时追踪，进度透明可见。核心洞察：**将"规划"和"执行"都外包给 AI Agent，用户只需定义目的地，Agent 自动分解并执行每日步骤**。该方案还包含过夜惊喜 Mini-App 构建模式——指示 Agent 构建 MVP，每天醒来即收获一个新产品原型。与 [[market-research-product-factory]] 同属 Alex Finn 启发的 OpenClaw 高阶用法，但前者侧重任务追踪和持续执行，后者侧重产品机会发现。与 [[Project State Management]] 的看板 vs 事件溯源存在潜在冲突。核心工程实践：**Git-style append-only 日志模式**（主会话管 AUTONOMOUS.md 状态，子代理只追加 tasks-log.md）解决多 Agent 竞态条件；[[Token-Light Design]] 保持 AUTONOMOUS.md 在 50 行以内避免心跳轮询 token 浪费。 + +**Pre-Build Idea Validator**：基于 [[OpenClaw]] + [[idea-reality-mcp]] 的 AI 项目启动前竞争分析门控——在写代码之前自动扫描 GitHub/Hacker News/npm/PyPI/Product Hunt 五个数据源，返回 `reality_signal` 分数（0-100）评估赛道拥挤度：高分数（>70）触发 STOP（展示竞品+询问是否继续/转向），低分数（<30）直接构建。核心价值：**在投入时间前发现已解决的同类问题**，是单兵创业者最重要的决策门控。与 [[market-research-product-factory]] 互补：后者挖痛点找方向，前者在动手前验证赛道的竞争密度。 + +**Never Write Another Prompt**：基于 YouTube 视频的工具介绍，展示一款将简单描述自动转化为详细结构化提示词的 AI 工具——用户无需具备提示词工程专业知识，只需输入简单描述即可获得专业级提示词，支持变量插入和自定义编辑。与 [[Claude Prompt Library 汇总表]]（现成提示词库）和 [[Nano Banana 提示词框架]]（结构化模板）同属提示词工程的不同路径——本工具侧重自动化生成，后者侧重模板规范。市场上单个专业提示词售价 $100-$500，本工具大幅降低了使用门槛。 + +**[[清华出的DeepSeek使用手册]]**：清华大学发布的《DeepSeek从入门到精通2025》官方使用指南（104页），由新闻与传播学院元宇宙文化实验室余梦珑博士后及团队撰写。与其他泛化教程不同，该手册强调"授人以渔"——不仅教用户"怎么问"，更教"为什么这么问"，帮助用户掌握提示词底层逻辑。涵盖 DeepSeek-R1 模型选择、提示语设计技巧、避免 AI 幻觉策略等核心内容。与 [[llms-rag-ai-agent-三个到底什么区别]] 同属 AI 工具方法论，但该手册聚焦 DeepSeek 特定实践。来源：[[清华出的DeepSeek使用手册，104页，真的是太厉害了！（免费领取）]] + +**[[如何写出完美的Prompt-提示词]]**：系统阐述 Prompt 构建底层逻辑的职场应用指南——核心理念：Prompt 是一套人与 AI 的协作协议，本质是将模糊需求转化为 AI 可执行的结构化任务。四大构建要素（角色+需求+场景+目标）+ 三层技巧体系（基础：需求拆解/上下文补全/格式定义/示例引导；进阶：思维链/任务拆分/角色赋能/预填回复/不确定性管理；高阶：跨模态联动/领域知识注入/反馈循环嵌入）+ 四大业务场景实战模板（内容创作/数据分析/方案策划/客户服务）+ 六大避坑指南。核心洞察：Prompt 能力的本质是有对问题清晰界定的能力 + 结构化的思维逻辑和表达能力，这决定了人能否用好 AI。与 [[清华出的DeepSeek使用手册]]（DeepSeek 特定实践）和 [[系统提示词构建原则]]（Agent 系统级指令）互补，构成完整的提示词工程方法论体系。 + +**[[Nano Banana 提示词框架]]**：Nano Banana 基础框架文档，提供两套结构化 JSON Schema 模板——物件描述框架（item / materials / details / condition）和人物描述框架（age / appearance / pose）——共用法学 shot / environment / lighting / camera / color_grade / style / quality / negatives 参数字段。将艺术总监级别的专业摄影描述语言转化为可结构化填写的模板，降低 AI 图像生成的专业门槛。与 [[Nano Banana Pro 提示词指南]]（进阶版）和 [[全网最全-nano-banana-2-使用指南-2025年12月更新-1]]（综合版）同属 Nano Banana 提示词体系。 + +**[[Nano Banana 2 国内使用指南]]**：基于 [[全网最全-nano-banana-2-使用指南-2025年12月更新-1]]，Nano Banana 2（Gemini 3 Pro Image）是 Google 发布的推理型图像生成模型——在生成图像前会进行内部推理，自动补完提示词的深层次需求，支持 1K/2K/4K 分辨率输出，最多可将 14 张输入图像组合为 1 张输出，擅长中文界面渲染、科研配图、技术路线图、教学插画等高准确性要求的图像创作。国内用户可通过 [[DeepSider]] 浏览器插件（deepsider.ai，Edge 扩展）直接访问，无需特殊网络和海外账户，插件同时支持 GPT5/GPT4.1/Claude/Gemini 2.5 Pro/Grok/Sora 2 等数十款 AI 模型。与 [[Nano Banana Pro 提示词指南]]（进阶专业提示）和 [[Nano Banana 提示词框架]]（结构化模板）同属 Nano Banana 提示词体系。 + +**[[Nano Banana Pro 提示词指南]]**：谷歌发布的 Nano Banana Pro 官方提示词指南（《The Complete Guide to Nano Banana Pro: 10 Tips for Professional Asset Production》，含上下两篇），凌晨无预警发布，核心主题是"将 AI 从趣味性图像生成升级为功能性专业资产生产"。核心理念：**停止标签堆砌，像创意总监一样思考**。核心突破：意图理解引擎实现物理规则推演、构图美学理解和语义上下文推理（而非传统关键词匹配）。关键能力：支持 14 张参考图像（6 张高保真）实现"身份锁定"；默认生成思考图像（不收费）后再输出最终结果；支持 1K-4K 原生高分辨率；[[Google Search]] 信息锚定减少实时内容幻觉。10 大黄金法则包括：编辑而非重新生成、使用自然语言完整句子、具体且具描述性、提供上下文（"为什么"或"为谁"）。上篇（[[nano-banana-pro-prompting-guide-strategies-1]]）覆盖前 9 个能力域（文本渲染/信息图、角色一致性/病毒缩略图、Google 搜索信息锚定、高级编辑/修复/着色、2D/3D 维度转换、高分辨率/纹理、思考推理、故事板/概念艺术、结构控制/布局引导），附大量可直接复制的实战提示词模板。与 [[清华出的DeepSeek使用手册]] 同属 AI 工具方法论指南——前者聚焦 DeepSeek 文本推理，后者聚焦 Nano Banana Pro 图像生成；与 [[nano-banana-提示词框架]]（Nano Banana 基础框架）和 [[全网最全-nano-banana-2-使用指南-2025年12月更新-1]]（Nano Banana 2 综合指南）同属 Nano Banana 提示词体系的不同层次。 + +**[[Ollama 本地 LLM 部署]]**：基于 [[详细-离线部署大模型-ollama-deepseek-open-webui安装使用方法及常见问题解决-1]] 的完整实操指南，展示如何使用 Ollama + DeepSeek-R1 + Open WebUI 在本地离线部署大模型。核心价值：**免费、无需 API Key、数据完全私有**。Ollama 跨平台支持（macOS/Windows/Linux/Docker），通过 `ollama run deepseek-r1:8b` 一键运行；国内网络环境下可通过魔塔社区（modelscope.cn）或 HuggingFace Mirror（hf-mirror.com）加速下载；云服务器部署必须通过 nginx + Bearer Token 保护 API 防止恶意调用；Open WebUI 提供浏览器端 Web 界面，支持 RAG 本地知识库（bge-m3 嵌入模型）和联网搜索。硬件要求：1.5B 模型需 4GB RAM，7B 需 16GB RAM，32B 需 64GB RAM+48GB 显存（Apple M2 Max 可流畅运行 32b 及以下）。 + +**[[Qwen2.5-Coder]] 部署实战**（[[在-ubuntu-安装-ollama-并运行-qwen2-5‑coder-7b]]）：Ubuntu 上通过 Ollama 本地部署 Qwen2.5-Coder 7B 代码生成模型，3条命令完成安装（`curl -fsSL https://ollama.com/install.sh | sh && ollama pull qwen2.5-coder:7b && ollama run qwen2.5-coder:7b`）。推荐配置：8+ CPU cores + 16GB RAM + NVIDIA GPU（CUDA 自动加速）。**qwen2.5-coder:7b 因 Tool usage 能力强、Shell/Python/SQL 理解强、Repo 级代码理解强，比普通 qwen2.5:7b 更适合工程任务**。支持 REST API（默认 localhost:11434）和 Python/Node.js SDK，可与 [[Open WebUI]]、[[n8n]]、[[OpenClaw]] 等工具集成构建本地 AI 应用栈。与 [[Ollama 本地 LLM 部署]]（DeepSeek-R1）同属 Ollama 本地部署场景，本方案侧重 Qwen2.5-Coder 的代码生成能力优势。 + +**Claude Code 调用方法**：[[claude-code调用方法总结]] 详细记录了 Hermes Agent 通过 `terminal` 工具调用 Claude Code 的两种模式——Print Mode（`claude -p`，适合绝大多数任务）和 TMUX 交互模式（适合超长任务）。核心参数包括 `--permission-mode bypassPermissions`（跳过所有权限确认）和 `--add-dir`（加载 SKILL.md）。关键结论：当任务需要 Claude Code 的 Skill 时，应使用 `terminal` 调用 `claude -p` 而非 `delegate_task`。 + +**Mac 必装软件清单**（[[mac必装软件清单-2026-04-17]]）：精选 8 款 Mac 必备软件——Claude（AI 助手）、Obsidian（AI 知识库）、Chrome（浏览器）、Rectangle（分屏工具）、iShot（截图录屏）、Lemon（系统清理）、Raycast（启动器）、Homebrew（包管理器）。核心理念：**用最少的软件达到最高的效率**。[[Homebrew]] 是用 Claude Code 搭 Agent 的前置依赖，[[Obsidian]] 搭配 [[Claudian]] 可打造 AI 驱动的终极个人知识库。与 [[Second Brain]] 和 [[Personal Knowledge Base (RAG)]] 同属知识管理场景。 + +**baoyu-imagine AI Logo 生成**：[[我做了个-skill-让-ai-帮你生成-logo-和图标]] 介绍了一个 Claude Code Skill `baoyu-imagine`（`npx baoyu-imagine` 安装），通过 Logo 专用提示词策略驱动 AI 生图工具生成专业 Logo 和图标。核心价值：让非设计师快速产出扁平化/几何/手绘/渐变等多种风格的专业品牌视觉资产，支持 SVG（矢量缩放）和 PNG 格式导出。与 [[Nano Banana]] 提示词体系（侧重摄影/插画/科研配图）同属 AI 图像生成工具链，baoyu-imagine 专注于 Logo/图标这一垂直场景。 + +**Coze 平台多行业 AI Agent 培训**（[[ai-解决方案专家培训课程]]）：Coze（扣子）平台的实战培训课程，分国内版（coze.cn）和海外版（coze.com），提供覆盖金融（客户分层营销、智能客服）、医疗（分诊助手、影像识别）、教育（知识库问答、拍照搜题）、电商（混剪助手、在线换衣、抖音直播回复）、人力资源（招聘打分、面试对练、AI 培训对练）、泛娱乐（AI 证件照、视频生成工作流）、在线客服（AI 助教、AI 销售）等 7 大行业共 50+ 可体验 Agent Demo，是 AI 解决方案专家培训的实操案例库。与 [[Prompt Engineering]]（提示词技能）、[[RAG（检索增强生成）]]（知识库问答）、[[Function Call]]（工具调用）三大基础能力配套，学员可通过邀请链接直接加入团队空间体验所有 Agent，并可 Fork 改造。与 [[固定镜头短视频制作的AI全流程解析]] 的 AI 视频生成工作流相关联。 + +**AI辅助PRD生成**：[[不会gemini的产品经理真的要淘汰]] 展示了大模型在产品经理工作流中的实战应用——通过 FeatureList 构思框架 → Mermaid 逻辑图辅助理解 → 分页面逐一描述生成 PRD+HTML 原型，可缩短文档工作时间 90% 以上。核心方法论：人负责"想"（创意决策），大模型负责"写"（格式补全）。 + +**[[autonomous-game-dev-pipeline]]**：基于 [[OpenClaw]] 的 AI Agent 全自动教育游戏开发流水线——每小时轮询队列产出 1 款儿童 HTML5 游戏，通过 "Bugs First" 优先策略（先修 bug 再做新功能）、Round Robin 年龄组均衡分配、纯 HTML5/CSS3/JS 无框架技术栈，实现单人维护 41+ 款游戏。核心工程纪律：同步 master → feature branch → conventional commits → PR merge，每次交付自动更新 CHANGELOG 和队列状态。核心价值：**每 7 分钟产出 1 款游戏或 1 个 bugfix**，单人可管理完整产品线。与 [[content-factory]] 同属 Agent 自动化内容生产，但前者侧重多 Agent 协作链，本方案侧重单人 Agent 的高纪律性流水线。 + +**[[aionui-cowork-desktop]]**：基于 [[AionUi]] 的 OpenClaw 桌面可视化 + 远程救援方案——通过 AionUi 的 Cowork 工作空间，用户可直接看到 OpenClaw 读写文件、运行命令、浏览网页，而非仅终端日志；内置 OpenClaw 部署专家，通过 Telegram/WebUI 远程诊断修复（`openclaw doctor`），解决"OpenClaw 挂了且不在机器旁"的困境；统一 MCP 配置一次，全局同步到 OpenClaw + 12+ 其他 Agent。与 [[Self-Healing-Home-Server]] 的远程修复场景关联，[[Multi-AgentHub]] 共享同一多 Agent 并行管理理念。 + +**播客制作自动化**：[[podcast-production-pipeline]] 提供 AI Agent 全自动播客制作流水线，覆盖「录前研究→大纲脚本→录制→时间戳笔记→社媒推广包→SEO描述」全链路。与 [[Content Factory]] 配合可将播客内容复用为博客、Newsletter、视频片段等多格式资产。 + +**Google ADK Skill 设计模式**：Google Cloud 发布的 5 种结构化设计模式，**[[ToolWrapper]]**（按需加载领域知识）、**[[Generator]]**（模板填空生成）、**[[Reviewer]]**（检查逻辑分离）、**[[Inversion]]**（先收集再行动）、**[[Pipeline]]**（硬性检查点工作流）。Anthropic 的 Skill 实践：内部几百个 Skills 总结出 3 条铁律——只写 Agent 不知道的东西、重点写踩坑清单、给工具不给指令。 + +**MCP 在 Cursor 中的集成**：MCP（Model Context Protocol）是基于 Client-Server 架构的协议，通过三种接口（GET 资源获取、POST 工具调用、Promise 提示词）实现 AI 大模型与外部工具的高效集成。在 Cursor 中有两种接入方式：SSE 服务端模式和本地 Command 命令行方式。在 Composer 的 Agent 模式下可自动执行 MCP 工具链，典型应用包括热点新闻服务（smisery 提供九个新闻来源）和 Sequential Thinking 逻辑推理工具。启用 Yolo Mode 可无确认自动执行命令，但存在误操作风险，默认关闭。 + +**会议记录自动化**：[[meeting-notes-action-items]] 提供 AI Agent 自动将会议转录文本（Otter.ai、Google Meet、Zoom）转换为结构化摘要，自动从会议中提取行动项并创建 Jira/Linear/Todoist/Notion 任务，同时发送 Slack/Discord 摘要，支持截止日提醒。核心洞察：**自动任务创建**比摘要本身更有价值，无法转化为追踪任务的会议记录只是"文档剧场"。 + +**Designing for Agentic AI**：[[designing-for-agentic-ai]] 阐述 GenAI（创作内容）vs Agentic AI（主动行动）的核心差异，以及为 Agentic AI 设计用户体验的 TCPCA 五原则——**透明度**（可视化 AI 决策进度与推理摘要）、**控制感**（停止/撤销/偏好设置机制）、**个性化**（基于历史行为预测未来需求）、**对话式交互**（自然语言界面 + 输入解读反馈）、**主动预判**（AI 预判需求并主动提供帮助，同时允许用户控制 AI 自主权级别）。核心洞察：**观察 AI 决策过程本身就是一种参与方式**，用户不再是被动旁观者；设计隐喻从"响应用户点击/滑动"转向"AI 运行时的实时反馈"。与 [[Google-5个-Agent-Skill-设计模式]]（ToolWrapper/Generator/Reviewer/Inversion/Pipeline）同属 AI Agent 设计方法论——后者侧重 Skill 架构模式，前者侧重终端用户体验设计。 + +**AI 簡報自動化工作流**：用 ChatGPT 先做知識整理，再交給 Canva / Gamma AI 输出演示文稿。两阶段工作流比直接用 AI 生成简报效果更好——ChatGPT 负责深度思考与内容组织，Canva/Gamma AI 负责视觉呈现与排版。核心洞察：让 AI 扮演不同角色（思考者 vs 设计师），充分发挥各工具的优势。与 [[YouTube-Content-Pipeline]] 共享同一"AI 整理 → AI 输出"两阶段模式。与 [[AI图生视频工具盘点]] 同属 AI 内容创作工具应用的不同垂直场景。 + +**[[我的工具集]]**：个人 AI 工具推荐清单，按类型分类（Text-to-Speech / Image-Editor / Image-to-Video / Web-Scraper / AI-Summary），每类列出工具名称、提供商、定价和链接。覆盖 Google AI Studio（Wavespeed 图生视频、Vidu $8/月、海螺 AI ¥42/月）、Brightdata（付费网页爬取）、Decopy（AI 摘要/思维导图/多语言输出）。与 [[AI图生视频工具盘点]] 互补——前者侧重工具索引清单，后者侧重免费工具详细评测。 + +Key concepts: [[AI簡報工作流]], [[AI圖生視頻工具]], [[文字生成視頻]], [[電商場景]], [[AI工具整合]], [[ChatGPT]], [[Canva]], [[Gamma AI]], [[Morning Briefing]], [[Todoist API]], [[AI-Driven Task Extraction]], [[TaskAutomation]], [[Recurring Tasks]], [[MeetingNotes]], [[ActionItemTracking]], [[TranscriptProcessing]], [[RAG从入门到精通系列]], [[Agent Personality Design]], [[Vibe Coding]], [[Design-to-Code Workflow]], [[Multi-AI Review]], [[CodeWeaver]], [[LLM Wiki]], [[多智能体系统可靠性]], [[Plan Mode]], [[Build Mode]], [[Workspace]], [[API Enablement]], [[OAuth 2.0]], [[Google Cloud Console]], [[Agent-Memory]], [[Claude Code Templates]], [[MCP（Model Context Protocol）]], [[Remote-SSH]], [[Bind Mount]], [[Attach 容器]], [[Docker 用户组]], [[SSH Config]], [[SSH 免密登录]], [[Vibe-Kanban]], [[OpenCode]], [[nvm]], [[pm2]], [[单一职责原则]], [[DRY原则]], [[模块化编程]], [[微服务架构]], [[Redis缓存]], [[消息队列]], [[输入-处理-输出模型]], [[并发编程]], [[Pain Point Mining]], [[Startup MVP Pipeline]], [[Agent-Driven Market Research]], [[Last 30 Days Method]], [[Pre-Build Validation]], [[Reality-Signal]], [[Competition-Analysis]], [[Pivot-Strategy]], [[Agent-Build-Gate]], [[CoworkWorkspace]], [[RemoteRescuePattern]], [[Multi-AgentHub]], [[MCPOnceAllAgents]], [[Personalization]], [[Custom Instructions]], [[Proactive AI]], [[Expert User Assumption]], [[Error Accountability]], [[baoyu-imagine]], [[AI-Logo-Generation]], [[Claude-Code-Skill]] + +### Productivity & Knowledge Management +Obsidian plugins, blogwatcher RSS monitoring, [[Quartz]] static site generation, project management systems, and personal CRM frameworks. QuickAdd plugin enables quick note capture via hotkeys for rapid idea recording. + +**Obsidian Skills 生态**（[[obsidian-必装-skills]]）：AI Agent 操作 Obsidian 的完整工具链——kepano 发布的 defuddle（网页清洗）、obsidian-cli（官方 CLI 增删改查）、obsidian-bases（.base 动态数据库）；Axton 发布的 obsidian-canvas-creator（径向布局算法智能排版）、mermaid-visualizer（文本转图表）、excalidraw-diagram（手绘风格图）；学术研究工具 tutor-skills（输入-内化-检测学习闭环）和 scholar-skill（L1/L2/L3 分级论文阅读，最长 2.5 小时异步任务）。[[Obsidian-CLI]]（[[obsidian-cli]]）是 Obsidian v1.12+ 内置的官方命令行工具，通过终端执行所有 GUI 操作，支持 AI Agent 自动化集成；[[Claudian]] 和 [[Obsidian-Agent-Client]] 是两款适配 Claude Code / OpenCode 等 Agent 的 Obsidian 第三方插件。与 [[Second Brain]]（对话记忆）、[[Personal Knowledge Base (RAG)]]（知识检索）、[[semantic-memory-search]]（向量搜索）同属 Obsidian 知识管理能力的不同实现。 + +**[[Quartz]]** 是 Obsidian 笔记的静态网站发布方案——将 Markdown 文件通过 `npx quartz build` 构建为 HTML/JS/CSS bundle，支持本地预览（`--serve`）和自托管部署。本地预览适合开发调试，生产部署需配置 Web 服务器处理无扩展名链接：Nginx 使用 `try_files $uri $uri.html $uri/ =404`，Apache 使用 RewriteRule，Caddy 使用 `try_files {path} {path}.html {path}/`。部署前必须正确配置 `baseUrl`，否则 RSS Feed 和 Sitemap 功能无法正常工作。[[Obsidian]] 笔记 → [[Quartz]] 构建 → 自托管（GitHub Pages / Nginx / Apache / Caddy）构成完整的个人知识发布链条。 + +**Personal Knowledge Base (RAG)**：基于 [[OpenClaw]] 的个人知识库 RAG 系统——通过 Telegram Topic 或 Slack Channel 投递任意 URL（网页/推文/YouTube 字幕/PDF），Agent 自动抓取内容并以 Embedding 向量入库；支持语义搜索（"我保存的关于 LLM memory 的内容？"），返回排名结果并附带来源；可被其他工作流（如 [[YouTube-Content-Pipeline]]）主动查询。核心理念：**捕获像发短信一样简单，检索像搜索一样容易**，无需专用 App。[[ClawHub]] 提供 knowledge-base skill 一键安装。与 [[Second Brain]] 同属 OpenClaw 持久记忆能力，Second Brain 侧重对话记忆，本方案侧重结构化知识检索。 + +**[[semantic-memory-search]]**：通过 [[memsearch]]（基于 [[Milvus]] 向量数据库）为 OpenClaw 的 Markdown 记忆文件添加语义搜索能力——用自然语言提问（"我们选了哪个缓存方案？"）即可找到相关内容，无需精确措辞。混合搜索（稠密向量 + BM25 + RRF 重排）兼顾语义相似性和关键词精确匹配；SHA-256 内容哈希实现增量索引，仅重新嵌入变更内容；支持本地模式（无需 API Key）。Markdown 文件是唯一真相，向量索引随时可重建。与 [[Knowledge-Base-RAG]] 同属 RAG 技术栈的不同场景。 + +**[[ai-memory-tools-two-camps]]**：AI 记忆工具的全景分类框架（@witcheer，2026-04-15）——GitHub 上 450+ repos 标记"agent-memory"、460+ 标记"context-management"，但几乎无人明确区分两个根本不同的技术路线： +- **Camp 1（Memory Backend）**：从对话中提取事实，存入向量/图数据库，检索时召回。代表：Mem0、MemPalace、Supermemory、Honcho。优化目标：**召回精度** +- **Camp 2（Context Substrate）**：维护结构化人类可读文件（Markdown/知识图谱），跨会话累积，背景进程整合。代表：OpenClaw、Zep、Thoth、TrustGraph、MemSearch、ALIVE。优化目标：**复合增长** +- Zep 从"memory"重塑品牌为"context engineering"是市场上最强的信号；作者预测 6 个月内"context engineering"将取代"memory"成为描述成熟 Agent 基础设施的标准术语。与 [[semantic-memory-search]]（MemSearch 的文件优先哲学）、[[Self-Improving-Skill]]（背景整合实践）同属 Context Substrate 范式的不同切面。 + +Key concepts: [[Obsidian Tasks]], [[Dataview]], [[Templater]], [[QuickAdd]], [[Spaced Repetition]], [[Kanban]], [[Projects]], [[Outliner]], [[Calendar]], [[DB Folder]], [[Homepage]], [[间隔重复]], [[看板]], [[动态模板]], [[双向链接]], [[Daily Notes]], [[Event Sourcing]], [[Second Brain]], [[Personal CRM]], [[Knowledge-Base-RAG]], [[Zero-Friction-Capture]], [[Semantic-Search]], [[Content-Ingestion]], [[semantic-memory-search]], [[memsearch]], [[Hybrid Search]], [[Reciprocal Rank Fusion]], [[Content Hashing]], [[File Watcher]] + +### 经典智慧与人生哲学 +**一语点醒梦中人**（[[一语点醒梦中人]]）：收录中国传统诗词与哲学典籍中的经典名句及其释义，涵盖儒、道、佛三家智慧——王维"行到水穷处，坐看云起时"的佛学顿悟、曾国藩"唯忘机可以消众机"的处世哲学、庄子"知其不可奈何而安之若命"的接受智慧、《老子》"大智若愚"的守拙哲学、《金刚经》"一切有为法如梦幻泡影"的空性观。核心价值：跨越千年的东方哲学智慧为现代人面对困境提供精神指引。 + +### 个人品牌与一人公司 +**[[If-You-Have-Multiple-Interests]]**（thedankoe）：系统论证多重兴趣是 AI 时代超能力的个人发展指南——核心主张：工业化专业化分工使人类沦为"愚蠢而依赖"的螺丝钉，[[Second-Renaissance]]（第二次文艺复兴）已经到来。个人成功三要素：[[Self-Education]]（自学）+ [[Self-Interest]]（自利）+ [[Self-Sufficiency]]（自立），三者相互支撑，自然涌现出 [[Generalist]]（通才型人才）。品牌不是个人简介和头像，而是读者关注3-6个月后积累的整体印象；内容是高质量创意的策展[[Idea-Museum]]（创意博物馆）；[[System-Economy]]（系统经济）中，产品即系统，差异化来自个人实践。内容创作三步法：①建立创意博物馆（3-5个高密度信息源）②基于 [[Idea-Density]]（创意密度）= 表现力 × 兴奋度筛选 ③同一想法用1000种结构表达。参考 [[Adam Smith]] 分工批判、达芬奇/米开朗基罗/[[Leonardo da Vinci]] 作为 [[Generalist]] 典范、[[Jordan Peterson]] 作为"非内容创作者"案例。核心洞察：你的优势更多在于跨领域知识的交汇处，而非专业知识本身。 + +系统性的个人商业化方法论：**天才地带自检**（识别能产生心流的活动）→ **底层能力挖掘**（追溯童年、毫不费力、底层通用三个维度）→ **心理陷阱识别**（愧疚陷阱、效率陷阱、卓越陷阱、努力陷阱）→ **Ikigai 框架定位**（热情 × 擅长 × 市场需求 × 报酬）→ **赛道验证**（搜索意图分析、支付意愿测试、落地页测试、预售验证）→ **产品体系设计**（引流免费PDF → ¥199入门工具 → ¥4999核心特训营 → ¥20,000/月高价咨询）→ **内容矩阵构建**（核心主题 × 内容形式，反向金字塔内容法，Build in Public）→ **销售漏斗搭建**（获客 → 激活 → 转化，价格锚定与诱饵效应）。 + +核心观点：一人公司的关键不是更努力工作，而是更聪明地定位，用 AI 杠杆放大个人优势。 + +Key concepts: [[Generalist]], [[Self-Education]], [[Self-Interest]], [[Self-Sufficiency]], [[Second-Renaissance]], [[Idea-Density]], [[Idea-Museum]], [[Brand-Environment]], [[Content-Creator]], [[System-Economy]], [[Attention-Economy]], [[AdamSmith]], [[LeonardoDaVinci]], [[一人公司]], [[个人品牌]], [[Ikigai框架]], [[天才地带（Zone of Genius）]], [[底层能力]], [[四个心理陷阱]], [[产品四层级体系]], [[内容矩阵]], [[Build in Public]], [[销售漏斗]], [[价格锚定]], [[诱饵效应]] + +## Source Distribution + +| Category | Count | Key Sources | +|----------|-------|-------------| +| The Agency Agents | 147+ agents | README, CONTRIBUTING, 12 divisions | +| CTP Topics | 73 topics | AWS, Azure, FinOps, Security | +| Learning Sessions | 30+ sessions | OpenText, AWS, EKS, Cloud FinOps | +| Home Office | 60+ docs | Docker, NAS, Network, Monitoring | +| AI & Productivity | 80+ docs | Claude, OpenClaw, Obsidian, Prompting | +| Marketing Agents | 30+ agents | Cross-platform, China E-commerce | + +## Key Entities + +- [[tukuai]] — 独立研究者，递归自我优化生成系统论文作者，为 [[Self-Improving-Skill]] 提供原则性理论框架 +- [[Alex Ewerlöf]] — 资深Staff Engineer（27年经验），KTH系统工程硕士，专注可靠性工程和弹性架构，《Multi-Agent System Reliability》作者，主张将LLM视为不可靠组件而非拟人化智能体 +- [[Adam Smith]] — 古典经济学家，《国富论》（1776）作者，其分工理论被 [[If-You-Have-Multiple-Interests]] 引用，揭示专业化分工对人类智识和自主性的负面影响 +- [[Leonardo da Vinci]] — 文艺复兴时期通才典范（画家+雕塑家+工程师+解剖学家），[[If-You-Have-Multiple-Interests]] 中 [[Second-Renaissance]] 和 [[Generalist]] 概念的历史原型 +- [[The Agency]] — open-source AI agent collection (147 agents, 12 divisions) +- [[agency-agents]] — GitHub repository +- [[DracoVibeCoding]] — 公众号"Draco正在VibeCoding"作者，专注 Vibe Coding 与 AI Agent 实战分享 +- [[OpenClaw]] — multi-agent framework with memory +- [[clawr.ing]] — 托管电话服务提供商，消除 Twilio 等传统电话 API 配置复杂度，为 Agent 提供主动拨打电话通知能力，覆盖 100+ 国家 PSTN 电话，不存储录音 +- [[clawhub.ai]] — OpenClaw Skill 市场，托管 clawr.ing 等 Skill 安装包 +- [[AionUi]] — 桌面多 Agent Hub（macOS/Windows/Linux），将 OpenClaw 作为可视化 Cowork Agent 运行，支持内置远程救援专家和统一 MCP 配置 +- [[n8n]] — workflow automation +- [[Shlomi Ben-Hur]] — Micro Focus 产品安全小组（PSAC）成员，主讲 CTP Topic 21（供应链安全）和 CTP Topic 24（产品隐私框架），推动将法律合规要求翻译为技术实现 +- [[Octane-Hub]] — Software Factory 团队，Micro Focus 云转型计划一部分，主导 Docker 容器化工作负载从 Bibling Lab 向 AWS Landing Zone 的迁移项目，CTO 为 Holger Rode +- [[Node.js]] — JavaScript 运行时环境，n8n-mcp 的运行依赖，也是 [[n8n]] 工作流引擎的后端运行环境 +- [[gog CLI]] — 由 steipete 开发的 Google Workspace 命令行管理工具（Homebrew 安装），支持 Gmail/Calendar/Drive/Contacts/Docs/Sheets 全套服务，[[personal-crm]] 和 [[multi-channel-assistant]] 的前置依赖 +- [[Quartz]] — static site generator for wikis +- [[RSSHub]] — open-source RSS aggregator +- [[RackNerd]]：低总价OpenVZ/KVM VPS提供商，本方案中托管公网VPS1（192.227.222.142, vps.ishenwei.online），运行frps服务端（端口7000）和Caddy自动HTTPS反向代理（*.ishenwei.online），作为全网内网服务的统一公网入口 +- [[Synology NAS DS718]]：群晖NAS设备（192.168.3.17, nas.ishenwei.online），运行DSM管理界面及Calibre/MinIO/Zipline/Navidrome/Jellyfin/Prometheus/Alertmanager/v2rayA/vaultwarden/Portainer/CloudDrive2等Docker应用，通过FRP+Caddy暴露nas/navidrome/calibre/jellyfin/zipline/miniflux等服务至公网 +- [[Docker卷]] — Docker 容器持久化数据存储，默认路径 /var/lib/docker/volumes，是 TikTok 业务数据备份的核心对象 +- [[it-tools]] — 开源开发者工具集合 Web UI（corentinth/it-tools），提供 100+ 实用工具如 URL 编解码、UUID 生成、Cron 解析、哈希计算等，通过 Docker Compose 部署，端口 8999，内存限制 128MB +- [[Navidrome]] — 开源音乐流媒体服务器，Subsonic API 兼容，支持网页端与移动客户端 +- [[Transmission]] — 开源 BT 下载客户端，Home Server 媒体中心核心组件，负责下载环节，与 Jellyfin/Navidrome 构成"下载→播放"工作流 +- [[LinuxServer.io]] — 开源 Docker 镜像维护组织，为 Transmission/Jellyfin/Navidrome 等自托管应用提供标准化 Docker 镜像 +- [[MariaDB]] — 开源关系型数据库，Synology NAS Docker 环境部署，支持内网（192.168.3.17:3307）和公网（mysql.ishenwei.online:63307）双通道访问 +- [[Claude Code]] — Anthropic CLI agent +- [[Claude Desktop]] — Anthropic Claude AI 桌面应用，支持 MCP 协议扩展，通过 n8n-mcp 连接 n8n 工作流引擎 +- [[ChatGPT]] — OpenAI 开发的大语言模型对话产品，支持自定义指令（Custom Instructions）功能，[[openai-chatgpt-个性化定义]] 是其完整配置案例 +- [[OpenAI]] — 美国 AI 研究公司，开发 GPT 系列大语言模型、ChatGPT 产品、API 接口，为本 Wiki 多个 AI 工具提供底层技术支持 +- [[OpenCode]] — Vibe Coding CLI agent +- [[Trae]] — 国产 AI 增强型 IDE，支持 Remote-SSH 远程开发和 VS Code 插件生态 +- [[ISO-27001]] — 国际信息安全管理体系标准（云安全合规基础） +- [[HIPAA]] — 美国医疗健康信息隐私法规 +- [[GDPR]] — 欧盟通用数据保护条例 +- [[Raj-Vardhan-Singh]] — LinkedIn 云计算文章作者 +- [[Agentic AI]] — 自主决策和任务执行能力的AI系统 +- [[Kubernetes]] — 容器编排平台（EKS/GKE/AKS） +- [[Terraform]] — IaC 基础设施即代码工具 +- [[LaunchDarkly]] — Feature Flag 管理平台（HP、Christian Dior RTO 优化案例） +- [[Veeam]] — 传统灾备工具（数据库备份、服务器镜像） +- [[Acronis]] — 传统灾备工具（跨区域复制） +- [[Portainer]] — Docker 可视化管理工具（portainer/portainer-ce），通过 Web UI 管理容器/卷/网络，支持 Edge Agent 集群管理，Home Server 运维常用；重装前需清理残留容器/Volume/Network，可通过 `external: true` 复用旧资源 +- [[Docker]] — 容器化平台，所有监控组件（Prometheus / Grafana / node_exporter / cAdvisor / blackbox_exporter）的部署底座，通过 Docker Compose 实现一键启动 +- [[Docker Compose]] — 多容器应用的定义和编排工具，通过 YAML 文件（docker-compose.yml / compose.yaml）声明式定义服务/网络/卷，`docker compose up/down` 管理整个堆栈生命周期，支持 `external: true` 复用已有网络和卷 +- [[Docker卷]] — Docker 容器持久化数据存储，默认路径 /var/lib/docker/volumes，通过 `docker volume ls` 查看，`docker volume rm` 删除；[[用docker安装portainer]] 的 `portainer_data` 卷存储 Portainer 用户、配置和 Edge Agent 数据 +- [[Docker Network]] — Docker 容器网络连接，默认 bridge 网络 IP 为 172.17.0.1，自定义网络如 172.24.0.1；compose 项目间同名网络冲突会产生 WARN 警告 +- [[Prometheus]] — CNCF 毕业项目，开源时序数据库和监控告警系统，pull 模式采集 exporters 指标，支持 PromQL 查询和告警规则引擎，是家庭监控方案的核心数据引擎 +- [[Grafana]] — 开源可视化平台，支持多数据源（Prometheus / Loki / VictoriaMetrics）仪表盘和告警管理，家庭方案中通过 Dashboard ID（1860/14282/7587）快速导入官方模板 +- [[node_exporter]] — Prometheus 官方主机指标采集器，以 host network 模式运行，采集 CPU / 内存 / 磁盘 / 网络 / I/O 等系统指标 +- [[cAdvisor]] — Google 开源容器资源监控工具，挂载 Docker socket 采集容器级别资源指标，为 Prometheus 提供容器层可观测性 +- [[blackbox_exporter]] — Prometheus 官方黑盒探测 exporter，通过 HTTP/TCP/ICMP/DNS/TLS 探测实现服务可用性和证书到期监控 +- [[Alertmanager]] — Prometheus 告警分发组件，支持告警分组、抑制、静默及邮件/Slack/Teams/Webhook 多通道路由 +- [[Uptime Kuma]]（louislam/uptime-kuma）— 自托管 uptime monitoring 工具，支持 HTTP/TCP/DNS/TLS 合成监控，适合外网/内网可用性探测 +- [[Netdata]] — 开箱即用的实时主机/容器监控面板，默认端口 19999，适合快速诊断，与 Prometheus 可互补使用 +- [[VictoriaMetrics]] — Prometheus 时序数据库替代方案，支持长期存储和高效写入，适合大规模数据保留场景 +- [[Portainer]] — Docker 可视化管理工具，不替代 Prometheus 但便于运维快速操作容器 +- **[[BMC]]** — 企业IT管理解决方案提供商（BMC Helix / Control-M） +- **[[AWS]]** — Amazon Web Services，提供 RDS 和 Aurora 两款托管数据库服务 +- **[[Amazon RDS]]** — 关系型数据库服务，计算与存储分离（EBS），支持 Multi-AZ 部署 +- **[[Amazon Aurora]]** — 云原生关系型数据库，6 副本跨 3 AZ 共享集群卷架构 +- [[Greg Klau]] — CTP Topic 66 讲师，主讲 PostgreSQL RDS vs Aurora 差异对比 +- [[Martin Rosler]] — Learning Sessions 讲师，主讲 OpenText Tagging Standard v2，聚焦云资源标签标准化 +- [[Vinay]] — FinOps 团队成员，主讲云成本优化技术实践（工作负载优化 + 费率优化）；Graviton 20-25% 节省、Spot 90% 折扣、Savings Plans 实施流程 +- [[Phenops-Team]] — OpenText 内部团队，2023 年发起云资源标签标准化项目，负责 Savings Plans 和 Reserved Instances 费率承诺计划的统一实施（最低 $5k/年，仅无预付选项） +- **[[Google-Cloud]]** — Google Cloud Platform +- [[Btop++]] — TUI系统监控器，作者首选 +- [[Htop]] — 轻量级TUI进程监控器 +- [[Glances]] — 超轻量TUI监控器 +- [[Bottom]] — TUI实时图表监控器 +- [[Mission Center]] — 类Windows任务管理器的GUI应用 +- [[Stacer]] — 功能最全的GUI监控+维护工具 +- [[网件RAX50]] — NETGEAR WiFi 6路由器，支持刷入梅林固件 +- [[梅林固件]] — 华硕路由器第三方固件改良版，支持软件中心插件 +- [[MerlinClash插件]] — 基于Clash核心的梅林固件科学上网插件，支持策略组分流 +- [[机场]] — 提供代理节点订阅服务的服务商 +- [[3X-UI]] — Xray 可视化管理面板（mhsanaei/3x-ui），提供 Web UI 管理 25 项运维操作（启停、更新、SSL证书、Geo更新、BBR等），支持 VLESS+Reality 入站配置生成 +- [[Xray]] — 新一代代理核心，支持 VLESS/VMess/Trojan/SS 等多协议，内置 Reality 流量伪装方案，是 3X-UI 的底层引擎 +- [[frp]] — 开源内网穿透工具，包含 frps（服务端）和 frpc（客户端）两个组件，通过反向隧道使内网服务可被公网访问，支持 TCP/UDP/HTTP 等多种协议 +- [[Ubuntu Server]] — Ubuntu Server 是 Canonical 维护的 Linux 服务器操作系统，默认使用 systemd 作为初始化系统，Ubuntu Server 24.04 LTS 是当前长期支持版本 +- [[systemd]] — Linux 系统和服务管理器，Ubuntu Server 的默认初始化系统，通过 unit 文件（service/timer/socket）和 systemctl 命令管理服务生命周期，支持开机自启（enable）、自动重启（Restart=on-failure）、日志收集（journald）等生产级特性 +- [[Mac Mini M4]] — Apple Silicon Mac Mini，作为家庭服务器运行 FRP 客户端、N8n、OpenClaw 等服务，支持 ARM64 架构 +- [[systemd-logind]] — Linux 系统登录管理器，负责管理用户会话、电源事件和系统休眠行为，Ubuntu 笔记本合盖休眠行为由其控制，通过 /etc/systemd/logind.conf 配置 HandleLidSwitch 系列参数 +- [[HandleLidSwitch]] — systemd-logind 的合盖动作配置指令，支持 ignore（忽略/继续运行）/suspend（待机）/hibernate（休眠）/poweroff（关机）/lock（锁屏）等值，Ubuntu Server 笔记本作为无显示器服务器时需设为 ignore +- [[Caddy]] — Go 语言编写的自动 HTTPS 反向代理服务器，默认启用 Let's Encrypt 证书，与 frp 配合提供内网服务的 HTTPS 访问 +- [[VPS]] — 公网虚拟专用服务器，本方案中托管 frps 和 Caddy，作为内网穿透的公网中转站（IP: 192.227.222.142） +- [[阿里云 DNS]] — 域名 ishenwei.online 的 DNS 解析服务，通过 A 记录将子域名指向 VPS 公网 IP +- [[Bandwagon VPS]] — 低总价 OpenVZ/KVM VPS 提供商，资料中 VPS2（104.194.92.188）托管了 3X-UI + Xray 服务 +- **[[CloudDrive2]]** — 云盘挂载工具，支持阿里云盘/Google Drive/OneDrive 等，通过虚拟文件系统将云端存储挂载为本地目录，Web UI 端口 19798 +- **[[矿神源]]** — Synology 社群第三方套件源（SPK 格式），提供 CloudDrive2 等官方未收录应用 +- **[[阿里云盘]]** — 阿里巴巴云盘服务，CloudDrive2 的主要挂载目标 +- [[AdsPower]] — 指纹浏览器产品，支持浏览器指纹隔离，免费版提供5个环境，是跨境服务注册的推荐工具 +- [[PingMe]] — 短信接码平台，支持美国区号码接收验证码，需下载App，最低充值2美元 +- [[WildCard]] — 虚拟信用卡服务，支持支付宝充值，解决国内用户跨境支付难题 +- [[Claude Pro]] — Anthropic Claude AI聊天工具的Pro订阅服务，月费20美元，需海外支付方式 +- [[v2rayN]] — 跨平台代理客户端（Windows/Linux/macOS），支持 VLESS+Reality 等多协议。内置部分 Core（Xray/sing-box/mihomo），其他 Core 需单独下载。Windows WPF 版需 .NET 8 Runtime；Avalonia UI 版为跨平台自包含版本；macOS DMG 需 `xattr -cr` 修复签名 +- [[v2rayNG]] — Android 代理客户端，v2rayN 的移动版，功能一致 +- [[Avalonia UI]] — 跨平台 .NET UI 框架，v2rayN desktop 版基于此构建，实现 Windows/Linux/macOS 三平台统一界面，无需额外运行时依赖 +- [[sing-box]] — v2rayN 支持的代理核心之一，支持多协议 +- [[mihomo]] — v2rayN 支持的代理核心，mihomo 协议实现 +- [[2dust]] — v2rayN GitHub 仓库维护者（github.com/2dust） +- [[BBR]] — Google TCP 拥塞控制算法，3X-UI 提供一键启用，可提升跨境网络吞吐量 +- [[代理客户端]] — 运行在终端设备上通过代理协议连接远程节点的软件，v2rayN 是典型产品，支持 VLESS/VMess/Trojan/SS 等多种协议 +- [[代理协议]] — 代理客户端与服务端通信的协议规范，如 VLESS+Reality、VMess、Trojan、Shadowsocks 等 +- [[Reality]] — Xray 的流量伪装方案，通过 SNI 分流实现深度伪装，v2rayN 可作为 Reality 客户端使用 +- [[Avalonia UI]] — 跨平台 .NET UI 框架，v2rayN desktop 版基于此构建，实现 Windows/Linux/macOS 三平台统一界面，无需额外运行时依赖 +- [[WPF]] — Windows Presentation Foundation，Windows 原生 UI 框架，.NET 桌面应用首选，v2rayN WPF 版基于此 +- [[.NET Desktop Runtime]] — .NET 桌面运行时环境，WPF 应用必需依赖，v2rayN WPF 版要求 .NET 8 Desktop Runtime +- [[便携版]] — 解压即用、数据存放在程序同目录、可复制多份独立运行的软件分发方式 +- [[安装版]] — 数据存放在系统规定用户目录、通过包管理器安装的软件分发方式（deb/rpm/dmg） +- [[代理核心]] — 代理客户端的底层引擎，如 Xray、sing-box、mihomo，负责实际流量转发 +- [[分流模式]] — 代理客户端的路由策略，"大陆白名单"模式下仅代理非中国大陆流量，减少不必要的代理开销 +- [[VPN Panel]] — Web 界面类代理管理工具的统称，3X-UI 属于此类，降低 Xray 服务端运维门槛 +- [[KoolCenter固件服务器]] — 提供梅林固件下载的服务器平台 +- **[[Clonezilla]]** — 开源磁盘镜像工具（再生龙），支持 savedisk/restoredisk 全盘镜像备份到 NAS +- **[[Rufus]]** — 开源 U 盘启动盘制作工具，ISOHybrid 镜像写入模式选择（ISO 模式推荐） +- **[[HP ZBook]]** — HP 工作站笔记本，支持 UEFI/F9 启动菜单，F10 进入 BIOS，作为 Ubuntu 24.04 安装目标机 +- **[[NodeWarden]]** — 将 Bitwarden 服务器端部署到 Cloudflare Workers 的开源实现，运行在边缘计算平台，无需 VPS 和服务器维护，数据存储在 Cloudflare D1 + R2，支持 Bitwarden 官方全平台客户端 +- **[[Cloudflare Workers]]** — Cloudflare 边缘计算平台，基于 V8 隔离的 Serverless 运行时，NodeWarden 的部署环境 +- **[[Cloudflare D1]]** — Cloudflare 边缘 SQLite 数据库，NodeWarden 的主数据存储（保管库/同步数据） +- **[[Cloudflare R2]]** — Cloudflare S3 兼容对象存储，NodeWarden 用于存储密码附件 +- [[V2RayA]] — V2Ray 的 Web 可视化管理界面，基于 V2Ray 内核，支持透明代理和分流策略，在群晖 NAS 上以 Docker 容器方式部署 +- **[[Apache Superset]]** — Apache 软件基金会旗下的开源 BI 平台，通过 Docker 快速部署，支持 SQL 查询、多样化图表和仪表盘构建。Home Server 场景通过 `apache/superset:GHA-*` 镜像容器化部署，6 步初始化流程：拉取镜像 → 启动容器 → 创建管理员 → 数据库迁移 → 加载示例 → 完成初始化，默认端口 8088（映射 8777），内置 SQLite，可选外挂 MySQL +- **[[RustDesk]]** — 开源远程桌面软件，支持自建中继服务器，可通过修改 GDM3 配置 `WaylandEnable=false` 强制 X11 解决 Ubuntu 24.04 Wayland 登录限制问题 +- **[[Ollama]]** — 开源本地 LLM 运行框架（ollama.com/ollama.org.cn），支持 macOS/Windows/Linux/Docker，提供简洁命令 `ollama run ` 运行大语言模型，通过 API（localhost:11434）和 Open WebUI 提供多元化接入方式，DeepSeek-R1 系列模型官方支持 +|- **[[Open WebUI]]** — 开源大模型 Web 界面（ghcr.io/open-webui/open-webui:main），基于浏览器访问，支持 Ollama/OpenAI API 接入，可配置 RAG 本地知识库（bge-m3 嵌入模型）和联网搜索，Docker Compose 一键部署 +|- **[[WSL2]]** — Windows Subsystem for Linux 2，Windows 10/11 内置的 Linux 虚拟机环境，默认使用 NAT 网络模式，通过 `.wslconfig` 的 `networkingMode=mirrored` 可实现与 Windows 共享网络堆栈；[[ghproxy]] 提供 GitHub 下载的反向代理加速 + +|- **[[ghproxy]]** — ghproxy.com，国内可访问的 GitHub 反向代理服务，通过将 `github.com` 替换为 `mirror.ghproxy.com/https://github.com` 绕过网络限制，适用于 uv 安装器、Claude Code 等工具的下载加速 +|- [[ProxyChains]]：通过 LD_PRELOAD 劫持 socket 调用使任意终端命令走 SOCKS5 代理的工具，配置文件 /etc/proxychains4.conf，格式 `socks5 127.0.0.1 10808`，适用于临时命令级代理 +- [[Git 全局代理]]：Git 不读取系统环境变量，必须通过 `git config --global http.proxy socks5://127.0.0.1:10808` 设置 +- [[Docker Daemon Proxy]]：通过 systemd drop-in 文件（/etc/systemd/system/docker.service.d/http-proxy.conf）注入环境变量使 docker pull 走代理，docker info | grep -i proxy 验证 +- [[Docker 网络网关 IP]]：Docker 容器内访问宿主机的 IP，bridge 网络默认 172.17.0.1，自定义网络如 172.24.0.1，容器内 127.0.0.1 指向自身而非宿主机 +- [[SOCKS5h 代理]]：socks5h 协议变体，DNS 解析由代理服务器完成，防止本地 DNS 污染，curl -x socks5h:// 使用 +- [[环境变量代理]]：通过 HTTP_PROXY/HTTPS_PROXY/ALL_PROXY 环境变量让程序走代理，Docker 容器内使用 ALL_PROXY=socks5://172.24.0.1:10808 +- [[Wayland]]：Linux 新一代显示协议，Ubuntu 24.04 默认使用，基于安全设计严格限制外部程序在未登录状态下获取屏幕控制权，是 RustDesk 无法在 Login Screen 场景工作的根本原因 +- [[X11]]：经典显示协议，兼容性好、权限开放度高，远程桌面场景下稳定性优于 Wayland，通过修改 GDM3 配置 `WaylandEnable=false` 强制启用 +- [[GDM3]]：GNOME Display Manager，Ubuntu 默认登录管理器，控制用户会话初始化，支持 Wayland 和 X11 两种显示协议 +- **[[透明代理]]** — 通过修改 iptables 规则劫持系统出站流量，国内直连、国外走代理的分流机制，V2RayA 的核心实现方式 +- **[[分流模式]]** — V2RayA 的路由策略，"大陆白名单"模式下仅代理非中国大陆流量，减少不必要的代理开销 +- **[[iptables]]** — Linux 内核防火墙，V2RayA 通过修改 iptables 规则实现透明代理 +- **[[MinIO]]** — 开源 S3 兼容对象存储，Zipline 图床系统的存储后端，提供高性价比本地存储 +- **[[Zipline]]** — 开源自托管图床应用，提供前端上传 UI 和 REST API，支持 [[n8n]] 工作流集成 + +### TikTok E-commerce Operations +**[[电商如何选品-如何找到爆款-选品策略]]**（YouTube 视频摘要）：电商选品系统方法论——20 种选品策略（细分市场定位如LGBTQ群体、情境配对如露营三件套、季节性规划等）+ POD 低成本测款模式 + 工具辅助分析（Salesmartly 多平台订单管理、Erank 竞争分析、Pinterest/Etsy 趋势报告）。核心观点：未来品牌需针对细分市场而非大众市场；多工具组合使用可提升客户转化率和选品效率。与 [[做TK跨境思路不对努力白费]]（运营策略）和 [[TikTok E-commerce Product Management]]（Django 产品管理系统）共同构成 TikTok 跨境电商知识体系。 + +**[[做TK跨境思路不对努力白费]]**：TikTok 跨境电商全流程实战指南——从市场选择（优先美区/日本，避开东南亚）→ 账号准备（选区看直播了解流程）→ 选品策略（数据软件分析+单一垂直类目）→ 店铺运营（流量监控+商品优化）→ 流量获取（短视频营销+达人合作）→ 仓储物流（海外仓+海运补货）→ 团队建设（招聘分工），提供完整的执行框架。核心观点：思路正确是成功的前提，市场定位和选品是核心竞争力。与 [[电商如何选品]] 同属选品策略范畴，与 [[TikTok E-commerce Product Management]]（Django 产品管理系统）互补——前者侧重运营策略，后者侧重技术实现。 + +**电商数据采集与处理系统**：基于 Docker + Ubuntu + n8n 的可自动化、可扩展、AI增强的电商数据采集与处理系统。三层架构：爬虫层（Scrapy/Playwright）→ AI处理层（n8n + LLM API）→ 存储展示层（PostgreSQL/MinIO + Grafana）。推荐 Scrapy + Playwright 组合抓取动态页面，Docker Compose 容器化部署，输出 JSON/CSV 供 n8n 消费；n8n 工作流实现定时启动爬虫→读取数据→LLM提取属性→写入数据库→报表通知的全链路自动化；AI 处理任务包括摘要分类、多语言翻译、特征提取、异常检测；本地可使用 Ollama（Mistral/Llama3）通过 HTTP Request 调用，无需外部 API Key；防封策略包括 User-Agent 轮换、代理池（Bright Data/ScraperAPI）和下载延迟随机化。与 [[做TK跨境思路不对努力白费]]（运营策略）互补，后者侧重电商运营全流程，前者侧重技术架构搭建。与 [[scrapy-playwright-抓取tiktok-shop-data]] 同属电商数据采集技术栈。 + +### TikTok E-commerce Product Management +A comprehensive Django-based product data management system for TikTok Shop. Covers Django ORM models (Product, ProductImage, ProductVideo, ProductVariation, ProductReview), Django Admin customization (TinyMCE rich text, inline models, image preview modals), REST API via Django REST Framework with django-filter for search and filtering, Docker + Gunicorn + Nginx production deployment, Django-Q async task queue for Bright Data API scraping, and custom Management Commands for JSON data import. Key components: Product list with thumbnail display, multi-condition filtering by store_name, bulk product fetch via Bright Data asynchronous API, description detail HTML generation, and Apache Superset BI dashboard integration. + +Key concepts: [[Django ORM]], [[Django REST Framework]], [[Django Admin 定制]], [[Docker 容器化部署]], [[Django-Q 异步任务]], [[Bright Data API]], [[MySQL / MariaDB 数据库]], [[Gunicorn]], [[Nginx]], [[自定义管理命令]] + +### Content Strategy & Production +**[[marketing-content-creator]]**（Marketing Content Creator）：The Agency Marketing 部门的多平台内容创作专家 Agent——专注于跨平台品牌内容策略制定、叙事构建和受众互动优化。**核心理念：在每个受众所在的平台上，创作有吸引力的故事**。核心能力：**内容策略框架**（编辑日历 + 内容支柱 + 受众优先规划 + 跨平台优化）；**多格式创作**（图文/视频脚本/播客/信息图/社媒内容）；**品牌叙事**（叙事开发 + 品牌声音一致性 + 情感连接建立）；**SEO 内容优化**（关键词优化 + 搜索友好格式 + 有机流量生成，目标 40% 增长）；**视频制作全链路**（脚本创作 + 分镜 + 剪辑指导 + 缩略图优化，完播率目标 70%+）；**绩效分析**（内容分析 + 参与度优化 + ROI 测量，ROI 目标 5:1）。与 [[marketing-social-media-strategist]] 协同——Content Creator 负责内容生产，Social Media Strategist 负责分发策略；与 [[marketing-twitter-engager]]（Twitter 内容定制）、[[marketing-linkedin-content-creator]]（LinkedIn 长文内容）、[[marketing-tiktok-strategist]]（TikTok 视频脚本）构成"内容生产→平台分发"的完整工作流；与 [[marketing-video-optimization-specialist]] 在视频后期优化和效果分析上协作；与 [[marketing-growth-hacker]] 在增长策略上协同。 + +### Data-Driven Growth & Experimentation +**[[marketing-growth-hacker]]**（Marketing Growth Hacker）：The Agency Marketing 部门的增长黑客专家 Agent——专注于通过数据驱动的实验和非常规营销策略，实现快速、可规模化的用户获取与留存。**核心理念：找到那个还没被人涉足的流量渠道，然后把它规模化——增长黑客的核心竞争力不在于\"砸钱买广告\"，而在于发现别人忽视的有机增长杠杆**。核心方法：**增长漏斗优化**（认知Awareness→获客Acquisition→激活Activation→留存Retention→收入Revenue→推荐Referral，全链路转化率提升）；**A/B/多变量实验体系**（每月10+增长实验，30%实验显示统计显著正增长）；**病毒系数工程**（K-factor > 1.0，通过推荐程序、分享激励和网络效应实现用户自发传播）；**北极星指标体系**（North Star Metric 驱动所有增长工作，定义产品为用户创造的核心价值）；**LTV:CAC 经济学**（LTV:CAC ≥ 3:1 为健康增长门槛，CAC 回本周期 < 6个月）。关键指标：月环比自然增长 20%+、K-factor > 1.0、CAC 回本周期 < 6个月、LTV:CAC ≥ 3:1、首周激活率 60%+、Day 7 留存 40%。交付物涵盖增长实验设计、病毒裂变机制、增长渠道发现与评估、北极星指标选择与追踪框架。与 [[marketing-content-creator]] 协同——Content Creator 生产的病毒内容素材是 Growth Hacker 设计裂变机制的基础；与 [[marketing-social-media-strategist]] 互补——Social Media Strategist 专注平台有机运营，Growth Hacker 负责将社交流量转化为可规模化实验的增长假设；与 [[marketing-tiktok-strategist]] 存在策略差异——TikTok Strategist 以平台内容为核心预设 TikTok 为最重要渠道，Growth Hacker 以实验数据为核心，哪个渠道 K-factor 最高就用哪个。 + +### Professional Social Media (LinkedIn & Twitter) +**[[marketing-social-media-strategist]]**（Social Media Strategist）：The Agency Marketing 部门的跨平台社交媒体战略专家 Agent——专注于 LinkedIn、Twitter 等专业社交平台的企业级品牌建设和社群运营。**核心理念：通过统一信息流设计、平台适配内容优化、社群互动管理、思想领导力建设，实现品牌在专业社交平台的影响力提升**。核心能力：**LinkedIn 全栈运营**（公司页面/个人品牌/专栏文章/新闻通讯/LinkedIn Ads）；**Twitter 实时协同**（与 Twitter Engager Agent 协作保持一致声音）；**B2B 社交销售**策略与销售管道开发；**员工倡导计划**设计与品牌大使激活；**跨平台内容瀑布流**（LinkedIn 首发 → Twitter 适配 → 其他平台分发）。成功指标：LinkedIn 互动率 3%+（公司页面）/5%+（个人品牌）、每月受众覆盖增长 20%、50%+ 内容达到平台基准、社交广告 ROI 3 倍+。与 [[paid-media-paid-social-strategist]] 互补——前者专注有机内容运营和品牌建设，后者专注付费社交广告投放；与 [[marketing-instagram-curator]]（视觉平台）和 [[marketing-douyin-strategist]]（短视频平台）构成完整的多平台营销矩阵。 + +**[[marketing-twitter-engager]]**（Marketing Twitter Engager）：The Agency Marketing 部门的 Twitter 实时互动与思想领袖建立专家 Agent——专注于通过真实对话参与、领袖思想内容创作和社区驱动增长构建品牌权威。**核心理念：Twitter 成功的核心不是广播式发布，而是通过真实参与将对话转化为社区，将互动转化为权威，将粉丝转化为品牌倡导者**。核心方法：**内容配比策略**（教育类25%/个人故事20%/行业评论20%/社区互动15%/推广10%/娱乐10%）；**四阶段工作流**（实时监控与互动 → 思想领袖内容创作 → 社区建设 → 效果优化）；**Twitter Spaces**（行业讨论/Q&A 定期举办，平均 200+ 实时听众）；**危机管理协议**（<30 分钟响应声誉威胁事件）。关键指标：互动率 ≥2.5%、回复率 80%（2小时内）、教育 thread ≥100 转推。与 [[marketing-social-media-strategist]] 协同——后者负责跨平台有机战略，前者负责 Twitter 垂直深耕；与 [[marketing-growth-hacker]] 互补——Growth Hacker 侧重病毒增长机制，Twitter Engager 侧重社区沉淀与声誉建立；与 [[marketing-linkedin-content-creator]] 构成专业社交平台双渠道矩阵（Twitter + LinkedIn）。 + +### Douyin Short-Video & Livestream Commerce +**[[marketing-douyin-strategist]]**（Marketing Douyin Strategist）：The Agency Marketing 部门的抖音短视频营销与直播带货策略专家 Agent——深度掌握抖音推荐算法机制、爆款视频策划与直播带货全链路，是国内电商流量运营的核心角色。**核心理念：抖音的核心不是"拍好看的视频"，而是"前三秒钩住注意力，让算法替你分发"**。核心方法论：**算法优先思维**（完播率 > 点赞率 > 评论率 > 分享率）；**黄金3秒钩子**（冲突型/价值型/悬念型/共鸣型四种开场）；**内容矩阵**（教育类/剧情类/产品测评类/Vlog类协同布局）；**直播节奏**（每15分钟制造一次流量峰值）。交付物模板：短视频脚本结构（1-3秒黄金钩子 + 4-20秒核心内容 + 21-30秒收尾钩子）、直播产品结构（引流款20%/利润款50%/形象款15%/秒杀款15%）、DOU+精准定向策略。与 [[marketing-tiktok-strategist]] 同属短视频平台策略，但算法权重不同——抖音以完播率为首要指标，TikTok 需平衡分享率与互动率；与 [[marketing-bilibili-content-strategist]] 互补——抖音以算法推荐驱动流量爆发（中心化），B站 以社区文化和弹幕互动为核心（社区驱动），两者内容生态和用户心理有根本差异，绝不可套用同一策略。| + +**[[marketing-bilibili-content-strategist]]**（Marketing Bilibili Content Strategist）：The Agency Marketing 部门的 B站（Bilibili）平台内容策略与 UP主增长专家 Agent——专注于弹幕文化精通、B站算法优化、社区建设和品牌内容原生化。**核心理念：B站 用户最讨厌硬广——社区文化标准要求内容绝对真实，原生化品牌内容 + ACG 文化精通 = 可持续增长**。核心方法：**四阶段工作流**（平台洞察与账号审计→内容架构与生产→发布与社区激活→增长优化与变现）；**弹幕互动设计**（在剧本阶段就嵌入弹幕触发点，引导社区自发生成弹幕）；**三连率体系**（Coin 投币 + Favorite 收藏 + Like 点赞，目标 >5%）；**恰饭内容原生化**（品牌合作需尊重社区文化，否则立即被抵制）；**内容分区策略**（知识区/科技区/生活区/美食区/游戏区/动漫区各自独立的赛道逻辑）。关键指标：三连率 >5%、弹幕密度 >30条/分钟关键片段、每月至少一条视频进入"每周必看"或"热门推荐"。交付物模板涵盖内容策略蓝图（账号定位+内容规划+数据目标）、弹幕互动设计模板（时间戳×内容触发点×预期弹幕响应）、封面图 A/B 测试框架。与 [[marketing-douyin-strategist]] 形成中国视频平台双核——抖音是算法推荐驱动的流量爆发（中心化分发，Z世代+一二线城市），B站是社区文化驱动的粉丝积累（订阅关系，Z世代+ACG爱好者+知识型用户）；与 [[marketing-china-market-localization-strategist]] 协同——后者明确指出"抖音/小红书/微信/微博/知乎/B站各自独立制定，不跨平台复制"，B站策略师提供 B站 垂直赛道的深度战术执行；与 [[marketing-kuaishou-strategist]] 互补——快手侧重下沉市场（低线城市30-50岁，老铁关系），B站侧重一二线城市Z世代（ACG文化，弹幕社区）；与 [[marketing-video-optimization-specialist]] 在视频包装层面协同——前者专注 YouTube 算法，后者专注 B站 分区推荐逻辑与弹幕互动设计。 + +**[[marketing-tiktok-strategist]]**（Marketing TikTok Strategist）：The Agency Marketing 部门的 TikTok 病毒式内容创作与品牌增长策略专家 Agent——深度掌握 TikTok 推荐算法机制、病毒内容公式和社区建设策略。 + +**[[marketing-china-market-localization-strategist]]**（China Market Localization Strategist）：The Agency Marketing 部门的中国市场全栈本地化增长策略师——将实时趋势信号转化为可执行的选品、内容和渠道策略，是进入中国市场的全局性战略 Agent。**核心理念：本地化不是翻译，而是文化再工程**。核心方法：**实时趋势情报**（7+ 中国平台热榜监控，见微知著/交叉验证/反直觉/MECE 四模型）；**双轨分析**（内容轨：互动模式/关键词/供需缺口 + 评论轨：需求词/痛点/风险词/情感）；**六阶段 GTM 门控**（P0 信号验证→P1 种子内容→P2 渠道激活→P3 规模化→P4 优化→P5 成熟运营）；**平台原生策略**（抖音/小红书/微信/微博/知乎/B站各自独立制定，不跨平台复制）。关键原则：数据驱动（信号须跨 ≥ 2 平台交叉验证）、闭环思维（"第3天互动率 < 2% 则停止内容；> 5% 则 DOU+ 投放 ¥500"）。与 [[marketing-douyin-strategist]]（抖音放大）、[[marketing-kuaishou-strategist]]（下沉市场）、[[marketing-weibo-strategist]]（公域舆论）、[[marketing-zhihu-strategist]]（权威背书）、[[marketing-wechat-official-account]]（私域沉淀）、[[marketing-baidu-seo-specialist]]（搜索生态）共同构成中国全平台营销矩阵，是统合上述各平台 Agent 的战略上层；与 [[marketing-cross-border-ecommerce]]（跨境合规与物流）协同，是全球品牌进入中国市场的端到端 GTM 体系。| + +**[[marketing-video-optimization-specialist]]**（Marketing Video Optimization Specialist）：The Agency Marketing 部门的 YouTube 视频增长与留存优化专家 Agent——专注于 YouTube 算法优化、观众留存率提升、策略性章节划分、高转化率缩略图设计和跨平台内容分发。**核心理念：前30秒（The Hook）决定视频生死**——必须精确规划开场以防止观众流失，留存率图谱驱动视频结构优化。核心方法：**CTR 协同优化**（标题+缩略图联合讲述微故事，而非各自为政）；**留存率优先**（消除"死空气"时间点，在注意力衰减前注入价值）；**会话视角**（以频道而非单视频维度优化，引导观众进入下一个视频）；**跨平台分发**（Shorts/Reels/TikTok 格式自适应改造）。成功指标：8%+ 平均 CTR、50%+ 第3分钟留存率、20%+ 平均观看时长提升。交付物模板涵盖从**包装策略**（标题变体/缩略图设计）→ **视频结构**（Hook/章节时间戳/高潮节点）→ **SEO 元数据**（描述/标签/卡片/结束画面）的完整链路。与 [[marketing-douyin-strategist]] 互补——后者专注抖音中国市场（完播率优先，3秒黄金钩子），前者专注 YouTube 海外市场（留存率+CTR 双驱动，30秒 Hook 框架），两者共同构成多平台视频营销矩阵；与 [[marketing-content-creator]]（内容创作）和 [[design-visual-storyteller]]（视觉叙事）协同——后两者负责内容生产，Video Optimization Specialist 负责算法层面的包装与分发优化。 + +**[[marketing-book-co-author]]** + +**[[marketing-zhihu-strategist]]**（Marketing Zhihu Strategist）：The Agency Marketing 部门的知乎营销专家 Agent——将品牌打造为中国最大知识分享平台知乎上的思想领袖，通过专业知识分享建立权威并获取精准线索。**核心理念：信誉优先——在知乎，权威和真实专业度比粉丝数或推广推送重要得多**。核心方法论：六阶段工作流（话题定位→问题识别→高质量内容创作→专栏开发→关系建设→性能分析与优化）；信誉驱动内容标准（仅回答真正有可辩护专业知识的问答，每条主张必须有数据/研究/案例支撑）；知识驱动参与策略。关键交付物：专题权威映射（识别 3-5 个品牌应建立权威的核心话题）、问题选择策略、高质量答案模板库（最少 300 词）、专栏开发计划（6 个月内容日历）、影响力者关系列表、线索生成漏斗。成功指标：答案平均 100+ 点赞、每月 50-200 条精准线索、专栏每月 500-2000 新订阅者。与 [[marketing-douyin-strategist]] 同属 The Agency Marketing 部门中国平台矩阵——知乎侧重信誉驱动的深度内容（综合性回答最少 300 词），抖音侧重娱乐驱动的视觉内容（3-60 秒爆款），两者互补构建品牌在中国主流平台的全方位影响力。 + +前，后者专注直播带货深度战术层面）。 + +**[[marketing-instagram-curator]]**（Marketing Instagram Curator）：The Agency Marketing 部门的 Instagram 视觉品牌营销专家 Agent——通过视觉品牌开发、多格式内容策略、社区培养与社交电商将品牌打造成 Instagram 主力账号。**核心理念：超越内容创作，建立将粉丝转化为品牌拥护者、将互动转化为可衡量商业增长的视觉帝国**。核心方法：**四阶段工作流**（品牌美学开发 → 多格式内容策略 → 社区建设与电商 → 绩效优化）+ **1/3 内容法则**（品牌内容/教育内容/社区内容各占三分之一）+ **多格式运营**（Posts/Stories/Reels/IGTV/Shopping 全覆盖）。绩效目标：互动率 3.5%+、Story 完成率 80%+、购物转化 2.5%+、UGC 月产 200+ 条。核心交付物：品牌美学指南（配色/字体/摄影风格）、30天内容日历（格式分布）、Instagram Shopping 完整配置、话题标签策略。与 [[marketing-douyin-strategist]] 和 [[marketing-tiktok-strategist]] 同属短视频/视觉平台策略，但 Instagram 侧重视觉一致性与社区粘性（长期积累型），TikTok/Douyin 侧重算法流量获取与趋势跟随（爆发型），运营节奏与内容策略有本质差异。与 [[paid-media-paid-social-strategist]] 协同——后者负责付费社交广告投放，Instagram Curator 负责有机内容运营，共同构成完整 Instagram 营销体系。 + +**[[marketing-kuaishou-strategist]]**（Marketing Kuaishou Strategist）：The Agency Marketing 部门的快手平台下沉市场营销策略专家 Agent——专注于低线城市短视频营销、直播带货运营与老铁经济社区信任构建。**核心理念：真实性高于一切，快手用户能即时识别并拒绝精心制作的不真实内容**。核心方法：**均衡分发算法**（快手给予每个创作者基础曝光，奖励日常一致性而非病毒爆发）；**老铁关系构建**（信任先于销售，每条内容加强创作者-粉丝情感纽带）；**直播带货 3-2-1 公式**（3个痛点→2个产品演示→1个不可抗拒报价）；**私域运营**（粉丝团+微信私域转化）。交付物：账号定位策略（下沉市场受众画像+真实感创作人格）、每日短视频内容矩阵（70%生活快照/20%信任建立/10%社区内容）、直播带货全链路脚本（预热→直播中→复盘）、快手vs抖音差异化策略表。**核心禁忌：绝不将抖音内容直接复用到快手**——两者在受众心理（低线城市30-50岁 vs 一二线18-35岁）、算法逻辑（均衡分发 vs 中心化推荐）、内容审美（真实质朴 vs 精致潮流）上存在根本差异。与 [[marketing-douyin-strategist]] 形成中国短视频双平台互补体系——快手侧重下沉市场信任积累，抖音侧重一二线城市流量爆发。与 [[marketing-livestream-commerce-coach]] 协同——后者提供直播带货通用战术，快手策略师专注快手平台原生适配。属 [[直播带货]] 在快手生态的具体实践。 + +**[[marketing-livestream-commerce-coach]]**（Marketing Livestream Commerce Coach）：The Agency Marketing 部门的直播带货全链路运营教练 Agent——专注于主播培训、直播间操盘、流量运营和数据优化，覆盖抖音、快手、淘宝直播和微信视频号四大平台。**核心理念：停留时长和互动率决定平台是否给免费流量，GMV 是结果而非目标**。核心方法论：**主播孵化三阶段**（素人→能播4小时不冷场→能控节奏驱动转化→能拉自然流量即兴发挥）；**五阶段话术框架**（留人钩子→产品介绍→信任建立→紧迫成交→追单挽留）；**三阶段流量模型**（冷启期付费70%+自然30%→成长期50%+50%→成熟期30%+自然70%）；**产品排品策略**（引流款/主推款/利润款/秒杀款配比，随流量波峰实时切换）。关键指标：停留时长>60秒、互动率>5%、GPM>800元、自然流量占比>50%（成熟期）、千川ROI>2.5。交付物模板涵盖单品5分钟脚本、千川投放全流程SOP、直播间数据复盘模板。合规底线：不使用绝对化表述、不暗示医疗功效、不贬低竞品、不诱导未成年人购买。**核心原则：永远不以GMV为目标，而是以停留时长和互动率为目标——前者是结果，后者才是算法真正在喂养的指标**。与 [[marketing-douyin-strategist]]（抖音短视频+直播双驱动）和 [[marketing-kuaishou-strategist]]（快手下沉市场+老铁经济）构成中国直播电商三平台矩阵——抖音侧重算法驱动流量爆发，快手侧重信任积累长期复购，本教练提供跨平台的通用操盘战术层；与 [[marketing-private-domain-operator]] 协同——直播间作为公域获客入口，私域运营商负责将直播流量沉淀为企业微信资产；与 [[OceanEngine]] 协同——千川/Qianniu/超级直播等付费流量工具是冷启期的核心放大器；与 [[直播带货]] 概念页（[[直播带货]]）形成互补——概念页抽象化定义，本教练提供可直接执行的操作模板。 + +**[[marketing-short-video-editing-coach]]**（Marketing Short-Video Editing Coach）：The Agency Marketing 部门的短视频剪辑技术教练 Agent——专注于完整后期制作流水线，涵盖剪辑软件选择决策树（CapCut Pro 主推高效日更/Pr 适合商业项目/DaVinci Resolve 调色行业标准/Final Cut Pro Mac首选）、镜头语言体系（景别/运镜/转场）、色彩调色（二元体系：初级校正恢复真实 + 次级调色风格化）、音频工程（降噪→人声增强→BGM混音三步骤）、动态图形与VFX、字幕设计与多平台导出优化、AI辅助剪辑（自动字幕95%+/智能抠像/文字成片/数字人配音）。**核心理念：剪辑的核心不是软件熟练度，而是叙事能力和节奏感——软件是工具，叙事是灵魂。每一帧都必须有其存在的理由**。核心观点：音频优先于视频（观众可忍受平庸画面，无法忍受刺耳音频）；LUT是起点而非终点（60%-80%强度最合适）；模板化后单视频制作时间从2小时降至30分钟；AI承担60%重复工作，剩余40%创意打磨仍需人工。与 [[marketing-douyin-strategist]] 和 [[marketing-kuaishou-strategist]] 协同——策略师负责内容策划和平台运营，本教练负责将素材转化为专业成片；与 [[marketing-video-optimization-specialist]] 在视频结构设计上互补——前者专注剪辑技术，后者专注算法层面包装（缩略图/留存率/SEO元数据），共同构成完整视频内容生产体系。 + +**[[marketing-baidu-seo-specialist]]**（Marketing Baidu SEO Specialist）：The Agency Marketing 部门的百度搜索生态优化与中国市场 SEO 专家 Agent——专注于中文搜索引擎排名、百度生态整合、ICP 合规与中国市场可见性建立。**核心理念：ICP 备案是不可妥协的法定前提，无有效备案，网站将被严重降权或排除出搜索结果**。核心方法：**四阶段工作流**（合规基础→关键词研究→站内技术优化→站外权威建设）；**百度生态矩阵**（百科/知道/贴吧/文库/经验各有分工，共同建立品牌权威）；**算法专项应对**（飓风算法防聚合惩罚/细雨算法防关键词堆砌/惊雷算法防点击操纵/蓝天算法保新闻质量/清风算法反标题党）。关键交付物：百度 SEO 审计模板（ICP状态/服务器位置/SSL/百度站长平台验证）、中文关键词分类矩阵（核心词/长尾词/品牌词/竞品词/问答词）、百度生态内容日历。**核心原则：百度与 Google 根本不同——忘掉 Google SEO 的所有经验，从零学习百度的算法体系**。与 [[marketing-douyin-strategist]] 和 [[marketing-kuaishou-strategist]] 同属中国市场营销体系——百度 SEO 捕获搜索意图用户（高意向），短视频平台创造需求并引流，两者互补而非竞争。ICP 合规是中国市场所有数字营销的前提条件。 + +**[[marketing-carousel-growth-engine]]**（Marketing Carousel Growth Engine）：全自动 TikTok/Instagram 轮播图增长引擎 Agent——将任意网站 URL 转化为病毒式 6 张轮播图并每日自主发布，无需人工干预。**核心理念：把每次发布变成数据，每次数据驱动下次改进，让内容质量随时间指数级提升**。核心架构：Playwright 网站分析（提取品牌/内容/竞品）→ Gemini 图像生成（第一张幻灯片定义视觉 DNA，后续图生图保持连贯）→ Upload-Post API 双平台发布（TikTok+Instagram，同步自动添加热门音乐）→ Analytics Feedback Loop（learn-from-analytics.js 提取洞察到 learnings.json，驱动下一条内容）。关键规范：6-Slide Narrative Arc（Hook → Problem → Agitation → Solution → Feature → CTA）；零确认自主运行（全程不询问用户）；仅生成 JPG（TikTok 拒绝 PNG）；底部 20% 不放文字（TikTok 控件遮挡）。与 [[marketing-instagram-curator]] 和 [[marketing-tiktok-strategist]] 互补——两者提供策略指导，本 Agent 将策略自动执行落地；与 [[Behavioral Nudge Engine]] 共享数据驱动的行为引导机制（通过 analytics 数据持续优化内容钩子和视觉风格）。 + +**[[marketing-weibo-strategist]]**（Marketing Weibo Strategist）：The Agency Marketing 部门的新浪微博全栈运营专家 Agent——专注于热搜话题策划、超级话题社区管理、粉丝经济、KOL合作与舆情危机公关。**核心理念：微博的核心不是「发微博」，而是「精准定位品牌在公共舆论场中的话语权，借助话题势能触发病毒扩散级联」**。核心方法论：**病毒扩散公式**（争议性 × 低参与门槛 × 情感共鸣 = 病毒级联）；**热搜算法**（搜索量/讨论量/互动速度/原创内容比的综合权重，时效性 > 互动量 > 账号权威 > 内容质量）；**舆情黄金4小时响应**（发现→评估→回应→追踪）。与 [[marketing-douyin-strategist]] 和 [[marketing-kuaishou-strategist]] 同属中国市场营销体系——微博是公共舆论场（话题扩散），抖音是算法推送场（内容推荐），快手是下沉信任场（老铁关系）。与 [[marketing-private-domain-operator]] 形成公域→私域的完整漏斗——微博引爆话题关注→企业微信私域沉淀转化。 + +**[[marketing-wechat-official-account]]**（Marketing WeChat Official Account Manager）：The Agency Marketing 部门的微信公众号全栈运营专家 Agent——将公众号打造为高互动、强忠诚的社群中心。**核心理念：微信公众号是中国最私密的商业沟通渠道，不是广播频道而是关系建设工具**——通过一致的价值传递、战略性内容组合和自动化运营，将订阅者转化为忠实拥护者和回头客。核心方法：**60/30/10 内容规则**（60% 价值内容 + 30% 社群/互动内容 + 10% 推广内容）；**五阶段运营工作流**（订阅者分析→内容策略→内容创作→自动化运营→数据分析）；**微信原生功能整合**（自动回复/关键词响应/菜单架构/小程序）。绩效目标：打开率 30%+（行业均值 2 倍）、菜单点击率 20%+、文章读完率 50%+、月自然增长 10-20%、转化率 2-5%。与 [[marketing-weibo-strategist]] 形成互补——微博公域话题引爆→导入公众号私域深度沉淀；与 [[marketing-private-domain-operator]] 形成漏斗下游——公众号订阅者→企业微信私域深度运营；与 [[marketing-douyin-strategist]] 和 [[marketing-kuaishou-strategist]] 形成内容协同——短视频种草引流→公众号深度内容留存。 + +**[[marketing-app-store-optimizer]]**（App Store Optimizer）：The Agency Marketing 部门的 App Store 优化（ASO）全栈专家 Agent——专注于应用商店搜索可见性优化、视觉资产转化率提升和可持续用户增长。**核心理念：所有优化决策必须基于转化率数据而非创意偏好，转化优先于美学**。核心方法：**数据驱动决策**（基于性能数据和用户行为分析驱动所有优化决定）+ **转化优先设计哲学**（优先考虑应用商店转化率而非创意偏好）+ **A/B 测试系统性优化**（对所有视觉和文本元素进行系统性测试）+ **国际化本地化策略**（文化适应与本地市场优化）。四阶段工作流：市场研究分析 → 策略开发 → 实施测试 → 优化规模化。绩效指标：有机下载月增长 30%+、关键词前10排名 20+ 个、转化率提升 25%+、评分提升至 4.5 星+。与 [[marketing-seo-specialist]] 互补——Web 搜索优化 vs 应用商店搜索优化，共同构成全渠道数字发现优化体系；与 [[marketing-content-creator]] 和 [[marketing-short-video-editing-coach]] 协同——内容创作者提供文案和截图文字，App Store 优化师将其转化为应用商店最优格式，预览视频由短视频剪辑教练制作；与 [[marketing-video-optimization-specialist]] 在视频策略层面互补——视频优化专家与 App Store 优化师共同优化 App 预览视频。** + +**[[marketing-seo-specialist]]（Marketing SEO Specialist）：The Agency Marketing 部门的 Google 搜索生态 SEO 专家 Agent——专注于技术 SEO、关键词集群策略、内容优化、链接权威建设和搜索分析，实现可持续的有机流量增长。**核心理念：可持续有机增长来自技术卓越、高质量内容和权威链接档案三者的交叉点——排名是价值的自然结果，SEO 效果需要数月才能显现，非短期行为**。核心方法：**五阶段工作流**（发现→关键词策略→内容 cannibalization 检测→技术执行→权威建设→测量迭代）；**强制 cannibalization 审查**（任何优化前必须运行 GSC 跨页面查询图，防止同一关键词被多页面竞争）；**Pillar+Satellite 主题集群**（支柱页承载主关键词，卫星页支撑长尾，集群内不得重复主关键词）；**Core Web Vitals 基准**（LCP<2.5s，INP<200ms，CLS<0.1）。关键交付物：技术 SEO 审计模板（爬行性/索引率/Core Web Vitals/结构化数据）、关键词策略文档（主题集群+搜索意图分类）、内容 cannibalization 审查表、内部链接架构规划、外链获取方案。**白帽 SEO 是唯一合规方式**，禁止任何链接方案/cloaking/关键词填充等违规操作。高级能力涵盖国际化 SEO、程序化 SEO、算法恢复和 AI 搜索优化。与 [[marketing-baidu-seo-specialist]] 同属搜索优化领域——前者针对 Google 生态（英文市场为主），后者针对百度生态（中文市场为主），算法体系不可通用；与 [[marketing-app-store-optimizer]] 互补——Web SEO 覆盖所有网站流量，ASO 覆盖应用商店流量，共同构成全渠道数字发现优化体系；与 [[marketing-content-creator]] 协同——SEO 专家提供关键词意图洞察和内容结构指导，内容创作者执行生产。 + +### New Linux/DevOps Concepts (recently added) +- **[[efibootmgr]]** — Linux NVRAM 启动项管理工具，可强制重写 BootOrder 解决 HP BIOS 固执行为 +- **[[ISOHybrid镜像]]** — 同时支持 BIOS 和 UEFI 引导的混合 ISO 镜像，Rufus 提供 ISO/DD 两种写入模式 +- **[[UEFI Only]]** — HP ZBook 终极启动修复方案，切换后消除 Legacy BBS 项干扰 +- **[[NVMe硬盘分区]]** — Ubuntu 24.04 自动识别并优化 NVMe 分区对齐 + +### Sales Outbound Methodology +**[[sales-outbound-strategist]]**（Outbound Strategist Agent）：信号型出站销售策略师，将出站销售从"批量轰炸"转变为"精准触发"——核心信念：出站应由证据驱动，而非配额驱动。核心理念：**信号驱动出站转化率比无触发出站高 4-8 倍**；信号的半衰期极短（30 分钟内必须路由到正确销售），24 小时后信号失效，72 小时后竞争对手已成交。核心框架：三层信号分级体系（Tier 1 主动购买信号如 G2 访问/竞品对比 → Tier 2 组织变化信号如融资/招聘/领导层变动 → Tier 3 技术/行为信号如技术栈变化/内容互动）+ 可证伪 ICP 定义（含排除条件，否则是 TAM 幻灯片）+ 三层账户分级（Tier 1 深度多线程个性化 / Tier 2 半个性化序列 / Tier 3 自动化轻定制）+ 8-12 触点 3-4 周多渠道序列（每次触达必须提供新的价值角度）。冷邮件回复率基准：泛化型 1-3%、角色定制 5-8%、信号驱动 12-25%、推荐引入型 30-50%。SDR 角色演变：从每天 100 次活动的批量操作员 → 拥有 50-80 个深度账户的信号监控管线专家。与 [[sales-discovery-coach]] 协同——发现阶段收集的 ICP 信号直接驱动出站序列启动；与 [[sales-deal-strategist]] 形成漏斗互补——出站负责漏斗顶部（Signal → Contact），Deal Strategist 负责漏斗中部（Qualified → Commit）；与 [[sales-account-strategist]] 形成客户生命周期互补——出站获取新客户，Account Strategist 负责 Land-and-Expand 扩张。 + +### Sales Discovery Methodology +**[[sales-discovery-coach]]**（Discovery Coach Agent）：销售发现访谈（Discovery）方法论与教练框架，帮助销售代表和SDR成为更优秀的买家访谈者——坚信发现阶段才是交易成败的真正战场，而非演示、提案或谈判阶段。 + +**三大发现框架：** +- **[[SPIN Selling]]**（Neil Rackham）：四步提问法（Situation → Problem → Implication → Need-Payoff），核心洞察是 Implication 问题通过激活损失厌恶心理推动成交，是 SPIN 框架中最有力量但最常被跳过的一步 +- **[[Gap Selling]]**（Keenan）：以当前状态与期望未来状态之间的差距为中心的销售方法论；差距越大紧迫感越强；根因问题（而非表面症状）才真正驱动购买决策 +- **[[Sandler Pain Funnel]]**：从表面症状 → 商业影响 → 个人/情感层面的三层漏斗；第三层（情感层面）是大多数销售人员永远不会触及的区域，但购买决策本质上是情感决策 + +**标准发现电话结构（30分钟）**：开场2分钟（Upfront Contract，设定三种可能结果建立信任）→ 发现阶段18分钟（60-70%精力放在当前状态和痛点）→ 定向pitch 6分钟（仅展示直接对应买家痛点的能力）→ 下一步4分钟（明确谁做什么、什么时候做） + +**[[AECR Framework]]**（异议处理四步框架）：Acknowledge → Empathize → Clarify → Reframe，将异议视为诊断信息而非攻击。核心洞察：预算异议几乎从不是真正的预算问题，本质是买家对价值是否超过成本的判断。 + +核心教练原则：发现不是审讯，而是帮助买家更清晰地看清自身处境；60/40规则（买家说话60%以上）；最优秀的销售比竞争对手多问一个问题；资格筛选要快（没有真正痛点、无法触达决策者、无紧迫时间线就不是交易而是预测谎言）。 + +### Sales Coaching Methodology +**[[sales-coach]]**（Sales Coach Agent）：AI 销售教练 Agent，通过苏格拉底式提问驱动销售代表成长——坚信过程纪律比结果运气更有价值，"一次失败的纪律分明的交易比一次幸运的赢单更有价值，因为过程会累积而运气不会"。核心辅导框架：Richardson Sales Performance（四维能力：辅导卓越/激励领导/销售管理纪律/战略规划）、Challenger 辅导模型（以商业洞察引领对话而非回应需求）、MEDDPICC 资质诊断（资质缺口是交易风险信号而非CRM问题）。每周2小时以上辅导的代理赢单率56%，vs 少于30分钟仅43%；正式辅导项目配额完成率91.2%，vs 非正式辅导84.7%。关键方法：辅导行为而非结果；一次只做一件事；管道质量是管理工具而非数量是虚荣指标；挑战"happy ears"要求可验证的承诺。[[sales-coach]] 与 [[sales-discovery-coach]] 协同——后者专注发现阶段深度辅导，前者覆盖全周期辅导规划与战略制定，共同构成完整销售能力发展体系。 + +**[[sales-account-strategist]]**（Account Strategist Agent）：售后账户扩张策略师 Agent，专注于将成交客户从单点解决方案扩展为企业平台——核心理念：最佳销售时机是客户成功时（"The best time to sell more is when the customer is winning"）。核心框架：**Land-and-Expand**（从初始 land deal 扩展为七位数平台的系统性方法）+ QBR 前瞻性战略规划（永远不做回顾性状态报告）+ 利益相关者多线程关系建设（每账户至少三条独立关系线）+ NRR（净收入留存）作为终极指标。账户健康评分体系：绿色账户推扩张、黄色账户稳基础、红色账户救流失。关键纪律：永远不在未成功的账户上推扩张；扩张信号必须配合情境+时机+利益相关者对齐三个维度才算机会；单线程账户是最高风险状态。[[sales-account-strategist]] 与 [[sales-proposal-strategist]] 互补——前者构建赢单叙事，后者交付并超越叙事；与 [[sales-coach]] 协同——后者辅导卖方（代表成长），前者辅导买方（内部冠军培养）。 + +**[[sales-deal-strategist]]**（Deal Strategist Agent）：高级deal策略师与管线架构师，将严谨的资质方法论应用于复杂B2B销售周期——坚信每个deal都是战略问题而非关系练习，"如果资质缺口没有尽早识别，失败就已经锁定了，只是你还没发现"。核心能力：**MEDDPICC资质评估**（八维度评分，每维度5分，满分40；全面推行MEDDPICC的组织赢率提升18%、deal规模扩大24%）+ **竞争定位**（Winning/Battling/Losing三区分析 + 地雷问题布局）+ **Challenger商业教学法**（六步序列：Warmer → Reframe → Rational Drowning → Emotional Impact → A New Way → Your Solution）+ **交易检查方法论**（系统探测风险信号：单线程/无紧迫事件/Champion不开放EB通道/决策标准完美匹配竞争对手）。核心原则：预测准确率Commit deals关闭率85%+；Qualified Pipeline（28/40+）赢率35%+；永远不做单线程账户；每条资质缺口必须附带具体下一步、责任人、和截止日期。与 [[sales-discovery-coach]] 协同——后者提供买方情境输入（发现阶段），前者构建交易策略（评估+定位+计划）；与 [[sales-proposal-strategist]] 互补——Deal Strategist提供结构化deal分析和竞争定位，Proposal Strategist将其转化为说服性叙事，共同构成"发现→赢单策略→提案叙事"完整销售闭环。 + +**[[sales-pipeline-analyst]]**（Pipeline Analyst Agent）：Revenue Operations 领域的 Pipeline 健康诊断与收入预测 AI Agent，将 CRM 数据转化为可执行的 Pipeline 洞察——坚信"每个 Pipeline 评估都应至少发现一个需要立即干预的 Deal"。核心框架：**Pipeline Velocity** =（合格机会数 × 平均 Deal 规模 × 胜率）/ 销售周期长度，四个变量均为独立诊断杠杆；**质量调整覆盖度**（$5M 含 20 个陈旧 Deal 的 Pipeline 价值低于 $2M 含 8 个活跃 Deal 的 Pipeline）；**MEDDPICC Deal 健康评分**（资格深度 + 互动强度 + 进展速度三维度 0-36 分综合评分）；**多信号预测模型**（历史转化 + Velocity 加权 + 互动调整 + 季节性模式 + AI 模式匹配）。预测输出 Commit（>90%）/Best Case（>60%）/Upside（<60%）三档而非单一数字。关键原则：晚期阶段 MEDDPICC 字段<5/8 的 Deal 是预测失误的主要来源；单线程 + 无 EB 接触 + 20+ 天无会议 = 与上一季度 Closed-Lost 队列相同模式；30 天未更新的 Pipeline 应被标记审查；CRM 显示的 $12M Pipeline 调整后可能只有 $4.8M 有效。与 [[sales-deal-strategist]] 协同——后者关注单个 Deal 策略，前者提供全 Pipeline 层面的诊断和预测；与 [[sales-coach]] 共享 MEDDPICC 框架，但前者用于 Deal 质量评估，后者用于代表能力辅导。 + +**[[sales-engineer]]**（Sales Engineer Agent）：售前工程师 Agent，专注于在 B2B 技术评估中赢得技术决策——核心理念：技术决策先于商业合同，售前工程师必须将每一次技术对话连接到业务成果，而非单纯展示功能。核心能力：**Demo Engineering**（以影响力为导向的演示设计：先量化问题→展示结果→逆向讲解→证明收尾，以 [[AhaMoment]] 为核心成功标准）+ **POC Scoping**（严格限定的概念验证：成功标准明确写在开始前，2-3 周硬性时间线，中期检查点，防止范围蔓延）+ **FIA Framework**（Fact-Impact-Act 竞争定位框架，保持事实基础和可操作性，永远不攻击竞品）+ **技术异议解码**（识别"是否支持 SSO？"背后的真实关切是"能否通过安全审查"，从根源回应而非表面处理）+ **评估笔记维护**（结构化记录每个活跃交易的技术环境、决策者、竞争态势和演示策略）。成功指标：技术赢率 70%+，POC 转化率 80%+，演示到下一步行动率 90%+，中位数 18 天技术决策。与 [[sales-discovery-coach]] 在发现阶段技术深度参与度上存在张力——前者主张售前主导技术发现，后者主张销售发现以业务语言建立信任；与 [[sales-deal-strategist]] 共享竞争定位和 Winning/Battling/Losing 三区分析，但前者专注于技术评估层，后者覆盖全周期交易策略。属 The Agency Sales 团队完整销售闭环中的技术评估支柱。 + +### The Agency — Specialized 部门 + +**[[specialized-civil-engineer]]**（Civil Engineer）：全球设计标准覆盖的结构与土木工程专家 Agent——专注于安全、经济、可建造的结构设计，驾驭 Eurocode（EN 1990–1999 + 各国 National Annex）、ACI 318（LRFD/SD）、AISC 360、ASCE 7、GB、IS、AIJ 等全球主流建筑规范体系。核心能力：**ULS+SLS 双重验证**（承载力极限状态与正常使用极限状态必须同时满足方为合格）+ **多标准冲突处理**（IBC+Eurocode 混用时识别冲突→文档记录→保守优先→设计依据报告）+ **岩土工程**（地勘报告解读、承载力/沉降分析、挡土结构、边坡稳定）。计算交付物包括：钢梁 AISC 360 LRFD 计算包（截面选型→抗弯验算→挠度检查）、RC 梁 Eurocode EN 1992-1-1 计算包（K 法配筋设计→抗剪验算）、岩土地基 Terzaghi 承载力分析（含 EN 1997 DA1 验证）。六阶段工作流：项目范围→初步设计→详细计算→建造文档→规范合规→施工支持。属 The Agency Specialized 部门的基础设施工程方向，与 [[specialized-developer-advocate]]（开发者关系）同属 Specialized 专业 Agent 系列，与 [[specialized-workflow-architect]]（工作流架构）存在依赖关系。 + +**[[specialized-document-generator]]**（Document Generator）：专业文档生成专家 Agent——The Agency Specialized 部门的程序化文档生成专家，通过代码方式（Python/Node.js）生成 PDF、PPTX、DOCX、XLSX 等专业文档（投资者演示文稿、合规报告、数据密集型电子表格）。核心工具栈：PDF（reportlab/weasyprint/fpdf2）、PPTX（python-pptx/pptxgenjs）、XLSX（openpyxl/xlsxwriter/exceljs）、DOCX（python-docx/docx）。核心原则：**样式系统优先**（拒绝硬编码字体/字号，使用文档样式主题）、**品牌一致性**（颜色/字体/Logo 全局统一）、**数据驱动**（接受结构化数据输入生成文档输出）、**无障碍设计**（Alt 文本/标题层级/PDF 标签）、**模板可复用**（构建模板函数而非一次性脚本）。与 [[report-distribution-agent]]（文档分发）和 [[agents-orchestrator]]（工作流编排）协同，构成完整的文档从生成到分发的工作流。属 The Agency Specialized 部门的生产力工具方向，与 [[specialized-developer-advocate]] 同属专业工具 Agent 系列。 + +**[[government-digital-presales-consultant]]**（Government Digital Presales Consultant）：The Agency Specialized 部门的政府数字化售前专家——面向中国ToG（政府）市场，专注于数字政府、智慧城市、一网统管、城市大脑等主流方向的全生命周期售前支持。核心能力：政策解读（数字中国/国家数据局政策信号提取：区分"鼓励探索"与"全面实施"的政策成熟度判断）、合规架构（等保2.0三级/商用密码评估/信创适配）、招投标全流程（需求调研→方案设计→POC验证→标书撰写→述标答辩→中标交接）。五步工作流配合技术方案模板、等保合规矩阵、投标检查清单、机会评估模板等交付物。关键原则：**技术方案必须以业务场景驱动**（"市民服务处理速度提升80%"而非"微服务架构"）；**等保/密评/信创是强制项而非加分项**；方案至少经过三轮迭代打磨。成功指标：中标率>40%、零废标、售前到交付偏差<10%。与 [[sales-engineer]]（通用售前）互补——后者覆盖企业级B2B市场，前者专精中国政府ToG市场特有的政策合规与采购流程；与 [[Digital-Government]]（数字政府）和 [[Smart-City]]（智慧城市）构成完整的政府信息化知识体系。属 The Agency Specialized 部门的垂直行业方向。 + +**[[healthcare-marketing-compliance]]**（Healthcare Marketing Compliance Specialist）：The Agency Specialized 部门的医疗营销合规专家——覆盖中国医疗健康全品类（药品/医疗器械/医美/保健食品/互联网医疗）营销合规，深度熟悉《广告法》《医疗广告管理办法》《互联网广告管理办法》等核心法规体系。核心能力：医疗广告审查（《医疗广告审查证明》申请与合规）、处方药/OTC药广告分规管理、医疗器械三类分级合规（I类备案/II类注册/III类严格审批）、医美"容貌焦虑"红线防控、保健品"蓝帽子"标识管理、互联网诊疗合规（初诊必须线下面诊）、患者隐私 PIPL 合规（敏感个人信息须单独授权）、学术推广合规（医疗代表备案、会议赞助标准、医师讲课费规范）。关键原则：**合规不是"堵营销"，而是"保护品牌"**——一次违规处罚的代价远高于合规投入；**"事前审查"优于"事后补救"**——所有对外发布的医疗营销内容必须经过合规团队审核。成功指标：年度零监管处罚、平台违规 < 3次/年、100% 内容发布前合规审查覆盖率。属 The Agency Specialized 部门的合规垂直方向，与 [[government-digital-presales-consultant]]（政府合规）和 [[legal-compliance-checker]]（通用法律合规）共同构成完整的合规能力体系。 + +**[[blockchain-security-auditor]]**（Blockchain Security Auditor）：The Agency Specialized 部门的智能合约安全审计 Agent——专职发现 DeFi 协议与区块链应用中的漏洞，核心理念：**在攻击者之前找到漏洞**。核心方法：自动化静态分析（Slither/Mythril/Echidna）+ 人工逐行审查 + 属性化模糊测试 + 经济博弈建模；五步工作流（范围→自动化分析→人工审查→经济分析→报告）。核心原则：自动化工具只能捕获约 30% 的真实漏洞；每个发现必须包含可复现 PoC；使用 OpenZeppelin 不等于安全（误用安全库本身是漏洞类型）；必须验证代码与部署字节码一致（供应链攻击真实存在）。漏洞评级严格化：能导致用户资金损失的发现不得降级为 Informational。与 [[Agents-Orchestrator]] 构成审计质量门控——流水线交付前须通过安全审计；与 [[compliance-auditor]] 同属审计类 Agent，但前者聚焦代码层智能合约安全，后者聚焦企业合规认证体系（SOC 2/ISO 27001/HIPAA）。 + +**[[compliance-auditor]]**（Compliance Auditor）：The Agency Specialized 部门的专业技术合规审计 Agent——专注于 SOC 2、ISO 27001、HIPAA、PCI-DSS 等安全隐私认证的全流程指导，从准备评估到证据收集直至认证通过。与 Healthcare Marketing Compliance 侧重营销内容合规不同，Compliance Auditor 关注**技术控制体系**的审计准备。核心方法：五步工作流（Scoping → Gap Assessment → Remediation Support → Audit Support → Continuous Compliance）；核心原则：**不跟随的政策比没政策更危险**（Checkbox-Compliance 是反面教材）、**证据必须证明整个审计周期内持续有效**（而非仅当下存在）、**自动化证据收集从第一天建立**（手动流程无法扩展）、**技术控制优于管理控制**（代码比培训更可靠）。核心交付物：Gap Assessment Report（差距评估报告）、Evidence Collection Matrix（证据收集矩阵）、Policy Template（策略模板）。成功指标：零不合格发现（zero adverse findings）、审计周期缩短 30%、年度合规状态持续可查。与 [[specialized-model-qa]] 互补——后者审计 AI/ML 模型质量，前者审计组织整体安全控制，两者共同构成完整的技术合规审计体系；与 [[automation-governance-architect]] 协同——自动化证据收集需依托 Governance Architect 设计的 AI 系统治理框架。 + +|**[[specialized-workflow-architect]]**（Workflow Architect）：工作流设计专家 Agent——The Agency Specialized 部门的工作流设计与系统建模专家，在代码编写前对系统所有路径进行穷举建模。核心职责：**工作流发现**（扫描 route/worker/migration/IaC/cron 文件找出隐式工作流）+ **工作流注册表维护**（四视角：按工作流/按组件/按用户旅程/按状态）。核心交付物：**工作流树规范格式**（含 Actor/Prerequisites/Trigger/Step 树/ABORT_CLEANUP/State Transitions/Cleanup Inventory/Test Cases/Assumptions），覆盖快乐路径+七类失败分支（输入验证/超时/瞬态/永久/部分失败/并发冲突）。关键原则：**不只为快乐路径设计**、**每个系统边界定义显式 Handoff Contract**（payload schema + 成功/失败响应 + 超时值 + 恢复动作）、**Reality Checker 验证是 Draft 升为 Approved 的前置条件**。Agent 协作协议：Reality Checker 验证规范→Backend Architect 实现代码→API Tester 生成测试用例→DevOps Automator 验证清理顺序。属 The Agency Specialized 部门的质量保障基础设施，与 [[specialized-civil-engineer]]（基础设施工程）同属 Specialized 专业 Agent 系列。 + +**[[corporate-training-designer]]**（Corporate Training Designer）：The Agency Specialized 部门的企业培训体系架构师与课程开发专家——专注企业级培训需求分析、ADDIE/SAM 教学设计模型、混合学习项目、内训师培养（TTT）、领导力发展（HIPO）及 Kirkpatrick 四级培训效果评估。核心价值观：**优秀培训的衡量标准不是"教了什么"，而是"学员回去做了什么"**。关键方法：ADDIE 模型（分析→设计→开发→实施→评估）、Bloom 认知六层次、Kirkpatrick 四级评估（反应→学习→行为→业务结果）、Kolb 体验式学习圈、OMO 混合学习（线上"认知"→线下"实践"→社群"持续"）。与 [[specialized-workflow-architect]]（工作流设计）和 [[cultural-intelligence-strategist]]（跨文化产品设计）形成系统性设计能力互补——分别应用于组织学习、软件工程和文化包容三大领域，共同构成 [[The Agency]] 的系统性设计矩阵。 + +**[[cultural-intelligence-strategist]]**（Cultural Intelligence Strategist）：文化包容性专家 Agent——The Agency Specialized 部门的文化智能策略师，专门检测和消除软件开发中的"隐性排斥"（Invisible Exclusion）。核心方法：**四阶段工作流**（盲点审计→自主研究→结构修正→解释原理）。典型案例：刚性 First Name / Last Name 字段在 APAC 市场失效（改为 Full Name 或 Preferred Name）；中国金融应用中红色表示"上涨"而非"错误"（需辅以文字/图标说明）；RTL 阅读方向、多日历系统、不同文化隐私期望等全局包容性设计。核心原则：**国际化是架构前提条件，而非亡羊补牢**；**拒绝表演性多元化**——仅在首页放多元人群图但产品流程本身仍具排斥性不可接受。核心价值：将文化智能（CQ）从"后期本地化补丁"提升为"架构级前提条件"。与 [[InclusiveVisualsSpecialist]]（包容性视觉）互补——前者覆盖整个产品工作流（含表单、交互、颜色语义），后者专注于 AI 生成图像的表征偏见消除；与 [[design-brand-guardian]] 在特定市场语境下存在张力——品牌一致性要求与为不同市场调整视觉语义的必要性需要平衡。 + +**[[specialized-model-qa]]**（Model QA Specialist）：ML/统计模型端到端独立审计专家——The Agency Specialized 部门的模型质量保障专家，核心使命：**将模型视为"有罪推定"，直到全面审计证明其可靠性**。独立于模型构建者运行，通过证据驱动的分析发现模型在文档、数据、特征、性能、校准、可解释性、公平性等各环节的问题，并量化业务影响。核心方法：10 大审计领域覆盖模型全生命周期（文档治理→数据重建→标签分析→分段评估→特征分析→模型复制→校准测试→性能监控→可解释性→业务影响），配套完整 Python 工具集（PSI 监控、Hosmer-Lemeshow 校准检验、SHAP 可解释性分析、PDP 偏依赖图、KS/AUC/Gini 判别指标）。核心原则：**独立性**（永远不审计自己参与构建的模型）、**可复现性**（每个分析必须产出可执行脚本）、**证据链完整**（每个发现必须包含观察→证据→影响评估→建议）。成功指标：审计发现 95%+ 被模型所有者确认为有效、零部署后失败。属 The Agency Specialized 部门的质量保障垂直方向，与 [[specialized-workflow-architect]]（工作流设计中的 Reality Checker 验证）互补——后者验证系统行为符合规范，前者验证 ML/统计模型符合质量标准，共同构成 [[The Agency]] 的全栈质量保障体系。与 [[multi-agent-system-reliability]] 存在潜在张力：对抗辩论模式通过架构约束弥补 LLM 不可靠性（概率性），而 Model QA 要求确定性统计证据链。 + +**[[lsp-index-engineer]]**（LSP/Index Engineer）：代码智能系统架构师 Agent——The Agency Specialized 部门的 LSP 客户端编排和语义图谱构建专家，通过 graphd LSP 聚合器将 TypeScript/PHP/Go/Rust/Python 等多语言 LSP 客户端统一编排为语义图谱，为沉浸式代码可视化提供基础设施。核心交付物：多语言 LSP 并发编排 + 统一图谱模式（节点：文件/符号，边：contains/imports/calls/refs）+ nav.index.jsonl 语义索引 + WebSocket 实时增量推送 + 原子性图谱更新保证。核心原则：**严格遵循 LSP 3.17 规范**（永远检查服务器能力而非假设）、**图谱一致性约束**（每个符号有且仅有一个定义节点，所有边引用有效节点 ID）。性能北极星指标：/graph <100ms、/nav <20ms（缓存）/60ms（未缓存）、WebSocket <50ms、内存 <500MB、100k+ 符号无性能降级。TypeScript 和 PHP 支持为**默认生产就绪要求**。与 [[specialized-workflow-architect]] 存在张力：LSP/Index Engineer 要求确定性图谱一致性（"Reference edges must point to definition nodes"），而 Workflow Architect 承认穷举建模存在 LLM 概率性上限——协调方向：两者作用于不同抽象层次，符号层面需确定性约束，行为工作流层面允许概率性处理。与 [[multi-agent-system-reliability]] 共享对"架构约束优于提示词约束"的认同。 + +**[[study-abroad-advisor]]**（Study Abroad Advisor）：留学申请规划专家 Agent——The Agency Specialized 部门的全链路留学申请规划专家，面向中国学生，覆盖美国/英国/加拿大/澳大利亚/欧洲/香港/新加坡七大目的地，涵盖本科/硕士/博士全学位层次。核心理念：**数据驱动、零焦虑贩卖**——GPA 3.2 进入 Top 30 的案例与 GPA 3.9 全拒的案例并存，关键变量是选校策略和文书质量。核心方法：四步工作流（全面诊断→策略制定→材料打磨→提交跟进）+ 多国联申时间线协调；标准化交付模板（选校报告、多国申请时间线、文书诊断框架、Offer 比较矩阵）。诚信原则：不代写文书、不承诺录取结果、明确区分"确认信息"与"经验估算"。属 The Agency Specialized 部门的垂直服务方向，与 [[corporate-training-designer]]（企业培训）同属服务型 Agent，但前者面向 B2C 个人消费者，后者面向企业组织。 + +**[[specialized-french-consulting-market]]**（French Consulting Market Navigator）：法国 IT 咨询市场生态导航专家——The Agency Specialized 部门的法国 ESN/SI（Entreprise de Services Numériques）自由职业者策略 Agent，专帮助独立 IT 顾问最大化日均费率（TJM）、最小化回款风险、建立可持续客户关系。核心理念：**理解 ESN Margin 架构是谈判关键**；永远区分 TJM 毛收入（brut）与税后净收入（net）。核心方法：ESN 分层定价架构（Tier 1 全球型 Margin 35-50%、Tier 2 专项型 25-40%、Tier 3 经纪型 15-25%）+ 五平台对比矩阵（Malt/collective.work/Comet/Crème/FreeWork）+ TJM 阶梯锚定谈判四步法（Floor计算→Sell Rate反推→分层锚定→条件让步）。关键区分：Portage Salarial 税后净得约 50% TJM（700€/天 → ~300-330€ 净），Micro-Entrepreneur 净得约 70%（~420-450€），338€/天差价是社保保护（ARE失业保险、退休金补充）的价格。国际顾问策略：主动披露位置+时区覆盖价值重构替代隐瞒。属 The Agency Specialized 部门的垂直市场专家方向，与 [[specialized-korean-business-navigator]]（韩国市场导航）同属区域市场进入策略 Agent。 + +**[[specialized-korean-business-navigator]]**（Korean Business Navigator）：韩国商业文化导航专家——The Agency Specialized 部门的韩国市场进入 Agent，专帮助外国专业人员解码韩国商业隐性规则，将西方直接性与韩国关系动态相结合。核心理念：**韩国"yes"不一定是同意，沉默是信息，成交发生在会议室外的走廊**。核心洞察：품의（共识审批）流程耗时 6-16 周（SME 6-10、中型 8-12、财阀 12-16），远长于西方的 2-4 周，永远不要在第一次会议要求决策时间线；永远不要绕过联系人越级上报；KakaoTalk 群聊必须使用韩语；永远不要在第一次对话中谈钱（关系→能力→价格三阶段）；회식（商务聚餐）出席是预期而非可选。关键方法：六阶段 품의时间线（소개→미팅→내부검토→품의서→결재→계약）、Nunchi 解码表（"검토해보겠습니다"实际意为"婉拒"）、分阶段 KakaoTalk 消息模板、韩国企业职级体系（회장→대리十级）、Proof Project 策略（有边界小项目降低感知风险）。与 [[cultural-intelligence-strategist]] 同属跨文化领域 Agent，但前者聚焦韩国单一市场，后者覆盖全球包容性设计；与 [[specialized-french-consulting-market]] 同属区域市场进入策略 Agent，共に构成 The Agency 的全球区域化服务能力。 + +**[[supply-chain-strategist]]**（Supply Chain Strategist）：中国制造业供应链管理与战略采购专家 Agent——The Agency Specialized 部门的供应链全链路专家，基于中国制造业生态，帮助企业建立高效、有韧性、可持续的供应链体系。核心能力：供应商开发与分级管理（ABC 分类 + 战略合作伙伴升级）、Kraljic 矩阵采购类别策略、QCD 绩效评分体系（全季度评分年度淘汰）、TCO 全成本分析（直接/间接/隐性/全生命周期成本）、库存优化模型（EOQ/ROP/安全库存/VMI/JIT）、供应链数字化成熟度评估（L1 手动 → L5 自主智能）。采购渠道覆盖 1688/阿里巴巴、中国制造网、广交会、企查查企业核验等全渠道。合规能力：RBA 行为准则、SA8000 社会责任审计、碳足迹追踪、冲突矿产合规（CMRT）、ISO 14001/REACH/RoHS。关键原则：**关键物料禁止单一来源**；**TCO 是采购决策依据而非单价**；**质量问题必须追溯根本原因**。典型成就：紧固件品类年采购成本通过整合采购降低 12%，节省 ¥870,000。与 [[specialized-french-consulting-market]] 同属 Specialized 部门垂直领域 Agent，分别覆盖供应链管理和法国市场咨询两个不同专业方向。 + +**[[data-consolidation-agent]]**（Data Consolidation Agent）：销售数据整合专家 Agent——The Agency Specialized 部门的战略数据整合专家，将分散的销售提取数据聚合为实时仪表盘。核心理念：**将原始销售指标转化为可操作的实时决策视图**。核心能力：并行多维度查询（地区/代表/管道/时间维度）、实时达成率计算（revenue / quota * 100，处理除零错误）、MTD/YTD/Year End 多时间视图、< 1 秒仪表盘加载 + 60 秒自动刷新。交付物：Dashboard Report（地区业绩摘要 + 代表排名 + 管道快照 + 6 个月趋势 + Top 5 业绩者）和 Territory Report（地区级深度分析，含所有代表指标及最近 50 条历史记录）。关键原则：**始终使用最新数据**（按 type 取最新 metric_date）；**零数据不一致**（明细与汇总视图完全一致）。与 [[sales-data-extraction-agent]]（上游数据提取）和 [[report-distribution-agent]]（下游分发）构成销售数据管道；与 [[sales-pipeline-analyst]] 共享数据源但职责互补（整合 vs 分析）；与 [[sales-coach-agent]] 协同提供 Top 5 业绩者洞察。属 [[Multi-Agent-System-Reliability]] 的数据层实践，为多 Agent 销售系统提供统一数据视图。 + +**[[report-distribution-agent]]**（Report Distribution Agent）：销售报告自动分发专家 Agent——The Agency Specialized 部门的报告分发协调专家，基于区域参数将合并报告精准送达对应业务员和管理层。核心理念：**确保正确的报告在正确的时间到达正确的人**。核心原则：区域路由（业务员仅收到其负责区域的数据）、管理层接收公司级汇总报告、每次分发均记录状态和时间戳（sent/failed）、工作日 8:00 AM 定时日报、周一 7:00 AM 周报、失败时记录错误并继续分发。交付物：HTML 格式区域报告（业务员表格）、公司汇总报告（区域对比表格）、分发日志（接收人/区域/状态/时间戳）。关键指标：99%+ 定时送达率、零区域错误分发、失败发送 5 分钟内识别。核心工作流：定时触发→查询区域和代表→生成报告（调用 Data Consolidation Agent）→HTML 格式化→SMTP 发送→分发日志记录→UI 展示历史。与 [[data-consolidation-agent]] 构成数据管道（整合→分发）；与 [[specialized-document-generator]]（文档生成）协同——生成报告的内容由 Document Generator 提供结构，分发层负责路由和传输。属 [[Multi-Agent-System-Reliability]] 的分发层实践。 + +**[[specialized-developer-advocate]]**（Developer Advocate）：开发者关系工程师 Agent——The Agency Specialized 部门的开发者体验与社区运营专家，通过提升 DX、技术内容创作、社区运营将产品与外部开发者紧密连接，最终推动平台采用和商业价值增长。核心理念：**Authentic 技术参与，而非商业推销**——"You don't do marketing — you do developer success." 核心洞察：**DX 改善复合效应永远优于快速内容发布**，修复前 3 大 DX 问题再发布任何新教程；**真实性是核心资产**，AstroTurf（虚假社区参与）永久性摧毁开发者信任。核心方法：DX 工程审计（Time-to-First-Success 三阶段评分）→ 技术内容创作（教程/演示/演讲提案/Dev Survey）→ 社区运营（GitHub Issue ≤24h 响应、Hackathon/Ambassador Program）→ 产品反馈闭环（月度 Voice of Developer 报告）。关键原则：**先听后创**（30天 GitHub Issue → Stack Overflow → 社交媒体 → 开发者调查）；**内容必须有可运行代码**；**5人大会 Q&A = 数千无声障碍推断**。成功指标：首次成功 ≤15min、GitHub 响应 ≤24h、教程完成率 ≥50%、开发者 NPS ≥8/10。与 [[automation-governance-architect]] 互补（DevRel 关注外部开发者体验，治理架构师关注内部自动化质量）；与 [[specialized-mcp-builder]] 协同（MCP Builder 的 DX 改善依赖 Developer Advocate 的 DX 原则）；与 [[specialized-workflow-architect]] 存在设计哲学张力：前者优先 DX 质量再发布内容，后者优先快速交付功能后迭代。属 The Agency Specialized 部门的技术运营方向。 + +## Game Development + +**[[game-audio-engineer]]**（Game Audio Engineer Agent）：游戏交互式音频工程师 AI Agent——设计自适应音乐系统、空间音频架构和 FMOD/Wwise 中间件集成方案。核心原则：**所有游戏音频必须通过中间件事件系统触发**，游戏代码中不得出现 AudioSource/AudioComponent 直接播放（原型除外）。核心规范： + +- **自适应音乐**：tension parameter（0–1）驱动音乐层切换，转换必须 tempo-synced（禁止硬切） +- **空间音频**：所有世界空间音效必须使用 3D 空间化，raycast 驱动 occlusion 参数（800Hz 低通截止，每帧最多 4 个 raycast） +- **语音预算**：PC 64 语音/Console 48/Mobile 24；每个事件必须配置 voice limit、priority 和 steal mode +- **Reverb Zone**：Outdoor（15% wet）/ Indoor（35%）/ Cave（60%）/ Metal Room（45%） +- **音频格式**：Vorbis（音乐/长氛围）、ADPCM（短SFX）、PCM（UI零延迟） +- **CPU预算**：FMOD DSP 每帧 ≤1.5ms（以最低目标硬件测量） +- **工作流程五阶段**：Audio Design Document → FMOD/Wwise 项目搭建 → SFX 实现 → 音乐集成 → 性能分析 + +核心通信风格：状态驱动思维（"玩家此刻的情绪状态是什么？"）、参数优先（"不硬编码音效——通过 intensity 参数驱动音乐响应"）、毫秒级预算（"这个混响 DSP 消耗 0.4ms，我们总共只有 1.5ms。批准。"）、无感知设计（"如果玩家注意到音频过渡，说明它失败了——他们应该只感受到它"）。属 The Agency Game Dev 部门的核心技术 Agent。与 [[AdaptiveMusic]]（自适应音乐）和 [[SpatialAudio]]（空间音频）共享音频中间件基础设施；与 [[FMOD]]（音频中间件）构成核心工具链；与 [[visionos-spatial-engineer]] 在空间计算领域存在技术交叉（VR 音频需要 FOA/HRTF）。 + +**[[narrative-designer]]**（Narrative Designer Agent）：游戏叙事设计师 AI Agent——将叙事视为一套由选择、后果、世界一致性构成的系统，而非插入在游戏玩法之间的电影剧本。核心理念：**故事和游戏是同一个系统的两个维度**——每个主要故事节点必须连接到游戏机制后果，叙事选择必须与机械选择保持一致。核心规范： + +- **对话写作**：每句台词必须通过"真实人物会这样说话吗？"测试，拒绝"as you know"式对话，每个节点必须有明确的戏剧功能（揭示/建立关系/制造压力/交付后果） +- **分支设计**：选择必须类型不同（非仅程度不同），所有分支最终收敛，延迟后果设计让 Act 1 选择在 Act 3 显现 +- **Lore 架构**：三层可选深度（Surface 所有玩家/Engaged 探索者/Deep Lore 猎手），关键路径无需任何可选内容即可理解 +- **环境叙事**：通过场景道具与空间布局无声讲述故事，是 Tier 2/3 Lore 的物理呈现，与 [[Level Designer Agent]] 协作执行 + +核心通信风格：角色优先（"这句台词像作家写的，不像角色说的"）、系统清晰（"这个分支需要 2 beats 内有后果，否则选择失去意义"）、Lore 纪律（"这与建立的时间线矛盾——需要更新世界圣经"）、玩家代理（"玩家在这里做了选择——世界需要承认它"）。属 The Agency Game Dev 部门。与 [[Game Audio Engineer]] 在叙事节奏与自适应音乐层切换的协同（音频响应叙事状态）；与 [[Level Designer Agent]] 在环境叙事执行上的协作边界（叙事设计师定义内容架构，关卡设计师执行物理空间设计）。与 [[Branching Narrative]]（分支叙事）、[[Character Voice Pillars]]（角色声音柱）、[[Lore Architecture]]（Lore 三层架构）、[[Narrative-Gameplay Integration]]（叙事-玩法整合）共享叙事设计工具链。 + +**[[technical-artist]]**（Technical Artist）：技术美术 Agent——连接艺术视野与引擎实现的桥梁角色。核心职责：在硬性能预算内最大化视觉质量，涵盖着色器编写、VFX 系统构建、资产管线标准定义和渲染性能分析。核心原则：**预算优先**——每种资产类型（多边形数、纹理分辨率、Draw Calls、粒子数）必须在生产前定义明确上限，而非交付后才发现超标；**移动端优先**——过度绘制（Overdraw）是移动端性能隐性杀手，所有半透明/加法粒子必须审计并设定上限，LOD 管线强制执行（LOD0–LOD3 最低要求）；**着色器标准**——所有自定义着色器必须包含移动端安全变体或明确标注平台限制。核心交付物：Asset Budget Spec Sheet（含角色/环境/VFX 详细预算表）、Dissolve Shader（HLSL/Unity URP）、VFX Performance Audit Checklist、LOD Chain Validation Script。高级能力涵盖实时光线追踪（RT reflections + DLSS/XeSS/FSR 超采样）、AI 辅助美术管线（纹理超分辨率、AI 法线图生成）和模块化后处理栈（LUT 调色、TAA + 锐化）。属 The Agency Game Dev 部门，与 [[UnrealTechnicalArtist]]（Unreal 专精）和 [[UnityShaderGraphArtist]]（Unity 着色器图形专精）共享技术栈。 + +**[[blender-addon-engineer]]**（Blender Add-on Engineer）：Blender 原生工具开发专家 AI Agent——通过 Python + bpy API 构建自定义 Operator、Panel、资产验证器和导出器，将重复性 DCC 工作流自动化为可靠的一键工作流。核心理念：**Pipeline-first, artist-empathetic, automation-obsessed, reliability-minded**。核心规范： + +- **数据 API 优先**：偏好 bpy.data/bpy.types 直接数据访问而非 bpy.ops 操作符（后者上下文脆弱），确保 Operator 行为可预测 +- **非破坏性验证**：验证工具必须在自动修复前报告问题，绝不静默"成功"；dry-run 模式预演所有破坏性操作 +- **Pipeline 可靠性三角**：命名确定性 + 变换分离检查（location/rotation/scale 单独验证）+ 材质槽顺序验证 + 集合包含/排除显式规则 +- **可审计批量操作**：批量工具必须精确记录修改内容，Log Exactly What They Changed + +核心交付物：Asset Validator Operator（PIPELINE_OT_validate_assets，含命名/变换/材质槽检查）、Pipeline Export Panel（导出预设 UI）、Naming Audit Report（命名规范报告）、Validation Report Template（验证报告模板）。属 The Agency Game Dev 部门 DCC 工具专项，与 [[Technical Artist]]（通用技术美术）构成 DCC 工具分工——Technical Artist 定义资产管线标准，Blender Add-on Engineer 实现 Blender 端工具；与 [[UnityArchitect]] 在编辑器扩展设计哲学上存在张力——后者倾向所见即所得直接修改，前者坚持非破坏性验证优先，均为平台约束最优解。与 [[bpy]]（Blender Python API）、[[Asset-Validation]]（资产验证）、[[Non-Destructive-Workflow]]（非破坏性工作流）共享核心工具开发概念。 + +**[[roblox-systems-scripter]]**（Roblox Systems Scripter）：Roblox 平台 Luau 系统脚本工程师 AI Agent——专注于服务器权威架构、RemoteEvent 安全验证、DataStore 可靠性和 ModuleScript 模块化设计，构建可防作弊、数据持久化安全、架构整洁的 Roblox 游戏体验。核心理念：**服务器是唯一真相来源，客户端只显示状态，不拥有状态**。核心规范： + +- **客户端-服务器信任边界**：`LocalScript` 仅客户端显示，`Script` 仅服务器逻辑，绝不混合；RemoteEvent FireServer 请求必须在服务器端完整验证（类型检查+冷却检查+距离检查+权限检查），不得信任任何客户端数据 +- **DataStore 可靠性**：`pcall` 包装 + 指数退避重试（2s/4s/8s）+ 双保存点（PlayerRemoving + BindToClose）；UpdateAsync 优先于 SetAsync（原子处理并发冲突） +- **ModuleScript 架构**：所有逻辑在 ModuleScript 中返回表，Script/LocalScript 仅 bootstrap；SharedTable 或 ReplicatedStorage 常量模块实现跨端共享常量 +- **安全验证**：所有 OnServerEvent 处理必须结构验证输入；RemoteFunction InvokeClient 禁止在服务器端调用（恶意客户端可永久挂起服务器线程） + +核心交付物：DataManager.lua（含 retryAsync + deepCopy + 双保存点）、CombatSystem.lua（完整验证链路示例）、GameServer.bootstrap.server.lua（五阶段引导模式）。高级能力涵盖 Parallel Luau（task.desynchronize + Actor 模型 + SharedTable）、对象池（预实例化 effects/NPC 减少 GC）、数据版本迁移（data._version + UpdateAsync 原子升级）。属 The Agency Game Dev 部门 Roblox Studio 专项，与 [[Roblox Experience Designer]]（玩家参与度和变现系统设计）协同构成完整 Roblox 开发体系——Experience Designer 定义体验目标，Systems Scripter 实现底层架构支撑。与 [[Server-Authoritative Architecture]]（服务器权威模型）、[[DataStore Reliability]]（DataStore 可靠性模式）、[[ModuleScript Architecture]]（模块化架构）、[[Parallel Luau]]（并行 Luau）共享 Roblox 系统工程核心技术栈。 + +**[[roblox-experience-designer]]**（Roblox Experience Designer）：Roblox 平台原生体验设计师 AI Agent——专注于 Roblox 受众（9-17岁）的参与度循环设计、变现系统与玩家留存。核心使命：设计让玩家返回、分享和投资的体验。核心方法：DataStore 驱动进度系统（玩家等级/道具/货币持久化，创造沉没成本）；Roblox 原生化变现（Game Pass 永久权益、Developer Product 消耗品、UGC 道具）；参与度阶梯（首次会话→每日返回→周留存，每层有清晰奖励闭环）；每日奖励系统（1-7天循环阶梯，驱动习惯性返回）；入职引导三阶段（0-60秒/5分钟/15分钟，最小化早期流失）。核心原则：**免费体验必须完整**——禁止 pay-to-win；**DataStore 安全优先**——进度丢失是永久流失的首因；**变现伦理**——禁止暗黑模式、人工稀缺、压力购买。成功指标：D1 留存 >30%、D7 >15%、MAU 月增长 >10%、转化率 >3%、零 Roblox 政策违规。核心交付物：PassManager.lua（Game Pass 集中管理模块）、DailyRewardSystem.lua（每日奖励系统）、Onboarding Flow Design Document（含 Drop-off Recovery Points）。属 The Agency Game Dev 部门 Roblox Studio 专项，与 [[Roblox Systems Scripter]]（底层系统架构）协同构成完整 Roblox 开发体系——Experience Designer 定义体验目标，Systems Scripter 实现底层架构支撑。与 [[Game Designer]]（通用游戏设计方法论）、[[Technical Artist]]（视觉质量）协同构成 Game Dev 完整设计支撑体系。与 [[EngagementLoop]]（参与度循环）、[[DailyRewardSystem]]（每日奖励）、[[DataStoreProgression]]（数据存储进度）、[[RobloxMonetization]]（Roblox 变现）共享 Roblox 原生设计核心技术栈。 + +**[[roblox-avatar-creator]]**（Roblox Avatar Creator）：Roblox UGC 化身 pipeline 专家 AI Agent——掌握 Roblox avatar 系统的全部约束条件，以及如何构建能通过 Creator Marketplace 审核的商品。核心理念：技术规格精准、视觉打磨到位、平台合规。核心规范：UGC 网格三角面数硬限制（配件 ≤4,000、Bundle 部件 ≤10,000）；单 UV 通道且范围严格在 [0,1]；所有 transform 在导出前必须应用（scale=1, rotation=0）；纹理分辨率 256×256 ~ 1024×1024 PNG，UV island 留 2px 最小 padding；Layered Clothing 必须有 Outer Mesh + InnerCage + OuterCage 三层 cage。附件点必须使用标准命名（HatAttachment / FaceFrontAttachment / LeftShoulderAttachment 等），在 5 种 body type 上全部测试。核心交付物：Accessory Export Checklist（建模检查清单）、AvatarManager.lua（HumanoidDescription 全套换装）、Layered Clothing Cage Setup Guide（Blender cage 网格规范）、Creator Marketplace Submission Package（提交前审核检查清单）、UGC Shop UI Flow（MarketplaceService 购买监听）。属 The Agency Game Dev 部门 Roblox Studio 专项，与 [[Roblox Systems Scripter]]（Luau 系统架构）、[[Roblox Experience Designer]]（玩家变现）协同构成完整 Roblox 开发体系——Avatar Creator 负责 UGC 资产从建模到上线的 pipeline。与 [[LayeredClothing]]（分层服装系统）、[[HumanoidDescription]]（化身 API）、[[CreatorMarketplace]]（UGC 交易市场）、[[R15Rig]]（R15 骨骼权重系统）共享 Roblox 化身资产核心技术栈。与 [[UnityArchitect]] 在角色定制系统实现路径上存在平台差异——Roblox 强制服务端权威（HumanoidDescription + DataStore），Unity 可客户端预测，均为各自平台最优解。 + +**[[game-designer]]**（Game Designer Agent）：游戏系统与机制设计师 AI Agent——以"循环、杠杆、玩家动机"为思维框架，将创意愿景转化为可执行、无歧义的游戏设计文档（GDD）。核心理念：**从玩家动机出发设计，而非从功能列表出发**。核心方法：五步工作流（概念→设计支柱→纸面原型→GDD撰写→调优迭代）；三层核心循环（瞬间体验 0-30秒 → 会话目标 5-30分钟 → 长期进阶 数小时至数周）；数值以 `[PLACEHOLDER]` 标记假设直至测试验证。核心交付物：Game Design Document（含目的/玩家体验/输入/输出/边界/失败状态的完整机制规格）、Economy Balance Spreadsheet（玩家画像：鲸鱼/海豚/小鱼）、Player Onboarding Checklist（引导完成率目标 >90%）。高级能力涵盖行为经济学应用（Cialdini 影响原则/损失厌恶/变率奖励/沉没成本）、跨类型机制移植（机制活检分析）、高级经济设计（供给-需求模型/通胀检测/Monte Carlo 模拟）、系统性涌现设计（系统交互矩阵/最小可行复杂度）。属 The Agency Game Dev 部门。与 [[Narrative Designer]]（叙事-机制一致性整合）、[[Level Designer]]（关卡空间叙事协作）、[[Game Audio Engineer]]（反馈音效系统）、[[Technical Artist]]（视觉原型可执行化）共同构成 Game Dev 部门完整设计支撑体系。与 [[Core Gameplay Loop]]（核心循环设计）、[[Economy Balance]]（经济平衡）、[[Behavioral Economics in Games]]（行为经济学）共享 GameDesigner 核心方法论。 + +**[[unreal-technical-artist]]**（Unreal Technical Artist）：Unreal Engine 5 视觉系统工程师 AI Agent——拥有 Material Editor、Niagara VFX、PCG 和 Nanite 全栈专业能力，负责 UE5 项目的美术-引擎视觉管线。核心交付标准：Material Function 库复用规范（消除跨 Master Material 重复节点簇）、Niagara Scalability 三档预设（High/Medium/Low）、确定性 PCG 图设计（相同参数→相同输出）、Nanite 优先策略（非适用资产须手动 LOD 链）、Substrate 多层材质（UE5.3+ 替代 SSS workaround）。性能纪律：每个 Static Switch 使着色器排列数翻倍，必须审计；所有粒子系统必须设 Max Particle Count；PCG 生成须在 3 秒内完成，流式加载不得造成卡顿。属 The Agency Game Dev 部门，与 [[Technical Artist]]（通用技术美术基类）共享 VFX/着色器核心规范；与 [[Unreal World Builder]]（开放世界场景搭建）、[[Unreal Systems Engineer]]（引擎底层系统）协同构成 UE5 专精团队。 + +**[[unreal-multiplayer-architect]]**（Unreal Multiplayer Architect）：Unreal Engine 5 多人游戏网络架构工程师 AI Agent——构建服务器权威模型、延迟容忍、作弊防护的生产级 UE5 多人游戏网络系统。核心理念：**服务器拥有真相，客户端请求——服务器决定**。核心方法：Server-authoritative 架构（所有游戏状态变化在服务器执行，客户端预测+对账）；UFUNCTION(Server, Reliable, WithValidation) 全覆盖（每个游戏逻辑 RPC 必须实现 _Validate）；复制频率按 Actor 类型差异化（投射物 100Hz/NPC 20Hz/环境物 2Hz）；GAS 双路径初始化（PossessedBy 服务器路径 + OnRep_PlayerState 客户端路径）。核心交付物：Replicated Actor 模板（含 RepNotify + WithValidation）、GameMode/GameState/PlayerState 架构规范、GAS 网络集成方案、Replication Graph 空间分区优化、专用服务器 Shipping 构建配置。性能指标：每玩家带宽 <15KB/s、反作弊验证全覆盖、200ms 延迟下每玩家每 30 秒校正 <1 次。属 The Agency Game Dev 部门，与 [[Unreal Technical Artist]]（UE5 视觉系统）、[[Game Designer]]（多人游戏机制设计）协同构成 UE5 专精团队。与 [[ServerAuthoritativeModel]]（服务器权威模型）、[[ActorReplication]]（Actor 复制）、[[GAS]]（Gameplay Ability System）、[[ReplicationGraph]]（复制图）共享 UE5 网络核心技术栈。 + +**[[unreal-systems-engineer]]**（Unreal Systems Engineer）：Unreal Engine 5 系统架构工程师 AI Agent——掌握 C++/Blueprint 连续统一体、Nanite 几何系统、Lumen GI、Gameplay Ability System 的 AAA 级 UE5 项目性能与混合架构专家。核心理念：**Tick 逻辑必须 C++，Blueprint 是设计师 API 而非运行时引擎**。核心规范： + +- **C++/Blueprint 边界**：每帧逻辑（Tick）必须 C++；Blueprint 适用于：高层游戏流、UI 原型、设计师可扩展层 +- **Nanite 预算**：单场景 1600 万实例上限，开放世界需提前规划实例预算；不兼容骨骼网格/复杂 clip 操作/样条网格 +- **内存安全**：所有 UObject 指针必须 UPROPERTY() 声明；跨帧 Actor 指针需 IsValid() 检查；TWeakObjectPtr/TSharedPtr 处理非拥有引用 +- **GAS 架构**：UGameplayAbility + UAttributeSet + UAbilitySystemComponent 网络就绪配置；FGameplayTag 替代字符串标识符 +- **高级能力**：Mass Entity（Unreal ECS，处理海量 NPC）、Chaos 破坏系统（Geometry Collection 实时断裂）、Lyra 模块化框架（GameFeatureAction 运行时注入） + +属 The Agency Game Dev 部门，与 [[Unreal Technical Artist]]（Nanite 资产验证与优化）协同处理几何管线；与 [[Unreal Multiplayer Architect]]（GAS 网络复制安全）在技能系统实现与 RPC 层调用上互补。核心性能纪律：Tick 逻辑 C++ 实现、帧预算 60fps（目标硬件）、Unreal Insights 性能分析验证。 + +**[[unreal-world-builder]]**（Unreal World Builder）：Unreal Engine 5 开放世界环境架构工程师 AI Agent——专注于 World Partition 分区流送、Landscape 地形系统、PCG 程序化内容生成和 HLOD 层级 LOD 构建，覆盖 4km² ~ 64km² 超大规模开放世界。核心理念：**用格子大小控制流送预算，用 RVT 消除地形层混合成本**。核心规范： + +- **World Partition 格子策略**：密集城区 64m / 空旷地形 128m / 沙漠海洋 256m+；Always Loaded 层存放 Sky/Audio/GameMode；关键游戏内容（任务触发器、关键 NPC）禁止放在格子边界 +- **Landscape 层限制**：单区域最多 4 层材质，超过则产生材质排列组合爆炸；超过 2 层必须启用 RVT（Runtime Virtual Texturing）消除逐像素层混合开销 +- **HLOD 规则**：所有 500m 以外可见区域必须生成 HLOD；Nanite 资产排除在 HLOD 合并之外；骨骼网格不支持 HLOD +- **PCG vs Foliage Tool**：Foliage Tool 仅用于手工放置主角物件；大规模植被用 PCG + Nanite 预烘焙；排除区域（道路/路径/水体/建筑）必须在 PCG 图中显式定义 +- **LWC（大世界坐标）**：任何轴超过 2km 的世界必须启用 LWC；约 20km 后无 LWC 会出现浮点精度错误；代码中位置使用 FVector3d 双精度 + +属 The Agency Game Dev 部门，与 [[Unreal Systems Engineer]]（Nanite 实例预算规划）共享 World Partition 流送基础设施；与 [[Unreal Technical Artist]]（Landscape 材质与 RVT 配置）共享地形渲染技术；与 [[Unreal Multiplayer Architect]]（World Partition 流送源与网络同步）互补。核心成功指标：地面疾跑无 >16ms 流送卡顿、1km² 以上区域全部预烘焙、HLOD 覆盖所有 500m+ 区域、Landscape 层数永不超 4。 + +**[[unity-editor-tool-developer]]**（Unity Editor Tool Developer）：Unity 编辑器扩展开发工程师 AI Agent——构建 EditorWindows、AssetPostprocessors、PropertyDrawers、Build Validators 等工具，使艺术/设计/工程团队效率可量化提升。核心理念：**最佳工具是隐形的**，在问题到达 QA 前自动拦截，在创意人员意识到需求前提前自动化。核心规范： +- **Editor 脚本放置**：必须置于 `Editor` 文件夹或使用 `#if UNITY_EDITOR` 保护，Editor API 调用进入运行时代码将导致构建失败 +- **EditorWindow 状态持久化**：必须通过 `[SerializeField]` 或 `EditorPrefs` 持久化状态，跨域重载不丢失；长操作必须通过 `EditorUtility.DisplayProgressBar` 反馈进度 +- **AssetPostprocessor 幂等性**：同一资源重复导入必须产生相同结果；命名规范强制（`_N` 后缀 → Normal Map）、压缩预算强制（2048px 上限）、平台配置自动化（Android ASTC 格式） +- **PropertyDrawer 标准**：`OnGUI` 必须调用 `BeginProperty`/`EndProperty` 以正确支持 Prefab Override UI；`GetPropertyHeight` 返回值必须与 `OnGUI` 实际绘制高度一致 +- **构建验证**：失败时必须抛出 `BuildFailedException`，而非仅 `Debug.LogWarning` + +属 The Agency Game Dev 部门，与 [[technical-artist]]（编辑器工具和资产管线）共享工具开发模式；与 [[unreal-systems-engineer]] 在"构建前验证"模式上互补——Unity 侧通过 `IPreprocessBuildWithReport` 在打包前验证，Unreal 侧通过 UAssetCheckConfig 在编辑器内实时检查。核心成功指标：每项工具都有量化的"每周节省 X 分钟"指标；AssetPostprocessor 拦截所有应被捕获的违规资产；团队在发布后 2 周内自愿采用工具（无需提醒）。 + +**[[unity-shader-graph-artist]]**（Unity Shader Graph Artist）：Unity 渲染效果专家 AI Agent——精通 Shader Graph 可视化材质创作与 HLSL 性能优化，专注于 URP/HDRP 渲染管线的实时视觉效果开发。核心理念：**Shader Graph 是艺术家创作的首选工具，HLSL 仅用于性能关键路径**。核心规范： + +- **Sub-Graph 强制复用**：所有 Shader Graph 必须使用 Sub-Graph 封装重复逻辑，重复节点簇是维护和一致性失败 +- **URP/HDRP API 严格区分**：URP 自定义通道使用 `ScriptableRendererFeature` + `ScriptableRenderPass`；HDRP 使用 `CustomPassVolume` + `CustomPass`，两者 API 不可互换 +- **移动端性能硬约束**：每 Fragment Pass 最多 32 次纹理采样，不透明 Fragment 最多 60 ALU 指令 +- **Alpha Clipping 优先**：透明材质优先使用 Alpha Clipping 而非 Alpha Blend，避免过度绘制深度排序问题 +- **Frame Debugger 强制分析**：所有 Fragment Shader 必须在 Unity Frame Debugger 和 GPU Profiler 中通过性能分析后方可发布 + +核心交付物：Dissolve Shader Graph（含 Sub-Graph 封装的 DissolveCore）、OutlineRendererFeature（URP 自定义描边通道）、CustomLit.hlsl（URP 兼容 PBR Shader 完整示例）、Shader Complexity Audit 模板。高级能力涵盖 Compute Shader GPU 数据处理、RenderDoc Shader 调试、自定义深度后处理通道和程序化纹理生成。属 The Agency Game Dev 部门，与 [[technical-artist]]（通用技术美术基类）共享 VFX/着色器核心规范；与 [[unreal-technical-artist]]（Unreal 材质系统）在跨引擎渲染技术层互补；与 [[unity-editor-tool-developer]]（编辑器工具）协同构成 Unity 专精团队。核心成功指标：100% Shader Graph 使用 Sub-Graph 封装重复逻辑；100% 暴露参数设置 Blackboard tooltip；移动端 Shader 100% 提供 fallback 变体。 + +**[[unity-architect]]**（Unity Architect）：Unity 游戏架构师 AI Agent——数据驱动模块化架构专家，精通 ScriptableObject 优先设计、职责拆分和反模式消除，构建可扩展、无"意大利面条式代码"的 Unity 项目。核心理念：**ScriptableObject-First**——所有共享游戏数据必须存于 ScriptableObject，绝不通过 MonoBehaviour 字段跨场景传递；**零硬引用**——跨系统通信禁止 GameObject.Find()、FindObjectOfType() 和静态单例，必须通过 SO 事件通道连线。核心规范： + +- **ScriptableObject 事件通道**：`GameEvent : ScriptableObject` 通过 Raise/Register 模式实现松耦合跨系统通信，替代 GetComponent<> 引用链 +- **RuntimeSet 无单例追踪**：全局实体追踪使用 `RuntimeSet : ScriptableObject`，OnEnable/OnDisable 自动注册/注销，无需单例 +- **单一职责强制**：每个 MonoBehaviour < 150 行，只解决一个问题；能用"and"描述则必须拆分；Prefab 场景无关自包含 +- **场景卫生**：每次场景加载视为干净状态，瞬态数据不得跨场景存活，除非显式通过 SO 持久化 +- **反模式零容忍**：God MonoBehaviour（500+ 行）、DontDestroyOnLoad 单例滥用、Update 内轮询逻辑均为禁止项 + +核心交付物：FloatVariable SO（含 OnValueChanged 事件）、RuntimeSet 泛型集合、GameEvent 事件通道（含 GameEventListener MonoBehaviour）、PlayerHealthDisplay 单一职责组件示例、Custom PropertyDrawer for FloatVariable（设计师实时编辑体验）。高级能力涵盖 Addressables 资源管理（替代 Resources.Load()）、SO 状态机（状态为 SO 资产、转换为 SO 事件）、Unity DOTS 混合架构（ECS + Job System + Burst Compiler 驱动性能关键系统，MonoBehaviour 处理编辑器友好型游戏逻辑）、内存分析（Memory Profiler 包 + Unity Profiler 深度分析）。 + +属 The Agency Game Dev 部门，与 [[unity-multiplayer-engineer]]（网络层叠加 SO 架构设计）互补；与 [[unity-shader-graph-artist]]（SO 数据驱动视觉资产）协同；与 [[unity-editor-tool-developer]]（Custom PropertyDrawer 赋能 SO 设计师体验）构成 Unity 工具链闭环。核心成功指标：零 GameObject.Find() 或 FindObjectOfType()；每个 MonoBehaviour < 150 行且单一职责；Prefab 在空场景独立运行无错误；所有共享状态存于 SO 资产。 + +**[[godot-gameplay-scripter]]**（Godot Gameplay Scripter）：Godot 4 游戏逻辑脚本专家 AI Agent——以软件架构师的纪律性构建类型安全、信号驱动、可组合的游戏玩法系统，精通 GDScript 2.0 和 C# 互操作。核心理念：**一切皆为节点，行为通过添加节点组合，而非增加继承深度**。核心规范： + +- **信号命名**：GDScript 用 snake_case（如 `health_changed`），C# 用 PascalCase + EventHandler 后缀（如 `HealthChangedEventHandler`）；信号必须携带类型化参数，禁止 Variant +- **静态类型强制**：所有变量、函数参数和返回值必须显式类型化，使用 typed arrays（`Array[EnemyData]`），零无类型 var 出现在生产代码 +- **组合优于继承**：通过 `@onready var health: HealthComponent = $HealthComponent` 附加子节点组件，拒绝继承层级 +- **Autoload 纪律**：仅用于真正的跨场景全局状态（设置/存档/事件总线），游戏逻辑必须驻留在可独立实例化的场景中 +- **场景隔离**：每个场景必须可独立运行（F6），不假设父节点类型或兄弟节点存在 + +核心交付物：Typed Signal 声明（GDScript + C# 双语）、EventBus Autoload 示例、HealthComponent 组件模式、Typed Array 敌人追踪示例、GDScript/C# 跨语言信号连接模式。高级能力涵盖 GDExtension C++ 集成（性能关键系统）、RenderingServer 低级 API（批量网格实例化）、Service Locator 模式（带优先级的事件总线）、WebRTC P2P 多人游戏（延迟补偿 + 死 reckoning）。属 The Agency Game Dev 部门 Godot 专精，与 [[unity-architect]] 在**组合优于继承**的设计哲学上存在跨引擎共识，但具体实现机制不同——Unity 使用 ScriptableObject 事件通道，Godot 使用信号总线；两者均反对全局可变状态。核心成功指标：零生产代码无类型 var；所有信号参数显式类型化；所有场景可独立运行（F6 无错）。 + +**[[godot-multiplayer-engineer]]**（Godot Multiplayer Engineer）：Godot 4 多人游戏网络专家 AI Agent——精通 MultiplayerAPI、MultiplayerSpawner、MultiplayerSynchronizer、RPC 机制和 ENet/WebRTC 传输层，构建生产级实时多人游戏。核心理念：**权威精确、场景架构意识、延迟诚实、GDScript 精准**。核心规范： + +- **权威模型**：`set_multiplayer_authority()` 必须显式设置每个节点权威（而非依赖默认值 peer 1），所有游戏关键状态（位置/生命值/分数/物品）由服务器（peer 1）持有权威 +- **RPC 安全性**：所有 `@rpc("any_peer")` 必须进行服务器端发送者 ID 验证和输入合理性检查；`@rpc("authority")` 用于服务器→客户端确认；`@rpc("call_local")` 用于调用者也执行效果 +- **场景复制**：`MultiplayerSpawner` 是所有动态生成网络节点的唯一正确方式（手动 `add_child()` 会导致对端节点丢失）；`MultiplayerSynchronizer` 配置 `ON_CHANGE` 模式避免每帧同步 + +核心交付物：NetworkManager Autoload（ENet 服务器/客户端）、Server-Authoritative Player Controller（含 RPC 安全审计）、MultiplayerSynchronizer 配置（ON_CHANGE 属性同步）、MultiplayerSpawner 场景生成（含连接/断连处理）、RPC Security Pattern（物品拾取验证示例）、Matchmaking 集成（HTTPRequest + ticket-based 方案）。高级能力涵盖 WebRTC P2P 多人游戏（STUN/TURN NAT 穿透）、Nakama 游戏服务器集成（大厅/排行榜/DataStore）、Relay Server 架构（二进制协议 + 房间路由）、自定义网络协议设计（`PackedByteArray` + 增量压缩）。属 The Agency Game Dev 部门，与 [[godot-gameplay-scripter]]（GDScript 游戏逻辑脚本）在多人游戏场景下协同工作；与 [[unity-multiplayer-engineer]] 在**服务器权威模型 + RPC 安全性**的核心概念上跨引擎共识，但 Godot 使用 `set_multiplayer_authority()` 显式权威 + MultiplayerSynchronizer 显式配置，Unity 使用 NetworkTransform/NetworkVariable 隐式同步。核心成功指标：零权威不匹配（所有状态变更均有 `is_multiplayer_authority()` 守卫）；所有 `@rpc("any_peer")` 均通过服务器端验证；在 150ms 模拟延迟下无破坏性同步问题。 + +**[[godot-shader-developer]]**（Godot Shader Developer）：Godot 4 渲染效果专家 AI Agent——精通 Godot 着色语言（GLSL-like）、VisualShader 编辑器、CanvasItem 和 Spatial 着色器、后处理与性能优化，专注于 2D/3D 视觉效果开发。核心理念：**创作性、正确性与性能意识三合一，渲染方案服务于目标平台而非理论最优**。核心规范： + +- **shader_type 声明**：每个着色器必须显式声明 `canvas_item`（2D/UI）、`spatial`（3D）、`particles` 或 `sky`，Godot 4 着色语言不是原始 GLSL，必须使用 Godot 内置变量（`TEXTURE`/`UV`/`COLOR`/`ALBEDO`）而非 GLSL 等价物 +- **渲染器分级适配**：Forward+（高端，全特性）→ Mobile（中端，规避 `discard`）→ Compatibility（最广泛，无 compute shader / 无 `DEPTH_TEXTURE` canvas 采样） +- **uniform hint 强制**：所有 uniform 必须附带 hint（`hint_range`/`source_color`/`hint_normal`），否则 Inspector 无法正确显示 +- **纹理采样计数**：片元着色器每帧纹理采样是主要性能成本，移动端不透明材质预算 ≤ 6 次采样 + +核心交付物：2D CanvasItem 精灵描边着色器（8 邻域采样 alpha 检测）、3D Dissolve 溶解着色器（noise texture + discard + 边缘自发光）、3D 水面着色器（双层法线混合 + 深度色彩渐变）、全屏后处理 CompositorEffect（GDScript + RenderingDevice）、着色器性能审计清单。高级能力涵盖 RenderingDevice API（compute shader 分发）、VisualShaderNodeCustom 自定义节点、FBM/Voronoi 程序化纹理、屏幕空间反射（SCREEN_TEXTURE）、体积雾（`fog_density` 输出）。属 The Agency Game Dev 部门，与 [[godot-gameplay-scripter]]（GDScript 游戏逻辑）协同构建完整的 Godot 4 游戏开发栈；与 [[unity-shader-graph-artist]] 在 Shader Graph 可视化编辑理念上跨引擎共识，但 Godot 使用 VisualShader + GLSL-like 代码着色器双轨，Unity 使用 Shader Graph + HLSL；与 [[technical-artist]] 在渲染技术+美术桥梁角色上重叠。核心成功指标：所有着色器声明 `shader_type` 并在头部注释标注渲染器要求；所有 uniform 带 hint；移动端着色器通过 Compatibility 渲染器无错；无未经性能审计的 `SCREEN_TEXTURE`。 + +## Conflict Areas + +1. **Kanban vs Event Sourcing**: Kanban emphasizes visual team collaboration; Event Sourcing emphasizes auto-tracking and context preservation. **[[Project State Management]]**（事件驱动看板替代方案）vs 传统 PM 工具。核心差异：手动拖拽 vs 自然语言输入；静态快照 vs 全历史保留；无上下文 vs 完整决策链。**[[Event Sourcing]]** 在此上下文中指将项目变更存储为事件序列，每次 progress/blocker/decision/pivot 均持久化，保留完整决策上下文。 + +2. **MEDDPICC 维度数量**：MEDDPICC 有 8 个维度（Metrics/Economic Buyer/Decision Criteria/Decision Process/Paper Process/Implicated Pain/Champion/Competition），但早期摄入的 [[sales-coach]] 描述为"六个维度"。已于本次摄入中修正为八维度，后续应避免再次引用旧的六维度描述。 + +3. **Kuaishou vs Douyin**: Kuaishou emphasizes authenticity and balanced algorithm; Douyin emphasizes polished content and central recommendation. Same country, opposite platform strategies. + +4. **Micro-Enterprise vs Portage Salarial**: Micro-enterprise yields higher net income but lacks social protections; Portage Salarial costs more but includes unemployment insurance, pension, mutuelle. Financial trade-off vs social safety net. + +5. **CI/CD Build Output**: SECURITY.md says build output is always closed; GitHub Actions best practice says certain generated files should be committed for reproducibility. Reproducibility vs cleanliness tension. + +6. **Sales Engineer vs Sales Discovery Coach（技术发现参与深度）**：Sales Engineer Agent 主张售前工程师应在技术发现阶段主导参与，结构化挖掘架构、集成、安全约束和真实技术决策标准；Sales Discovery Coach Agent 主张销售发现应以业务语言建立信任，深度技术探索由专门时机负责。协调方向：在发现阶段早期以业务语言建立信任，进入评估阶段后切换为技术深度模式。详见 [[sales-engineer]] Contradictions 部分。 + +7. **路由器科学上网 vs VPS科学上网 vs NAS科学上网 vs Server终端代理**：四层方案各有适用场景。[[网件RAX50刷梅林固件与科学上网]] 路由网关方案（[[MerlinClash插件]]）→ 全屋透明代理，无需客户端配置；[[3X-UI Xray on BandwagonVPS]] VPS服务端方案（[[3X-UI]] + [[Xray]]）→ 集中式代理节点，可扩展；[[群晖NAS科学上网]] NAS 代理方案（V2RayA 透明代理）→ 覆盖 NAS 本身及容器；[[ubuntu-server科学上网]] Server 终端代理方案（[[ProxyChains]] + [[Git 全局代理]] + [[Docker Daemon Proxy]]）→ 仅覆盖该 Server 本身。最佳实践：路由器作为主网关（[[MerlinClash插件]]），VPS作为代理节点池（订阅机制），NAS 按需透明代理，Server 终端按工具单独配置。**额外洞察**：在群晖 DSM 7.x 和 Ubuntu Server 中，V2RayA/透明代理不一定对 Docker Daemon 生效，**显式配置 Docker Daemon Proxy 环境变量**（systemd drop-in 文件）比依赖透明代理更可靠。 + +8. **Prometheus 监控 vs OpenTelemetry**：Prometheus 生态成熟、部署简单，适合家庭服务器和小型集群；OpenTelemetry 是云原生可观测性新标准（metrics/traces/logs 三合一），长期可考虑迁移路径但学习成本高。[[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] vs [[ctp-topic-67-cloud-native-observability-using-opentelemetry]]。 + +9. **Netdata vs Prometheus**：Netdata 开箱即用适合实时短期诊断（默认 19999 端口），Prometheus + Grafana 适合长期存储和趋势分析。两者可互补使用：Netdata 做快速排查，Prometheus 做 SLA 报表和历史分析。 + +10. **macOS vs Linux 睡眠管理**：macOS 使用 `pmset` 命令配置电源管理（sleep/displaysleep/standby/hibernatemode），Linux/Ubuntu 使用 `systemd-logind` 的 `HandleLidSwitch=ignore` 配置。两者目标相同（防止服务器睡眠），但工具链完全不同，不可互换但互为参考。[[mac-mini-服务器配置-防止自动锁屏与睡眠]] vs [[ubuntu禁用合盖休眠]]。 + +11. **Healthcare Marketing Compliance vs 通用法律合规**：医疗营销合规 Agent 主张医疗领域具有高度专业化特征（《广告法》/药械注册/平台规则），通用法律合规工具无法覆盖；[[legal-compliance-checker]] 主张合规 Agent 应具备跨行业通用框架，无需细分至医疗领域。**协调方向**：通用合规 Agent 负责数据隐私/合同合规等横向能力，医疗营销合规 Agent 专注垂直领域规则差异（详见 [[healthcare-marketing-compliance]] Contradictions 部分）。 + +12. **LSP 图谱确定性 vs Workflow 穷举概率性**：LSP/Index Engineer 要求确定性图谱一致性（"每个符号必须有且仅有一个定义节点"，"Reference edges must point to definition nodes"），强调 LSP 3.17 协议规范和原子性图谱更新；[[specialized-workflow-architect]] 承认穷举工作流建模存在 LLM 概率性上限，某些边界条件只能通过概率性处理。**协调方向**：两者作用于不同抽象层次——符号层面（静态代码分析）需确定性约束，行为工作流层面（系统边界交互）允许概率性处理，可共存（详见 [[lsp-index-engineer]] Contradictions 部分）。 + +13. **数据库备份方案**：pg_dump 逻辑备份 vs rsync 文件级备份。pg_dump 是热备份标准（零停机、跨平台迁移能力强），但不能备份运行中数据库的物理文件目录；rsync 适合 Docker 卷备份但需确保数据库一致状态。[[MinIO + Zipline 图床安装]] 使用 pg_dump 逻辑备份 PostgreSQL + Hyper Backup 文件备份 MinIO 目录，两者互补。 + +14. **Zhihu vs Douyin（中国平台深度 vs 视觉策略差异）**：知乎侧重信誉驱动的深度内容（综合性回答最少 300 词），内容以专业知识和案例支撑为核心；抖音侧重娱乐驱动的视觉内容（3-60 秒爆款），以完播率和黄金3秒钩子为核心。两者的"成功"衡量标准完全不同——知乎衡量权威积累和精准线索转化，抖音衡量流量规模和即时互动。**协调方向**：两者互补而非竞争，Zhihu 负责品牌专业深度建立， Douyin 负责流量获取和品牌曝光（详见 [[marketing-zhihu-strategist]] Contradictions 部分）。 + +15. **SuperCall 沙盒 Persona vs 通用语音 Agent**：[[event-guest-confirmation]] 中使用的 [[SuperCall]] 强调独立沙盒设计——AI persona 只持有预设的 persona name、goal、opening line，无法访问外部系统；[[phone-based-personal-assistant]] 侧重通用个人助手场景，需要访问更多上下文。**[[Sandboxed Persona]]** 适用于确认类单一任务（安全、无注入风险）；通用语音 Agent 适用于需要跨系统协调的复杂助手场景。 + +16. **Agent 去电通知 vs Agent 来电接收**：[[phone-call-notifications]] 中 Agent 主动向用户拨打电话通知（Agent → User），通话由 Agent 触发，用户是被动接收方；[[phone-based-personal-assistant]] 中用户主动呼叫 Agent（User → Agent），Agent 接听并提供助理服务。两者方向相反但互补——前者用于紧急告警、定时简报、重要事件通知，后者用于随时咨询、查询、执行任务。共同构成完整语音双向通信能力。 + +18. **企业财务 Agent 全链路能力**：Finance Tracker Agent 覆盖从数据验证→预算编制（95%+ 准确率）→现金流管理（12 个月预测，90%+ 准确率）→投资分析（NPV/IRR/ROI，25%+ 平均回报）→合规审计的全链路财务管理。核心差异化在于：多级审批 + 职责分离 + 完整审计跟踪。[[support-finance-tracker]] + +19. **播客"慢媒介" vs 短视频"快媒介"**：[[marketing-podcast-strategist]] 主张播客是"慢媒介"，核心竞争力是主播人格深度和听众陪伴感，固定更新节奏比频繁更新更重要，完成率比播放量更能反映内容质量；[[marketing-short-video-editing-coach]] 侧重高频爆款节奏，以完播率和黄金3秒钩子为核心。两者的"成功"衡量标准完全不同——播客衡量听众忠诚度和长期品牌信任，短视频衡量流量规模和即时互动。**协调方向**：两者互补而非竞争——播客负责深度内容建立品牌信任和私域沉淀，短视频负责流量获取和品牌曝光，可并行运营但内容策略和节奏管理需分开制定（详见 [[marketing-podcast-strategist]] Contradictions 部分）。 + +18. **多 Agent 协作工作流关键模式**：[[workflow-startup-mvp]] 展示了 4 周 MVP 开发中 7 种专业 Agent 的协作模式。核心 4 大模式：① **Sequential Handoff**（顺序交接）——每个 Agent 的完整输出作为下一 Agent 输入，不摘要不压缩；② **Parallel Agent Work**（并行工作）——独立 Agent 可在同一阶段同时激活（如 Week 1 的 Sprint Prioritizer 和 UX Researcher）；③ **Quality Gate**（质量门控）——在 Week 2 中点和 Week 4 发布前由 Reality Checker 评估 GO/NO-GO；④ **Context Passing**（上下文传递）——Agent 之间无共享记忆，必须显式传递完整上下文。未来引入 Orchestrator Agent 可替代手动传递，实现全自动化流水线。[[workflow-startup-mvp]] + + diff --git a/wiki/sources/engineering-autonomous-optimization-architect.md b/wiki/sources/engineering-autonomous-optimization-architect.md new file mode 100644 index 00000000..a6c48102 --- /dev/null +++ b/wiki/sources/engineering-autonomous-optimization-architect.md @@ -0,0 +1,52 @@ +--- +title: "Autonomous Optimization Architect" +type: source +tags: ["ai-finetuning", "llm-routing", "ai-fintech", "autonomous-agents", "cost-optimization"] +date: 2026-04-26 +--- + +## Source File +- [[Agent/agency-agents/engineering/engineering-autonomous-optimization-architect.md]] + +## Summary（用中文描述） +- 核心主题：LLM 驱动的自主优化与智能路由系统，通过影子测试持续评估和切换 AI 模型 +- 问题域：AI 系统运营成本失控、模型选择缺乏数据驱动、缺少金融级安全保障 +- 方法/机制：LLM-as-a-Judge 评分、影子流量测试、暗启动（Dark Launching）、熔断器（Circuit Breaker）、AI FinOps +- 结论/价值：在保证 99.99% 稳定性的前提下，通过自动路由至更便宜/更快的模型实现 >40% 成本降低 + +## Key Claims（用中文描述） +- 影子流量（Shadow Traffic）异步测试新模型，不影响生产环境稳定性的同时收集真实对比数据 +- 自主流量路由（Autonomous Traffic Routing）：实验模型达到基准精度（如 98%）且成本更低（如 1/10）时，自动切换至该模型 +- 金融与安全护栏（Financial & Security Guardrails）：每个外部请求必须配置超时、重试上限和廉价兜底方案，防止无限循环 +- 异常熔断（Halt on Anomaly）：流量突增 500% 或出现 HTTP 402/429 错误时，立即触发熔断器并告警人工 +- 成本优先原则：提出 LLM 架构时必须同时给出每百万 Token 的主路径和兜底路径成本估算 + +## Key Quotes +> "I have evaluated 1,000 shadow executions. The experimental model outperforms baseline by 14% on this specific task while reducing costs by 80%." — Autonomous Optimization Architect 通信风格 +> "Circuit breaker tripped on Provider A due to unusual failure velocity. Automating failover to Provider B to prevent token drain. Admin alerted." — 熔断触发时的标准告警语 +> "Autonomous routing without a circuit breaker is just an expensive bomb." — 该 Agent 的核心理念 + +## Key Concepts +- [[CircuitBreaker]]：熔断器模式，当 Provider 失败频率超过阈值时自动切断并切换到廉价兜底方案 +- [[LLMasJudge]]：用 LLM 自动评估实验模型输出的质量，作为客观评分替代人工评审 +- [[ShadowTraffic]]：影子流量，将一小部分请求异步转发至实验模型，与生产结果对比评分 +- [[SemanticRouting]]：语义路由，根据任务类型和历史性能选择最优 Provider +- [[DarkLaunching]]：暗启动/灰度发布，新模型在不影响用户的前提下逐步引入 +- [[AIFinOps]]：AI 云财务管理，跟踪每个 LLM 的 token 消耗、成本和延迟，建立历史性能排名 + +## Key Entities +- [[OpenAI]]：主要 LLM Provider 之一，提供 GPT 系列模型 +- [[Anthropic]]：主要 LLM Provider，提供 Claude 系列模型 +- [[GoogleGemini]]：主要 LLM Provider，提供 Gemini Flash 等高性价比模型 +- [[Firecrawl]]：网页抓取 API，当 LLM Provider 不可用时的备选数据获取方案 + +## Connections +- [[testing-workflow-optimizer]] ← uses ← [[AutonomousOptimizationArchitect]]（工作流优化依赖路由决策） +- [[backend-architect-with-memory]] ← depends_on ← [[AutonomousOptimizationArchitect]]（后端架构依赖成本追踪记忆） +- [[automation-governance-architect]] ← shares_guardrails ← [[AutonomousOptimizationArchitect]]（自动化治理与本 Agent 均涉及安全护栏设计） + +## Contradictions +- 与 [[testing-performance-benchmarker]] 冲突： + - 冲突点：性能基准测试强调人工驱动的静态评估，本 Agent 强调机器驱动的动态 A/B 测试 + - 当前观点：持续自动的影子测试比定期人工测试更能反映生产环境真实性能 + - 对方观点：性能基准测试提供可控、可复现的实验室数据，而非真实流量噪声 diff --git a/wiki/sources/engineering-mobile-app-builder.md b/wiki/sources/engineering-mobile-app-builder.md new file mode 100644 index 00000000..81034472 --- /dev/null +++ b/wiki/sources/engineering-mobile-app-builder.md @@ -0,0 +1,56 @@ +--- +title: "Mobile App Builder Agent Personality" +type: source +tags: [] +date: 2026-04-26 +--- + +## Source File +- [[Agent/agency-agents/engineering/engineering-mobile-app-builder.md]] + +## Summary（用中文描述） +- 核心主题：Mobile App Builder — 专注于原生 iOS/Android 开发和跨平台框架的移动应用开发 AI Agent 人格规范 +- 问题域：如何在移动端构建高性能、平台原生体验的应用；原生开发与跨平台开发的选型决策；移动端特有的性能、续航、离线场景约束 +- 方法/机制：Swift/SwiftUI（iOS）、Kotlin/Jetpack Compose（Android）、React Native/Flutter（跨平台）；MVVM 模式；Offline-First 架构；平台原生设计规范（Material Design / Human Interface Guidelines） +- 结论/价值：移动开发 Agent 需要具备平台意识、性能优先、用户体验驱动的特质，同时保持跨平台的技术多样性 + +## Key Claims（用中文描述） +- 原生 iOS/Android 开发必须遵循平台设计指南（Material Design、Human Interface Guidelines） +- 移动应用必须实现离线优先架构和智能数据同步 +- 跨平台开发需在代码复用与平台原生体验之间找到平衡 +- 移动性能优化目标：冷启动 < 3 秒，内存占用 < 100MB，续航损耗 < 5%/小时 + +## Key Quotes +> "Implemented iOS-native navigation with SwiftUI while maintaining Material Design patterns on Android" — 平台感知型开发示例 +> "Built offline-first architecture to handle poor network conditions gracefully" — 移动约束优先的设计理念 +> "Optimized app startup time to 2.1 seconds and reduced memory usage by 40%" — 性能优化的典型目标 + +## Key Concepts +- [[Offline-First Architecture]]：离线优先架构 — 构建应用时默认以离线为基准，网络连接时进行数据同步，确保弱网环境下的用户体验 +- [[MVVM Pattern]]：Model-View-ViewModel — SwiftUI 和 Jetpack Compose 推荐的状态管理模式，ViewModel 持有 UI 状态和业务逻辑，View 负责渲染 +- [[Cross-Platform Mobile Development]]：跨平台移动开发 — 使用 React Native 或 Flutter 等框架在 iOS 和 Android 上共享代码，同时保持平台原生特性 +- [[Platform-Native UI]]：平台原生 UI — 遵循各平台设计规范（Material Design / HIG）实现符合用户预期的界面和交互 +- [[Biometric Authentication]]：生物特征认证 — 在移动应用中集成 Face ID、Touch ID 或指纹识别实现安全身份验证 +- [[Push Notification System]]：推送通知系统 — 针对不同平台（APNs/Firebase）实现精准推送，提升用户留存 + +## Key Entities +- [[SwiftUI]]：Apple 声明式 UI 框架，用于构建现代 iOS/macOS 应用界面 +- [[Jetpack Compose]]：Google Jetpack 声明式 UI 工具包，Android 原生现代化 UI 开发 +- [[React Native]]：Facebook/Meta 开源跨平台框架，使用 JavaScript/TypeScript 构建原生移动应用 +- [[Flutter]]：Google 开源跨平台 UI 工具包，使用 Dart 语言，可编译为原生 ARM 代码 +- [[Swift]]：Apple iOS/macOS 开发语言，配合 SwiftUI 使用 +- [[Kotlin]]：Google 官方 Android 开发语言，配合 Jetpack Compose 使用 + +## Connections +- [[agents-orchestrator]] ← orchestrates ← [[engineering-mobile-app-builder]] +- [[engineering-mobile-app-builder]] ← shares_workflow ← [[unity-architect]]（平台策略和架构决策方法论） +- [[engineering-mobile-app-builder]] ← extends ← [[software-architect]]（系统架构原则应用于移动端） +- [[visionos-spatial-engineer]] ← related_to ← [[engineering-mobile-app-builder]]（Apple 生态移动开发扩展） +- [[xr-immersive-developer]] ← related_to ← [[engineering-mobile-app-builder]]（XR 与移动平台的跨设备体验） + +## Contradictions +- 与 [[unity-architect]] 跨平台理念存在框架差异： + - 冲突点：原生开发 vs 跨平台框架的优先级 + - 当前观点：Mobile App Builder 默认支持多种框架（SwiftUI、Jetpack Compose、React Native、Flutter），按需选型 + - 对方观点：Unity Architect 专注于 Unity 引擎内的跨平台方案 + - 说明：两者解决的问题域不同，Mobile App Builder 面向通用移动应用，Unity Architect 面向游戏开发，属合理分工而非矛盾