Auto-sync: 2026-04-21 17:12
This commit is contained in:
@@ -1,38 +0,0 @@
|
||||
---
|
||||
title: "2D-First Spatial-Second"
|
||||
type: concept
|
||||
tags: [product-strategy, spatial-computing, ux]
|
||||
date: 2026-03-05
|
||||
---
|
||||
|
||||
## Definition
|
||||
2D 优先、空间其次是一种产品策略，先构建优秀的 2D web dashboard，再渐进式添加空间能力。
|
||||
|
||||
## Rationale
|
||||
1. **分发覆盖**：WebXR 浏览器覆盖远超 VisionOS
|
||||
2. **市场验证**：Vision Pro 装机量不足以支撑独立业务
|
||||
3. **产品成熟度**：先确保核心 2D 产品价值成立
|
||||
4. **风险缓解**：避免"spatial solution in search of a problem"
|
||||
|
||||
## Phase Implementation
|
||||
- **Phase 1 (Months 1-6)**：2D web dashboard + Three.js 2.5D
|
||||
- **Phase 2 (Months 6-12)**：可选 WebXR 空间模式
|
||||
- **Phase 3 (Months 12-18)**：Native VisionOS（仅在验证后）
|
||||
|
||||
## Cross-Agent Consensus
|
||||
8 个专业 Agent 独立得出相同结论：
|
||||
- Product Trend Researcher：Vision Pro 数据不支持首发
|
||||
- Backend Architect：2D 先构建完整功能
|
||||
- Brand Guardian：接受"2D first, spatial in every demo"原则
|
||||
|
||||
## Key Quote
|
||||
> "If 2D is clearer, use 2D. Every review should ask: 'Would this be better flat?'" — UX Researcher
|
||||
|
||||
## Related Concepts
|
||||
- [[Progressive Disclosure]]：用户体验方法论
|
||||
- [[Spatial AI Operations]]：最终目标
|
||||
- [[WebXR]]：分发平台
|
||||
|
||||
## Related Entities
|
||||
- [[Nexus Spatial]]：实施产品
|
||||
- [[Vision Pro]]：最终平台（验证后）
|
||||
@@ -1,19 +0,0 @@
|
||||
---
|
||||
title: "360 度反馈"
|
||||
type: concept
|
||||
tags: [feedback, leadership-assessment]
|
||||
sources: []
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
从上级、同事、下级、客户等多个维度收集反馈，生成个人领导力档案和发展建议。
|
||||
|
||||
## Feedback Dimensions
|
||||
上级评价、同级评价、下级评价、客户评价（如适用）
|
||||
|
||||
## Privacy Rules
|
||||
结果仅与本人及其直接上级分享，不作为惩罚依据。
|
||||
|
||||
## Related Concepts
|
||||
- [[HIPO 计划]]：人才识别与发展
|
||||
@@ -1,18 +0,0 @@
|
||||
---
|
||||
id: 3x-ui
|
||||
title: 3X-UI
|
||||
type: concept
|
||||
tags: [proxy, panel, xray]
|
||||
sources: []
|
||||
last_updated: 2026-04-16
|
||||
---
|
||||
|
||||
## Summary
|
||||
- 定义：Xray 可视化管理面板，提供 Web 界面管理 Xray 代理服务
|
||||
- 作用：简化 Xray 配置和运维，支持一键安装、流量统计、节点管理
|
||||
|
||||
## Key Facts
|
||||
- 基于 GitHub 项目 mhsanaei/3x-ui
|
||||
- 支持命令行和 Web 界面管理
|
||||
- 支持 SSL 证书自动申请
|
||||
- 支持防火墙管理、BBR 加速等功能
|
||||
@@ -1,25 +0,0 @@
|
||||
---
|
||||
title: "90/10 Rule"
|
||||
type: concept
|
||||
tags: [reddit, marketing, community-building, engagement]
|
||||
sources: []
|
||||
last_updated: 2026-04-21
|
||||
---
|
||||
|
||||
## Summary
|
||||
Reddit 社区营销的核心原则：90% 价值内容，10% promotional content。
|
||||
|
||||
## Definition
|
||||
在 Reddit 社区参与中，90% 的内容应该是真正帮助社区成员的价值贡献，只有 10% 可以是与品牌推广相关的内容。
|
||||
|
||||
## Key Claims
|
||||
- 90/10 法则确保社区信任建立
|
||||
- 价值优先原则避免被社区视为 spam
|
||||
- 长期关系建设比短期推广更有效
|
||||
|
||||
## Related Concepts
|
||||
- [[Community Integration]]：通过持续价值贡献成为社区可信成员
|
||||
- [[Educational Content Leadership]]：通过教育内容建立思想领导力
|
||||
|
||||
## Examples
|
||||
- [[Marketing Reddit Community Builder]] 遵循此原则实现authentic community engagement
|
||||
@@ -1,22 +0,0 @@
|
||||
---
|
||||
title: "A/B Testing"
|
||||
type: concept
|
||||
tags: [experimentation, testing, statistics]
|
||||
sources: [project-management-experiment-tracker]
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
A/B Testing is a controlled experiment that compares a control variant against one or more treatments to measure causal impact on a target metric.
|
||||
|
||||
## Core Principles
|
||||
- Randomly assign users to variants
|
||||
- Change one meaningful variable at a time when possible
|
||||
- Predefine primary and guardrail metrics
|
||||
- Run long enough to reach adequate sample size
|
||||
- Analyze results with statistical rigor
|
||||
|
||||
## Related Entities
|
||||
- [[Experiment Tracker]]
|
||||
- [[Senior Project Manager]]
|
||||
|
||||
@@ -1,28 +0,0 @@
|
||||
---
|
||||
title: "ABC 分类法"
|
||||
type: concept
|
||||
tags: [supply-chain, supplier-management]
|
||||
---
|
||||
|
||||
## Definition
|
||||
ABC 分类法是一种供应商分级管理策略，根据供应商的战略重要性和采购金额将供应商分为不同等级，实施差异化管理策略。
|
||||
|
||||
## 分类标准
|
||||
|
||||
| 类型 | 采购金额占比 | 管理策略 |
|
||||
|------|--------------|----------|
|
||||
| **战略供应商** (Strategic) | Top 10-20% | 深度合作、联合开发、战略联盟 |
|
||||
| **杠杆供应商** (Leverage) | 20-30% | 竞争性管理、总量平衡 |
|
||||
| **瓶颈供应商** (Bottleneck) | 10-20% | 寻找替代源、保持库存 |
|
||||
| **常规供应商** (Routine) | 30-40% | 简化流程、自动化采购 |
|
||||
|
||||
## 与 Kraljic Matrix 的关系
|
||||
- ABC 分类法侧重**供应商层面**的分级管理
|
||||
- Kraljic Matrix 侧重**采购品类层面**的策略制定
|
||||
- 两者常配合使用：Kraljic 分类确定品类策略，ABC 分类确定供应商关系深度
|
||||
|
||||
## Connections
|
||||
- [[Supply Chain Strategist]] ← uses ← [[ABC 分类法]]
|
||||
- [[Kraljic Matrix]] — ABC 分类与 Kraljic Matrix 配合制定采购策略
|
||||
- [[供应商绩效考核]] — 绩效考核结果用于 ABC 分级调整
|
||||
|
||||
@@ -1,26 +0,0 @@
|
||||
---
|
||||
title: ACOS (Advertising Cost of Sales)
|
||||
type: concept
|
||||
tags: [advertising, ecommerce, metrics, amazon, ppc]
|
||||
aliases: [TACOS, Total Advertising Cost of Sales]
|
||||
---
|
||||
|
||||
## Definition
|
||||
广告成本销售比，衡量广告支出与产生的销售额之间的比率，是跨境电商最核心的广告效率指标。
|
||||
|
||||
## Formula
|
||||
```
|
||||
ACOS = (广告支出 / 广告产生的销售额) × 100%
|
||||
TACOS = (广告支出 / 总销售额) × 100%
|
||||
```
|
||||
|
||||
## Benchmark Values
|
||||
- 跨境电商目标：ACOS 20-25%
|
||||
- 成熟阶段目标：TACOS < 10%
|
||||
- 超出毛利率的广告活动必须优化或关闭
|
||||
|
||||
## Usage Context
|
||||
Amazon PPC 广告优化中，ACOS 是核心 KPI。Launch 阶段可接受较高 ACOS 以获取数据，Growth 阶段控制在 25% 以下，Mature 阶段追求低 ACOS 高利润。
|
||||
|
||||
## Connections
|
||||
- [[Marketing Cross-Border E-Commerce Specialist]] ← uses ← [[ACOS (Advertising Cost of Sales)]] ← measures
|
||||
@@ -1,22 +0,0 @@
|
||||
---
|
||||
title: "ADDIE 模型"
|
||||
type: concept
|
||||
tags: [instructional-design, training-methodology]
|
||||
sources: []
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
系统化课程设计流程，五个阶段依次为：Analysis（分析）→ Design（设计）→ Development（开发）→ Implementation（实施）→ Evaluation（评估），每个阶段有明确交付物。
|
||||
|
||||
## Core Phases
|
||||
- **Analysis**：组织诊断、需求研究、能力差距分析
|
||||
- **Design**：学习目标定义、课程大纲设计、评估策略制定
|
||||
- **Development**：课程内容开发、教材制作、试讲迭代
|
||||
- **Implementation**：培训交付、学习平台配置、讲师与学员准备
|
||||
- **Evaluation**：效果评估、数据收集、持续优化
|
||||
|
||||
## Related Concepts
|
||||
- [[SAM 模型]]：快速迭代版本
|
||||
- [[Bloom's Taxonomy]]：学习目标设计工具
|
||||
- [[Kirkpatrick 四级评估模型]]：评估框架
|
||||
@@ -1,34 +0,0 @@
|
||||
---
|
||||
title: "ADOT (AWS Distro for OpenTelemetry)"
|
||||
type: concept
|
||||
tags:
|
||||
- OpenTelemetry
|
||||
- AWS
|
||||
- ADOT
|
||||
date: 2024-04-02
|
||||
---
|
||||
|
||||
## Definition
|
||||
ADOT（AWS Distro for OpenTelemetry）是 AWS 提供的 OpenTelemetry 发行版，作为统一代理用于收集 Traces、Metrics、Logs，并自动检测应用语言创建预配置的 OpenTelemetry Collector。
|
||||
|
||||
## Key Features
|
||||
- **统一代理**：单一 Agent 收集所有类型遥测数据
|
||||
- **自动检测**：自动识别应用编程语言并配置 instrumentation
|
||||
- **AWS 集成**：原生支持 CloudWatch、X-Ray、OpenSearch、Prometheus 等 AWS 服务
|
||||
- **Operator 支持**：通过 Kubernetes Operator 自动管理 Collector 部署
|
||||
|
||||
## Capabilities
|
||||
- 自动 instrumentation（自动埋点）
|
||||
- 自定义属性添加（如租户 ID）
|
||||
- 日志支持（Fluent Bit 集成）
|
||||
- 无服务器指标抓取（Amazon Managed Prometheus）
|
||||
|
||||
## Related Components
|
||||
- [[OpenTelemetry]]：上游开源项目
|
||||
- [[OpenTelemetry-Collector]]：ADOT 基于 Collector 构建
|
||||
- [[EKS]]：主要部署平台
|
||||
- [[Amazon-OpenSearch-Service]]：数据存储后端
|
||||
|
||||
## References
|
||||
- AWS re:Invent 演示：EKS 上使用 Fluent Bit 收集日志，转发至 OpenTelemetry Collector 端点（端口 55681）
|
||||
- 支持 11 种语言 SDK
|
||||
@@ -1,42 +0,0 @@
|
||||
---
|
||||
title: "AECR Framework"
|
||||
type: concept
|
||||
tags: [sales, objection-handling, methodology]
|
||||
---
|
||||
|
||||
## 定义
|
||||
销售异议处理框架，包含四个步骤：Acknowledge（认可）、Empathize（共情）、Clarify（澄清）、Reframe（重构）。
|
||||
|
||||
## 四步处理流程
|
||||
|
||||
### 1. Acknowledge（认可）
|
||||
- 目的：验证担忧但不争论
|
||||
- 示例："这是个合理的担忧。我经常听到这样的说法。"
|
||||
|
||||
### 2. Empathize（共情）
|
||||
- 目的：展示理解买家为何这样感觉
|
||||
- 示例："可以理解——如果我坐在你的位置，之前也吃过[类似方案]的亏，我也会持怀疑态度。"
|
||||
|
||||
### 3. Clarify（澄清）
|
||||
- 目的：提问理解表面异议背后的真实异议
|
||||
- 示例：
|
||||
- "您能帮我了解一下您对[话题]的具体担忧是什么？"
|
||||
- "您说时机不对，是预算周期问题、带宽问题，还是其他原因？"
|
||||
|
||||
### 4. Reframe（重构）
|
||||
- 目的：基于所了解的信息提供新视角
|
||||
- 示例："我听到的是[真实担忧]。以下是您这种情况的其他团队是如何考虑的..."
|
||||
|
||||
## 常见异议分布
|
||||
| 类别 | 频率 | 真实含义 |
|
||||
|------|------|----------|
|
||||
| 预算/价值 | 48% | "我不相信 ROI 证明成本合理"或"我不控制预算" |
|
||||
| 时机 | 32% | "这不是当前的优先事项"或"我太忙了，无法接受另一个项目" |
|
||||
| 竞争 | 20% | "我需要证明为什么不选[替代方案]"或"我拿你做比价" |
|
||||
|
||||
## 关键洞察
|
||||
- 异议是诊断信息，不是攻击
|
||||
- 预算异议几乎从来不是关于预算，而是关于价值是否超过成本
|
||||
|
||||
## 关联实体
|
||||
- [[Sales Discovery Coach]]
|
||||
@@ -1,28 +0,0 @@
|
||||
---
|
||||
title: "AI ChatOps"
|
||||
type: concept
|
||||
tags: [ChatOps, AI, collaboration]
|
||||
sources: [How-Agentic-AI-can-help-for-Cloud-DevOps]
|
||||
last_updated: 2026-04-16
|
||||
---
|
||||
|
||||
## Summary
|
||||
AI ChatOps 是将 AI 能力集成到协作平台（如 Slack、Teams）中，实现通过自然语言进行故障排除和运维操作的工作方式。
|
||||
|
||||
## Definition
|
||||
通过聊天界面与 AI 代理交互，查询日志、获取性能洞察、执行故障排除操作的工作模式。
|
||||
|
||||
## Key Platforms
|
||||
- [[Slack]]
|
||||
- [[Teams]]
|
||||
- CLI 终端
|
||||
|
||||
## Key Capabilities
|
||||
- **自然语言查询**：用自然语言查询日志和指标
|
||||
- **AI 驱动洞察**：获取 AI 分析的问题原因
|
||||
- **自动化操作**：通过聊天触发自动化修复
|
||||
- **上下文保持**：AI 记住对话上下文，支持多轮对话
|
||||
|
||||
## Connections
|
||||
- [[Agentic AI]] ← powers ← [[AI ChatOps]]：Agentic AI 驱动 ChatOps 交互
|
||||
- [[监控可观测性]] ← enhanced_by ← [[AI ChatOps]]：AI ChatOps 增强可观测性
|
||||
@@ -1,28 +0,0 @@
|
||||
---
|
||||
title: "AI-driven RCA"
|
||||
type: concept
|
||||
tags: [AI, root-cause-analysis, incident-management]
|
||||
sources: [How-Agentic-AI-can-help-for-Cloud-DevOps]
|
||||
last_updated: 2026-04-16
|
||||
---
|
||||
|
||||
## Summary
|
||||
AI-driven RCA（AI 驱动的根因分析）利用机器学习分析日志和指标，自动识别故障根本原因。
|
||||
|
||||
## Definition
|
||||
使用 AI 算法分析来自多个来源的日志、指标和事件数据，自动定位系统故障的根本原因。
|
||||
|
||||
## Key Techniques
|
||||
- **日志关联分析**：跨服务、跨时间关联日志事件
|
||||
- **异常模式识别**：识别与历史 outage 类似的模式
|
||||
- **因果链路推断**：构建故障传播链路，确定因果关系
|
||||
- **多维度分析**：同时分析计算、网络、存储、应用层
|
||||
|
||||
## Tools
|
||||
- [[CloudWatch]]（AWS）
|
||||
- [[Stackdriver]]/Cloud Monitoring（GCP）
|
||||
- Azure Monitor（Azure）
|
||||
|
||||
## Connections
|
||||
- [[Agentic AI]] ← uses ← [[AI-driven RCA]]：Agentic AI 集成 RCA 能力
|
||||
- [[MTTR]] ← reduces ← [[AI-driven RCA]]：AI RCA 缩短平均修复时间
|
||||
@@ -1,23 +0,0 @@
|
||||
---
|
||||
title: "AI-powered Runbooks"
|
||||
type: concept
|
||||
tags: [runbooks, automation, AI]
|
||||
sources: [How-Agentic-AI-can-help-for-Cloud-DevOps]
|
||||
last_updated: 2026-04-16
|
||||
---
|
||||
|
||||
## Summary
|
||||
AI-powered Runbooks（AI 驱动运维手册）是利用 AI 推荐最佳运维操作手册和处理流程的系统。
|
||||
|
||||
## Definition
|
||||
AI 分析历史 incident 和最佳实践，自动推荐或生成处理当前事件的运维手册。
|
||||
|
||||
## Key Features
|
||||
- **智能推荐**：基于当前事件推荐最相关的操作手册
|
||||
- **动态生成**：根据上下文动态生成处理步骤
|
||||
- **历史学习**：从历史 incident 学习改进建议
|
||||
- **自动化执行**：可自动执行手册中的步骤
|
||||
|
||||
## Connections
|
||||
- [[Agentic AI]] ← powers ← [[AI-powered Runbooks]]：Agentic AI 实现智能运维手册
|
||||
- [[无责复盘 (Blameless Postmortem)]] ← informs ← [[AI-powered Runbooks]]：无责复盘结果改进运维手册
|
||||
@@ -1,21 +0,0 @@
|
||||
---
|
||||
title: "AI 摘要"
|
||||
type: concept
|
||||
tags: [ai-tool, summary]
|
||||
---
|
||||
|
||||
## Definition
|
||||
AI 摘要（AI-Summary）是指使用人工智能技术自动提取和总结文档、视频等内容的核心信息，生成简洁摘要的过程。
|
||||
|
||||
## Use Cases
|
||||
- 文章摘要：从长文章中提取关键信息
|
||||
- PDF 摘要：将 PDF 文档压缩为要点
|
||||
- 视频摘要：从视频内容中生成文字总结
|
||||
|
||||
## Related Tools
|
||||
- [[Decopy]]：提供文章、PDF 和视频摘要服务
|
||||
- [[NotebookLM]]：Google 的 AI 笔记工具，支持 Audio Overviews
|
||||
|
||||
## Related Concepts
|
||||
- [[信息提取]]：从非结构化数据中提取结构化信息
|
||||
- [[内容压缩]]：将长内容压缩为简短形式
|
||||
@@ -1,32 +0,0 @@
|
||||
---
|
||||
title: "AI-简报工作流"
|
||||
type: concept
|
||||
tags: [workflow, ai, presentation]
|
||||
---
|
||||
|
||||
## Definition
|
||||
先用 ChatGPT 做知识研究整理，再用 Canva/Gamma AI 输出设计的四阶段简报制作流程。
|
||||
|
||||
## Core Stages
|
||||
|
||||
### 阶段一：资料搜索（5分钟）
|
||||
利用 ChatGPT 上网搜索主题相关资料，调阅 10+ 笔素材作为简报素材库。
|
||||
|
||||
### 阶段二：知识架构（1分钟）
|
||||
让 ChatGPT 整理调阅出的素材，建立对主题的客观资料认识和主观诠释角度。
|
||||
|
||||
### 阶段三：大纲生成（1分钟）
|
||||
让 ChatGPT 根据阅读与理解，输出文字版简报大纲。
|
||||
|
||||
### 阶段四：设计输出
|
||||
将大纲复制到 Canva/Gamma，利用 AI 完成版面设计。
|
||||
|
||||
## Key Principles
|
||||
- 简报不是从版面设计开始，而是从资料研究开始
|
||||
- 在文字资料处理上，ChatGPT 比 Canva/Gamma 做得更好
|
||||
- 先完成知识整理，再让 AI 工具做视觉输出
|
||||
|
||||
## Connections
|
||||
- 使用 [[ChatGPT]] 进行研究和大纲生成
|
||||
- 使用 [[Canva]] 或 [[Gamma]] 进行设计输出
|
||||
- 核心概念：[[防彈筆記法]]
|
||||
@@ -1,62 +0,0 @@
|
||||
# AI 簡報流程
|
||||
|
||||
## Definition
|
||||
|
||||
AI 簡報流程是一種結合大型語言模型（LLM）進行前期資料研究、知識整理，與 AI 簡報工具進行視覺設計的兩階段工作方法論。
|
||||
|
||||
## Core Principles
|
||||
|
||||
1. **先研究、後設計** — 簡報不是從版面設計開始，而是從資料研究開始
|
||||
2. **內容為王** — AI 簡報工具擅長視覺設計，不擅長前期資料研究
|
||||
3. **分工明確** — LLM 負責文字推理與內容建構，AI 設計工具負責視覺美化
|
||||
|
||||
## Workflow Stages
|
||||
|
||||
### Stage 1: Knowledge Research (ChatGPT)
|
||||
|
||||
| Stage | Duration | Purpose |
|
||||
|-------|----------|---------|
|
||||
| 資料收集 | 5 min | 上網搜尋相關資料，調閱多筆素材 |
|
||||
| 架構建立 | 1 min | 建立對比表格，整理知識結構 |
|
||||
| 大綱設計 | 1 min | 輸出文字版簡報大綱 |
|
||||
|
||||
### Stage 2: Visual Design (Canva/Gamma)
|
||||
|
||||
| Tool | Strength | Notes |
|
||||
|------|----------|-------|
|
||||
| [[Canva]] | 豐富模板、AI 問答 | 2025年9月支援中文 |
|
||||
| [[Gamma]] | 專業版面、圖文並茂 | AI 簡報效果最好 |
|
||||
|
||||
## Practical Prompts
|
||||
|
||||
### 資料收集 Prompt
|
||||
```
|
||||
你是個人知識管理專家，請跟我解釋「[主題]」。請一步一步分析：
|
||||
先「上網搜尋相關資料」，以「條列清單的格式」，用一般人也能懂的用語，
|
||||
兼顧廣度與深度細節，說明這個主題。
|
||||
```
|
||||
|
||||
### 建立架構 Prompt
|
||||
```
|
||||
整合上面所有討論資料，建立一個「[主題]方法、應用」的對比表格，
|
||||
呈現出「打破[領域]迷思」的特色。
|
||||
```
|
||||
|
||||
### 簡報大綱 Prompt
|
||||
```
|
||||
統整上方的討論，根據「[主題]」主題，簡報對象是「[目標受眾]」，
|
||||
設計出 10 頁簡報大綱。請一步一步分析，先梳理上方討論的重點，
|
||||
根據背景、解決的問題、方法與應用，拆解出最容易讓人理解的順序。
|
||||
每一頁有一個明確主題，每個主題下條列關鍵重點，並帶入更多具體的數據資料細節，
|
||||
並且最後有吸引人的結論。
|
||||
```
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[防彈筆記法]] — 知識管理方法論
|
||||
- [[ChatGPT-應用]] — LLM 在知識工作中的應用
|
||||
- [[知識管理]] — 資料收集、整理、分析的系統方法
|
||||
|
||||
## References
|
||||
|
||||
- [[jiao-xue-chatgpt-xian-zuo-zhi-shi-zheng-li-zai-rang-canva-gamma-ai-shu-chu-jian-bao|教學：ChatGPT 先做知識整理，再讓 Canva、 Gamma AI 輸出簡報]]
|
||||
@@ -1,25 +0,0 @@
|
||||
---
|
||||
title: "AI"
|
||||
type: concept
|
||||
tags: [technology, intelligence]
|
||||
sources: [public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machine-learning-20240206]
|
||||
last_updated: 2024-02-06
|
||||
---
|
||||
|
||||
## Summary
|
||||
AI（人工智能）是复制需要人类智能才能完成的任务的系统，是计算机科学的一个分支。
|
||||
|
||||
## Definition
|
||||
Artificial Intelligence (AI) 是指能够复制以前需要人类智能才能完成的任务的系统，通常通过机器学习寻求概率性结果。
|
||||
|
||||
## Key Attributes
|
||||
- **类型**：技术/计算机科学
|
||||
- **子领域**：机器学习、深度学习、自然语言处理、计算机视觉
|
||||
- **核心方法**：监督学习、无监督学习、强化学习
|
||||
- **应用**：分类 AI、预测 AI、生成式 AI
|
||||
|
||||
## Connections
|
||||
- [[AI]] ← includes ← [[Machine Learning]]
|
||||
- [[AI]] ← includes ← [[Generative AI]]
|
||||
- [[AWS]] ← provides ← [[AI]]
|
||||
- [[Foundation Model]] ← powers ← [[AI]]
|
||||
@@ -1,32 +0,0 @@
|
||||
---
|
||||
title: "AI代理（Agent）"
|
||||
type: concept
|
||||
tags: [ai, cursor, agent]
|
||||
date: 2026-04-18
|
||||
---
|
||||
|
||||
## Definition
|
||||
具备自主决策和任务执行能力的 AI 系统，围绕 LLM 构建循环控制系统，能够感知目标、规划步骤、执行动作、并能够反思结果。
|
||||
|
||||
## Core Capability
|
||||
AI Agent = 思考（LLM）+ 认知（RAG）+ 行动，三者的组合实现真正的自主性。
|
||||
|
||||
## Agent Loop（代理循环）
|
||||
AI Agent 通过五步循环实现其目标：
|
||||
|
||||
1. **获取任务**：由具体且高层次的目标启动，可由用户或自动触发机制激活
|
||||
2. **扫描场景**：感知环境获取上下文信息，协调层访问可用资源（用户请求、记忆、工具）
|
||||
3. **仔细思考**：核心"思考"循环，由推理模型驱动，将任务与场景分析并制定行动计划
|
||||
4. **采取行动**：编排层执行计划的具体操作，选择并调用适当的工具（API、代码函数、数据库查询）
|
||||
5. **观察并迭代**：观察行动结果，将新信息添加到上下文或记忆中，然后回到步骤3继续循环
|
||||
|
||||
## Usage in Cursor
|
||||
- **Plan 模式**：生成计划，不修改代码
|
||||
- **Agent 模式**：执行计划，会修改代码文件
|
||||
- **Ask 模式**：仅返回文本答案，不改动文件
|
||||
|
||||
## Related Concepts
|
||||
- [[LLM]]：负责推理和思考
|
||||
- [[RAG]]：负责提供实时外部知识
|
||||
- [[Plan Mode]]：方案预览模式
|
||||
- [[Build Mode]]：实际执行模式
|
||||
@@ -1,15 +0,0 @@
|
||||
---
|
||||
title: "AI生成技能"
|
||||
type: concept
|
||||
tags: [claude-code, skill-category]
|
||||
date: 2026-04-18
|
||||
---
|
||||
|
||||
## Summary
|
||||
AI生成技能是 baoyu-skills 三大技能分类之一，专注于 AI 驱动的生成后端。
|
||||
|
||||
## Definition
|
||||
AI生成技能包括：baoyu-imagine（图像生成）、baoyu-danger-gemini-web（Gemini Web 交互）。
|
||||
|
||||
## Connections
|
||||
- [[baoyu-skills]] ← includes → [[AI生成技能]]
|
||||
@@ -1,22 +0,0 @@
|
||||
---
|
||||
title: "AI结对执行"
|
||||
type: concept
|
||||
tags: [vibe-coding, workflow]
|
||||
---
|
||||
|
||||
## 定义
|
||||
Vibe Coding 的核心理念之一，指人与 AI 协作进行开发，AI 负责具体的代码实现，开发者负责产品逻辑和审美把控。
|
||||
|
||||
## 工作模式
|
||||
- 开发者描述需求和期望
|
||||
- AI 生成实现计划和代码
|
||||
- 开发者审查和调整
|
||||
- 循环迭代直到完成
|
||||
|
||||
## 与 Vibe Coding 的关系
|
||||
AI结对执行是 Vibe Coding 三要素之一（规划驱动 + 上下文固定 + AI 结对执行），将开发者从体力劳动中解放出来，专注于创造性决策。
|
||||
|
||||
## 连接关系
|
||||
- [[AI结对执行]] ← part_of ← [[Vibe Coding]]
|
||||
- [[AI结对执行]] → enables → [[Plan Mode]]
|
||||
- [[AI结对执行]] → enables → [[Build Mode]]
|
||||
@@ -1,22 +0,0 @@
|
||||
---
|
||||
title: "AI自动回复"
|
||||
type: concept
|
||||
tags: [AI, Automation, Customer Service]
|
||||
---
|
||||
|
||||
## Definition
|
||||
基于业务知识库和意图分类的智能响应机制，AI能够自动回答常见问题、处理预约请求，并在必要时升级给人工处理。
|
||||
|
||||
## Related Concepts
|
||||
- [[业务知识库]]：存储企业服务、价格、政策的结构化数据
|
||||
- [[意图分类]]：识别客户消息意图（FAQ、预约、投诉、评价）的技术
|
||||
- [[人工接管]]：复杂问题转由人工处理的机制
|
||||
|
||||
## Use Cases
|
||||
- FAQ自动回答
|
||||
- 预约请求处理
|
||||
- 投诉识别和升级
|
||||
|
||||
## Connections
|
||||
- [[Multi-Channel AI Customer Service Platform]] ← uses ← [[AI自动回复]]
|
||||
- [[AI自动回复]] ← depends_on ← [[业务知识库]]
|
||||
@@ -1,41 +0,0 @@
|
||||
---
|
||||
title: AI视频生成
|
||||
type: concept
|
||||
tags: [ai-video]
|
||||
---
|
||||
|
||||
## Definition
|
||||
AI 视频生成是指利用人工智能技术自动创建视频内容的过程，包括从文本描述生成视频（图生视频）、从图片生成视频、以及完全由 AI 创作视频等技术方向。
|
||||
|
||||
## Key Technologies
|
||||
- 扩散模型（Diffusion Models）：基于噪声预测的生成技术
|
||||
- 时空联合注意力：理解复杂的时空关系
|
||||
- 多主体参考：保持多个主体的一致性
|
||||
- 物理模拟：生成符合真实世界物理规律的动作
|
||||
|
||||
## Application Scenarios
|
||||
- 内容创作：短视频、广告、剧情创作
|
||||
- 电商营销：商品展示视频生成
|
||||
- 教育内容：动态演示视频制作
|
||||
- 社交媒体：表情包、创意内容
|
||||
- 个人创作：照片动态化
|
||||
|
||||
## Industry Trends
|
||||
1. 生成速度持续提升：从分钟级到秒级
|
||||
2. 质量逐步提升：分辨率从 720p 到 1080p+
|
||||
3. 控制能力增强：从随机生成到精准控制
|
||||
4. 多模态融合：图生视频、文生视频、音视频同步
|
||||
|
||||
## Major Players
|
||||
- [[阿里巴巴]]：绘蛙AI视频、通义万相
|
||||
- [[快手]]：可灵AI
|
||||
- [[字节跳动]]：即梦AI
|
||||
- [[智谱AI]]：智谱清影
|
||||
- [[生数科技]]：Vidu
|
||||
- [[MiniMax]]：海螺AI
|
||||
- [[Stability AI]]：Stable Video
|
||||
- [[爱诗科技]]：PixVerse
|
||||
- [[潞晨科技]]：Video Ocean
|
||||
- [[阿里妈妈]]：万相营造
|
||||
- [[智象未来]]：Viva
|
||||
- [[MewXAI]]：艺映AI
|
||||
@@ -1,53 +0,0 @@
|
||||
---
|
||||
title: "AI辅助剪辑"
|
||||
type: concept
|
||||
tags: [ai, video-editing, automation]
|
||||
aliases: [AI-Assisted Editing, AI Video Editing]
|
||||
last_updated: 2026-04-21
|
||||
---
|
||||
|
||||
## Definition
|
||||
利用人工智能技术加速短视频制作各环节的技术，包括 AI 自动字幕、AI 智能抠像、AI 生成视频、AI 音乐生成和数字人配音。
|
||||
|
||||
## Core AI Capabilities
|
||||
|
||||
### AI Auto-Subtitles（AI 自动字幕）
|
||||
- **CapCut AI 字幕**：95%+ 准确率，支持中英日韩等多语言；一键生成
|
||||
- **OpenAI Whisper**：开源、离线可用、支持 99 种语言、极高准确率
|
||||
- **ByteDance 火山引擎 ASR**：企业 API，适合批量处理
|
||||
- **AI 字幕工作流**：AI 初稿 → 手动 review（专注术语、人名、同音字）→ 时间线调整 → 样式应用
|
||||
- **重要提醒**：AI 字幕并非 100% 准确——术语、方言、重叠说话人需要手动 review
|
||||
|
||||
### AI One-Click Video Generation（AI 一键成片）
|
||||
- CapCut "文字生视频"：输入文字自动匹配库存 footage、旁白、字幕和 BGM
|
||||
- CapCut "AI 脚本"：输入主题自动生成脚本 + 分镜建议
|
||||
- **用途**：新闻风格 / 对话口播 / 图文视频的快速初稿
|
||||
- **局限性**：AI 生成视频"能看但没灵魂"——处理 60% 工作，剩下 40% 创意细化仍需人工
|
||||
|
||||
### AI Smart Cutout（AI 智能抠像）
|
||||
- CapCut AI 抠像：实时人物分割，无需绿幕；效果已相当好
|
||||
- **Runway ML**：专业 AI 抠像和视频生成工具
|
||||
- **用途**：背景替换、画中画、绿幕替代
|
||||
- **边缘质量**：头发、半透明物体（玻璃/烟雾）仍是 AI 挑战；关键时需手动修补
|
||||
|
||||
### AI Music Generation（AI 音乐生成）
|
||||
- **Suno AI / Udio**：输入文字描述生成原创音乐；可指定风格、情绪和时长
|
||||
- **用途**：找不到合适 BGM 时快速生成定制音乐；避免版权问题
|
||||
- **版权注意**：确认 AI 生成音乐的商业授权条款；各平台政策不同
|
||||
- **质量评估**：简单配器足够；复杂编曲和人声表演仍不及人类创作
|
||||
|
||||
### Digital Avatar Narration（数字人配音）
|
||||
- 工具：CapCut 数字人、HeyGen、D-ID、腾讯智影
|
||||
- **用途**：批量生产教育/新闻内容；无法真人出镜时的替代方案
|
||||
- **现状**：唇形同步和面部表情已相当自然，但"明显是数字人"的感觉仍在
|
||||
- **使用建议**：作为真人出镜的补充而非替代——观众对真人的信任度远高于数字人
|
||||
|
||||
## Efficiency Impact
|
||||
- AI 字幕：节省 80% 字幕制作时间
|
||||
- AI 抠像：无需绿幕，简化拍摄流程
|
||||
- AI 成片：处理 60% 重复性工作
|
||||
|
||||
## Connections
|
||||
- [[短视频剪辑]] ← 技术增强 ← [[AI辅助剪辑]]
|
||||
- [[字幕设计]] ← 技术加速 ← [[AI辅助剪辑]]
|
||||
- [[CapCut Pro]] ← 内置 AI 功能 ← [[AI辅助剪辑]]
|
||||
@@ -1,29 +0,0 @@
|
||||
---
|
||||
title: "AI配音"
|
||||
type: concept
|
||||
tags: [AI, 语音合成]
|
||||
last_updated: 2026-04-18
|
||||
---
|
||||
|
||||
## Definition
|
||||
使用人工智能技术将文字转化为语音的技术。
|
||||
|
||||
## Related Tools
|
||||
- [[ElevenLabs]] — 国际顶流AI配音工具
|
||||
- [[海螺AI]] — MiniMax 出品，免费
|
||||
- [[F5-TTS]] — 开源免费，支持本地部署
|
||||
- [[TTSMaker]] — 每周免费3万字
|
||||
- [[剪映]] — 抖音官方，与视频剪辑无缝衔接
|
||||
- [[魔音工坊]] — 企业级，500+音色
|
||||
- [[AnyVoice]] — 3秒克隆，免费无限下载
|
||||
|
||||
## Use Cases
|
||||
- 有声书制作
|
||||
- 游戏角色配音
|
||||
- 视频旁白
|
||||
- 外语教学视频
|
||||
- 广告配音
|
||||
|
||||
## Related Concepts
|
||||
- [[声音克隆]] — 通过少量音频样本训练AI模型
|
||||
- [[文字转语音]] — TTS技术
|
||||
@@ -1,18 +0,0 @@
|
||||
---
|
||||
title: "AMI End-of-Life"
|
||||
type: concept
|
||||
tags: [AWS, Cloud, Infrastructure, Lifecycle]
|
||||
---
|
||||
|
||||
## Definition
|
||||
AMI End-of-Life 是指操作系统版本到达生命周期终点，AWS 不再提供更新和支持。
|
||||
|
||||
## Timeline
|
||||
- CentOS 7 → Rocky Linux (2024年6月)
|
||||
- Red Hat 7 → Rocky Linux (2024年6月)
|
||||
- OpenSUSE Leap 15 → (2024年12月)
|
||||
- OEL 7 → (2024年12月)
|
||||
|
||||
## Migration Path
|
||||
- CentOS 7 迁移到 Rocky Linux
|
||||
- 保持现有应用兼容性的同时完成操作系统升级
|
||||
@@ -1,43 +0,0 @@
|
||||
---
|
||||
title: "AMI Roadmap"
|
||||
type: concept
|
||||
tags:
|
||||
- AWS
|
||||
- AMI
|
||||
- Roadmap
|
||||
---
|
||||
|
||||
## Definition
|
||||
AMI 路线图（AMI Roadmap）是 CCOE 规划的操作系统支持计划，涵盖当前支持的 AMI 版本和新操作系统的添加时间表。
|
||||
|
||||
## Current Supported AMIs
|
||||
- Ubuntu（3个版本）
|
||||
- CentOS 7 和 8
|
||||
- Rocky 8.4 ARM
|
||||
- Amazon Linux 2
|
||||
- Windows（4个版本）
|
||||
|
||||
## Roadmap Timeline
|
||||
| 时间 | 新增 AMI |
|
||||
|------|----------|
|
||||
| 2022年11月 | SLES 15, RHEL 9 |
|
||||
| 2023年1月 | OpenSUSE 15, Amazon Linux 2022 |
|
||||
| 2023年3月 | Rocky 8, Rocky 9 |
|
||||
| 2023年5月 | RHEL 9.4 ARM, Ubuntu 22.04 ARM |
|
||||
|
||||
## EOL (End of Life) Schedule
|
||||
- Windows Server 2008/2008 R2：2020年1月
|
||||
- CentOS 8：2021年12月
|
||||
- Windows Server 2012：2023年10月
|
||||
- RHEL 7 + CentOS 7：2024年6月
|
||||
|
||||
## Priority Management
|
||||
路线图优先级由 ADM 需求决定，如需调整需通过需求管道（Demand Pipeline）流程。
|
||||
|
||||
## Related
|
||||
- [[Standard AMI]]
|
||||
- [[AMI-End-of-Life]]
|
||||
- [[CCOE]]
|
||||
|
||||
## Last Updated
|
||||
2026-04-18
|
||||
@@ -1,29 +0,0 @@
|
||||
---
|
||||
title: "AMI Sharing"
|
||||
type: concept
|
||||
tags: [AWS, AMI, Cloud]
|
||||
---
|
||||
|
||||
## Definition
|
||||
AMI Sharing（镜像共享机制）是 AWS 允许账户持有者通过授权方式与其他 AWS 账户共享 AMIs 的功能，避免了跨账号复制带来的额外存储成本和复制时间。
|
||||
|
||||
## Mechanism
|
||||
- 通过 AWS Resource Access Manager (RAM) 或控制台共享
|
||||
- 接收账户在自身账户中使用共享的 AMI 启动实例
|
||||
- 无需物理复制镜像到目标账户
|
||||
|
||||
## Benefits
|
||||
- 避免存储重复镜像
|
||||
- 快速分发到多个账号和区域
|
||||
- 降低存储成本
|
||||
- 简化镜像管理
|
||||
|
||||
## Use Cases
|
||||
- 中央镜像库分发标准 AMI
|
||||
- 跨账号环境标准化
|
||||
- ISV 镜像产品分发
|
||||
|
||||
## Related Concepts
|
||||
- [[Foundation AMI]] — 通过 AMI Sharing 分发的镜像类型
|
||||
- [[Standard AMI]] — 企业标准镜像
|
||||
- [[AWS Organizations]] — 跨账号管理
|
||||
@@ -1,41 +0,0 @@
|
||||
---
|
||||
title: "ANSI Escape Sequence"
|
||||
type: concept
|
||||
tags: [ansi, terminal, escape, control]
|
||||
---
|
||||
|
||||
## 定义
|
||||
ANSI 转义序列（ANSI Escape Sequence）是一种用于控制终端显示的标准化指令，通过转义字符（ESC）开头，后跟参数和控制码。
|
||||
|
||||
## 序列结构
|
||||
- 开头：ESC（\x1b）或 CSI（\x9b）
|
||||
- 参数：数字序列，用分号分隔
|
||||
- 结束：控制码字母
|
||||
|
||||
## 常用序列类别
|
||||
|
||||
### SGR（Select Graphic Rendition）
|
||||
- `\x1b[0m` — 重置所有属性
|
||||
- `\x1b[1m` — 加粗
|
||||
- `\x1b[4m` — 下划线
|
||||
- `\x1b[30m`-`\x1b[37m` — 前景色（黑-白）
|
||||
- `\x1b[40m`-`\x1b[47m` — 背景色（黑-白）
|
||||
|
||||
### 光标控制
|
||||
- `\x1b[H` 或 `\x1b[;H` — 光标归位
|
||||
- `\x1b[nA`/`\x1b[nB` — 上/下移动
|
||||
- `\x1b[nC`/`\x1b[nD` — 右/左移动
|
||||
|
||||
### 屏幕操作
|
||||
- `\x1b[2J` — 清除屏幕
|
||||
- `\x1b[K` — 清除行
|
||||
|
||||
## 应用场景
|
||||
- 终端输出着色
|
||||
- 进度条渲染
|
||||
- 表格边框绘制
|
||||
- 交互式 UI（TUI）
|
||||
|
||||
## 相关技术
|
||||
- [[VT100]]：终端标准规范
|
||||
- [[Terminal Emulation]]：终端仿真
|
||||
@@ -1,38 +0,0 @@
|
||||
---
|
||||
title: "API Enablement"
|
||||
type: concept
|
||||
tags: [google-cloud, oauth, api]
|
||||
---
|
||||
|
||||
## Definition
|
||||
API Enablement 是在 Google Cloud Console 中为项目启用特定 API 服务的操作。即使 OAuth 认证成功，如果目标 API 未启用，调用时仍会返回 `403 accessNotConfigured` 错误。
|
||||
|
||||
## Two-Layer Authorization Model
|
||||
|
||||
| 层级 | 控制内容 | 错误示例 |
|
||||
|------|---------|---------|
|
||||
| OAuth 授权 | 用户身份认证 | 未授权/权限不足 |
|
||||
| API Enablement | 是否允许调用 API | `403 accessNotConfigured` |
|
||||
|
||||
## 操作步骤
|
||||
1. 进入 **Google Cloud Console** → **APIs & Services** → **Library**
|
||||
2. 搜索目标 API（如 Gmail API、Calendar API）
|
||||
3. 点击 **Enable** 启用
|
||||
4. 等待生效（通常 30 秒 ~ 2 分钟，有延迟）
|
||||
5. 重新执行 OAuth 授权（因旧 token 不包含新权限）
|
||||
|
||||
## 典型错误
|
||||
> Gmail API has not been used in project XXX
|
||||
|
||||
表示：该 Google Cloud 项目未启用 Gmail API
|
||||
|
||||
## 相关概念
|
||||
- [[OAuth]]：第一层认证
|
||||
- [[Google-Cloud-Console]]：管理 API 启用的控制台
|
||||
- [[Gmail-API]]：Google Workspace API 示例
|
||||
- [[Calendar-API]]：日历 API
|
||||
- [[Drive-API]]：云端硬盘 API
|
||||
- [[测试用户]]：OAuth 授权配置
|
||||
|
||||
## 相关工具
|
||||
- [[gog CLI]]：一个同时需要 OAuth + API Enablement 才能正常工作的 CLI 工具
|
||||
@@ -1,41 +0,0 @@
|
||||
---
|
||||
title: "API Gateway"
|
||||
type: concept
|
||||
tags:
|
||||
- AWS
|
||||
- Serverless
|
||||
- API
|
||||
- Gateway
|
||||
date: 2024-09-03
|
||||
---
|
||||
|
||||
## Definition
|
||||
API Gateway 是 AWS 托管服务，用于创建、发布、维护和保护 API。作为 API 的前端入口，将请求路由到后端服务（如 Lambda、EC2），并处理认证、限流、监控等功能。
|
||||
|
||||
## Endpoint Types
|
||||
- **Edge-optimized（边缘优化）**：
|
||||
- 通过 CloudFront CDN 分发
|
||||
- 降低延迟
|
||||
- 适合全球访问
|
||||
|
||||
- **Regional（区域）**：
|
||||
- 同区域部署
|
||||
- 更低延迟
|
||||
- 适合同区域客户端
|
||||
|
||||
- **Private（私有）**：
|
||||
- 仅 VPC 内部访问
|
||||
- 通过 VPC 端点访问
|
||||
- 适合内部服务
|
||||
|
||||
## Key Features
|
||||
- 请求验证：验证 API 密钥、JWT、IAM
|
||||
- 速率限制：防止 API 滥用
|
||||
- 缓存：减少后端调用
|
||||
- 监控：CloudWatch 集成
|
||||
- 自定义域名：绑定自有域名
|
||||
- API 版本管理：v1、v2 版本控制
|
||||
|
||||
## Aliases
|
||||
- Amazon API Gateway
|
||||
- API Gateway
|
||||
@@ -1,28 +0,0 @@
|
||||
---
|
||||
title: "ARM64"
|
||||
type: concept
|
||||
tags: [linux, 架构, cpu, arm]
|
||||
date: 2026-04-16
|
||||
---
|
||||
|
||||
## Definition
|
||||
ARM64（AArch64）是 64 位 ARM 架构，广泛用于移动设备、嵌入式系统和部分服务器（如 AWS Graviton、阿里云倚天710）。
|
||||
|
||||
## Aliases
|
||||
- AArch64
|
||||
- aarch64
|
||||
|
||||
## Key Characteristics
|
||||
- 低功耗设计，效率优先
|
||||
- 64 位寻址能力
|
||||
- Apple Silicon（M 系列芯片）也使用 ARM64 架构
|
||||
- 部分云服务器使用 ARM 架构以降低成本
|
||||
|
||||
## Related Concepts
|
||||
- [[x86_64]]：另一种 64 位架构，Intel 和 AMD 处理器使用
|
||||
|
||||
## Usage
|
||||
在 Linux 中可通过以下命令检测：
|
||||
- `uname -m` 输出 aarch64
|
||||
- `lscpu` Architecture 字段显示 aarch64
|
||||
- `/proc/cpuinfo` 显示 AArch64 或 ARMv8
|
||||
@@ -1,20 +0,0 @@
|
||||
---
|
||||
title: "ATS"
|
||||
type: concept
|
||||
tags: [hr, recruiting, systems]
|
||||
sources: [recruitment-specialist]
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
ATS（Applicant Tracking System）是用于管理招聘流程、候选人资料、面试反馈和流程状态的系统。
|
||||
|
||||
## Core Principles
|
||||
- 统一记录候选人状态
|
||||
- 减少信息丢失和重复沟通
|
||||
- 支持筛选、评分和自动化提醒
|
||||
- 让招聘过程可追踪、可复盘
|
||||
|
||||
## Related Entities
|
||||
- [[Recruitment Specialist]]
|
||||
- [[The Agency]]
|
||||
@@ -1,32 +0,0 @@
|
||||
---
|
||||
title: "AWS Backup"
|
||||
type: concept
|
||||
tags: [AWS, Backup, DR]
|
||||
sources: []
|
||||
last_updated: 2026-04-18
|
||||
---
|
||||
|
||||
## Summary
|
||||
AWS Backup 是 AWS 托管的集中化数据保护服务，用于跨账户和跨区域自动备份 AWS 资源。
|
||||
|
||||
## Definition
|
||||
AWS Backup 是 AWS 提供的托管备份服务，支持 S3、RDS、EBS、EFS、EC2、FSx、DynamoDB 等 AWS 服务的统一备份。
|
||||
|
||||
## Key Features
|
||||
- 集中管理：跨账户、跨区域备份
|
||||
- 不可变性（Immutability）：防止备份被篡改或删除
|
||||
- 时间点恢复（PITR）：S3 和 RDS 可在 1 秒内恢复
|
||||
- 备份计划：支持每日、每小时或自定义计划
|
||||
- 法律保留（Legal Holds）：隔离备份以满足合规要求
|
||||
- 基于角色的访问控制（IAM）
|
||||
- CloudWatch 集成监控
|
||||
|
||||
## Limitations
|
||||
- 无法排除特定附加卷，必须备份所有卷
|
||||
- 不支持增量快照，仅支持崩溃一致性快照
|
||||
- 热备份已被 Amazon 不推荐用于数据库
|
||||
|
||||
## Connections
|
||||
- [[AWS]] → 提供 [[AWS Backup]]
|
||||
- [[RTO (Recovery Time Objective)]] ← 降低 [[备份和恢复]]
|
||||
- [[AWS Backup]] ← 替代 [[CCIE 门户]]
|
||||
@@ -1,22 +0,0 @@
|
||||
---
|
||||
title: "AWS Cloud Adoption Framework"
|
||||
type: concept
|
||||
tags: [Cloud, Framework, AWS]
|
||||
sources: [Cloud-Maturity-Model-A-Detailed-Guide-For-Cloud-Adoption]
|
||||
last_updated: 2025-02-28
|
||||
---
|
||||
|
||||
## Summary
|
||||
AWS Cloud Adoption Framework（AWS CAF）是一种帮助组织识别和优先处理转型机会、增强云就绪度的框架。
|
||||
|
||||
## Definition
|
||||
AWS CAF 提供最佳实践指导，帮助组织逐步完善转型路线图。
|
||||
|
||||
## Key Capabilities
|
||||
- 识别和优先处理转型机会
|
||||
- 增强云就绪度
|
||||
- 逐步完善转型路线图
|
||||
- AWS 特定的术语和实践
|
||||
|
||||
## Connections
|
||||
- [[AWS-Cloud-Adoption-Framework]] ← extends ← [[Cloud-Maturity-Model]]
|
||||
@@ -1,25 +0,0 @@
|
||||
---
|
||||
title: "AWS Landing Zone"
|
||||
type: concept
|
||||
tags:
|
||||
- AWS
|
||||
- Architecture
|
||||
- Multi-Account
|
||||
---
|
||||
|
||||
## Definition
|
||||
AWS Landing Zone 是 AWS 推荐的企业级云基础架构框架，通过多账号策略、安全基线、网络架构等组件提供安全、可扩展的云环境起点。
|
||||
|
||||
## Key Components
|
||||
- **多账号策略**：通过 AWS Organizations 管理多个账户
|
||||
- **安全基线**：安全组、SCP、密码策略等
|
||||
- **网络架构**：VPC、Transit Gateway、VPN/Direct Connect
|
||||
- **身份管理**：IAM 角色、SSO、AD 集成
|
||||
|
||||
## Related Concepts
|
||||
- [[Network-Segregation]]
|
||||
- [[SSM-Access]]
|
||||
- [[Gruntwork-Landing-Zone]]
|
||||
|
||||
## Related Entities
|
||||
- [[AWS]]
|
||||
@@ -1,43 +0,0 @@
|
||||
---
|
||||
title: "AWS SES"
|
||||
type: concept
|
||||
tags:
|
||||
- AWS
|
||||
- email
|
||||
- service
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- SES
|
||||
- Simple Email Service
|
||||
- Amazon SES
|
||||
- Amazon Simple Email Service
|
||||
|
||||
## Description
|
||||
AWS 提供的基于云的邮件发送服务，支持通过 API 或 SMTP 接口发送电子邮件。SES 提供可扩展的邮件发送能力，按发送量计费，是企业云端邮件发送的标准方案。
|
||||
|
||||
## Key Features
|
||||
- SMTP 端点：支持标准 SMTP 协议，应用程序无需重构代码即可集成
|
||||
- API 端点：支持直接调用 SES API 发送邮件
|
||||
- 收件人验证：生产环境需申请脱离 Sandbox Mode
|
||||
- 域名验证：支持 DKIM、SPF、DMARC 验证
|
||||
- VPC 终端节点：通过 PrivateLink 私有访问，避免公网暴露
|
||||
|
||||
## Use Cases
|
||||
- 应用通知邮件
|
||||
- 事务性邮件（订单确认、密码重置等）
|
||||
- 营销邮件
|
||||
- 批量邮件发送
|
||||
|
||||
## Related Concepts
|
||||
- [[SMTP]]
|
||||
- [[DKIM]]
|
||||
- [[VPC Endpoint]]
|
||||
- [[Secrets Manager]]
|
||||
|
||||
## Related Services
|
||||
- Amazon SNS：邮件通知的备选方案
|
||||
- Amazon Pinpoint：营销邮件服务
|
||||
|
||||
## Sources
|
||||
- [[ctp-topic-12-using-ses-smtp-service-terraform-module]]
|
||||
@@ -1,19 +0,0 @@
|
||||
---
|
||||
title: "Academic Detailing Compliance"
|
||||
type: concept
|
||||
tags: [academic-detailing, compliance, pharma, china]
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
Academic Detailing Compliance covers compliant medical education, conference sponsorship, speaker arrangements, and medical representative conduct.
|
||||
|
||||
## Core Principles
|
||||
- Keep academic content independent from commercial influence
|
||||
- Document sponsorships, speaker fees, and travel support transparently
|
||||
- Medical representatives may discuss safety and efficacy, but not act as sales quota carriers
|
||||
- Avoid gifts, benefits, or arrangements that look like disguised bribery
|
||||
|
||||
## Related Concepts
|
||||
- [[HealthcareMarketingCompliance]]
|
||||
- [[MedicalAdvertisingCompliance]]
|
||||
@@ -1,26 +0,0 @@
|
||||
---
|
||||
title: "Access Control"
|
||||
type: concept
|
||||
tags: [security, access-management]
|
||||
sources: [what-is-devsecops-best-practices-benefits-and-tools]
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
访问控制（Access Control）是管理谁可以访问系统、应用程序和数据的实践。在 DevSecOps 中，访问控制贯穿整个开发过程，确保只有授权人员能够访问敏感资源和进行特定操作。
|
||||
|
||||
## Core Components
|
||||
- **身份认证（Authentication）**：验证用户身份
|
||||
- **授权（Authorization）**：确定用户权限
|
||||
- **审计（Audit）**：记录访问行为
|
||||
|
||||
## Implementation in DevSecOps
|
||||
- 实施最小权限原则
|
||||
- 使用强身份验证方法（MFA）
|
||||
- 基于角色的访问控制（RBAC）
|
||||
- 自动化访问权限管理
|
||||
|
||||
## Connections
|
||||
- [[DevSecOps]] ← requires ← [[Access Control]]
|
||||
- [[Zero-Trust-Architecture]] ← implements ← [[Access Control]]
|
||||
- [[Risk Management]] ← includes ← [[Access Control]]
|
||||
@@ -1,26 +0,0 @@
|
||||
---
|
||||
title: "Ad Strength"
|
||||
type: concept
|
||||
tags: [Google Ads, Advertising, Quality Score]
|
||||
---
|
||||
|
||||
## 定义
|
||||
广告质量评分（Ad Strength）是 Google Ads 评估响应式搜索广告（RSA）整体质量的指标，分为 Poor、Average、Good、Excellent 四个等级。
|
||||
|
||||
## 评分维度
|
||||
- 相关性（Relevance）
|
||||
- 数量（Quantity）
|
||||
- 质量（Quality）
|
||||
|
||||
## 优化目标
|
||||
- 90%+ 的 RSA 评级为"Good"或"Excellent"
|
||||
|
||||
## 影响因素
|
||||
- 标题与关键词的相关性
|
||||
- 描述内容的完整性
|
||||
- 素材多样性
|
||||
- 行动号召明确性
|
||||
|
||||
## 相关概念
|
||||
- [[Responsive Search Ads (RSA)]]
|
||||
- [[Paid Media Ad Creative Strategist]]
|
||||
@@ -1,26 +0,0 @@
|
||||
---
|
||||
title: "Agent Archive"
|
||||
type: concept
|
||||
tags: []
|
||||
---
|
||||
|
||||
## 定义
|
||||
单一 Agent 的私有笔记目录，用于记录该 Agent 的专属思考、工作日志、任务记录和内容输出。
|
||||
|
||||
## 示例
|
||||
```
|
||||
/Users/weishen/Workspace/nexus/openclaw/xingshu/ ← 星枢专属笔记
|
||||
/Users/weishen/Workspace/nexus/openclaw/xinghui/ ← 星辉专属笔记
|
||||
/Users/weishen/Workspace/nexus/openclaw/xingyao/ ← 星曜专属笔记
|
||||
```
|
||||
|
||||
## 核心原则
|
||||
研究过程写入 Agent Archive；经过验证、可复用的知识沉淀到 Knowledge Base。
|
||||
|
||||
## 与 Knowledge Base 的关系
|
||||
Agent Archive 是临时工作区，Knowledge Base 是整理后的公共知识库。AI 在完成任务过程中将产出写入 Archive，验证通过后迁移到 Knowledge Base。
|
||||
|
||||
## 关联
|
||||
- [[Knowledge Base]]
|
||||
- [[OpenClaw]]
|
||||
- [[Obsidian]]
|
||||
@@ -1,19 +0,0 @@
|
||||
---
|
||||
title: "Agent Chain"
|
||||
type: concept
|
||||
tags: [agent-architecture, multi-agent]
|
||||
---
|
||||
|
||||
## Definition
|
||||
多个 Agent 串联工作，各自负责不同阶段的流水线架构。一个 Agent 的输出作为下一个 Agent 的输入，实现复杂任务的分解与协同。
|
||||
|
||||
## Use Cases
|
||||
- Podcast Production Pipeline：研究 Agent → 脚本 Agent → Show Notes Agent → 社交媒体 Agent
|
||||
- 内容工厂：选题 Agent → 写作 Agent → 校对 Agent → 发布 Agent
|
||||
|
||||
## Related Concepts
|
||||
- [[Pipeline]]：带硬性检查点的严格工作流
|
||||
- [[Agentic-AI]]：具备自主决策和任务执行能力的 AI 系统
|
||||
|
||||
## Related Sources
|
||||
- [[podcast-production-pipeline]]
|
||||
@@ -1,53 +0,0 @@
|
||||
---
|
||||
id: agent-skill-design-patterns
|
||||
title: "Agent Skill 设计模式"
|
||||
type: concept
|
||||
tags: [Agent, Skill, 设计模式]
|
||||
sources: [Google-5-Agent-Skill-design-patterns-2026-03-19]
|
||||
last_updated: 2026-04-17
|
||||
---
|
||||
|
||||
## Summary
|
||||
Google 发布的 5 种 Agent Skill 设计模式，用于指导如何构建真正可靠的 agent。
|
||||
|
||||
## Definition
|
||||
Agent Skill 设计模式是 Google Cloud 总结的 5 种经过验证的 skill 构建模式，每种都有完整的 ADK 代码示例。
|
||||
|
||||
## Five Patterns
|
||||
|
||||
### 1. Tool Wrapper
|
||||
让 agent 快速成为某个领域的专家。通过监听特定库关键词，当用户开始使用特定技术时才动态加载相关文档。
|
||||
|
||||
### 2. Generator
|
||||
从模板生成结构化输出。通过"填空"流程解决 agent 每次运行生成文档结构不一致的问题。
|
||||
|
||||
### 3. Reviewer
|
||||
把检查清单和检查逻辑分开。审查标准存放在 references 目录，agent 动态加载特定审查标准并强制输出结构化结果。
|
||||
|
||||
### 4. Inversion
|
||||
agent 先问用户再做。通过明确、不可协商的门控指令，确保 agent 逐个阶段提问，等待用户答案后再进入下一个阶段。
|
||||
|
||||
### 5. Pipeline
|
||||
带硬性检查点的严格工作流。强制执行顺序工作流，在关键节点设置硬性检查点，确保无法绕过复杂任务直接给出未验证的最终结果。
|
||||
|
||||
## Selection Guide
|
||||
每种模式有其应用场景：
|
||||
- Tool Wrapper：需要快速成为某领域专家时
|
||||
- Generator：需要强制一致的输出格式时
|
||||
- Reviewer：需要不同专项审计时
|
||||
- Inversion：需要用户参与每个阶段时
|
||||
- Pipeline：需要严格工作流和检查点时
|
||||
|
||||
## Combination
|
||||
5 种模式并非互斥，可以组合使用：
|
||||
- Pipeline 可以在最后包含 Reviewer 步骤来 double-check 成果
|
||||
- Generator 可以在最开始依赖 Inversion 来收集必要变量
|
||||
|
||||
## Related Concepts
|
||||
- [[Tool Wrapper]]
|
||||
- [[Generator]]
|
||||
- [[Reviewer]]
|
||||
- [[Inversion]]
|
||||
- [[Pipeline]]
|
||||
- [[SkillToolset]]
|
||||
- [[渐进式披露]]
|
||||
@@ -1,26 +0,0 @@
|
||||
---
|
||||
title: "Agent Task Visibility"
|
||||
type: concept
|
||||
tags: []
|
||||
---
|
||||
|
||||
## Definition
|
||||
AI Agent 任务对用户的透明化展示机制，通过外部工具（如 Todoist）实时展示任务状态、进度和内部推理过程。
|
||||
|
||||
## Core Components
|
||||
- 状态可视化：通过 Section 区分任务阶段（In Progress/Waiting/Done）
|
||||
- 推理外部化：将 Agent 内部 Plan 写入任务描述
|
||||
- 进度流式更新：子步骤完成通过评论实时追加
|
||||
|
||||
## Use Cases
|
||||
- 长时间运行的复杂任务追踪
|
||||
- 多 Agent 协作时的进度监控
|
||||
- 用户对 Agent 行为的可观测性提升
|
||||
|
||||
## Related Concepts
|
||||
- [[Task-Automation]]
|
||||
- [[工作流自动化]]
|
||||
|
||||
## Related Entities
|
||||
- [[Todoist]]
|
||||
- [[OpenClaw]]
|
||||
@@ -1,24 +0,0 @@
|
||||
---
|
||||
title: "Agent Design Principles"
|
||||
type: concept
|
||||
tags: [ai-agents, design]
|
||||
sources: [the-agency-contributing]
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
The Agency 项目定义的智能体设计六大核心原则，用于创建高质量、专业化的 AI 智能体。
|
||||
|
||||
## Six Principles
|
||||
|
||||
1. **Strong Personality** — 赋予智能体独特的声音和角色，非通用的"helpful assistant"
|
||||
2. **Clear Deliverables** — 提供具体的代码示例、模板和框架，展示真实输出
|
||||
3. **Success Metrics** — 包含具体可衡量的指标（如"页面加载时间低于 3 秒"）
|
||||
4. **Proven Workflows** — 经过真实场景验证的步骤流程，非理论推导
|
||||
5. **Learning Memory** — 智能体从成功模式、失败方法、用户反馈中学习
|
||||
6. **Real-world Testing** — 在真实场景中测试和迭代
|
||||
|
||||
## Application
|
||||
|
||||
- [[TheAgency]] 项目的所有贡献者应遵循这些原则创建新智能体
|
||||
- 评审新智能体时检查是否符合六大原则
|
||||
- 与 [[AgentFileStructure]] 结合使用
|
||||
@@ -1,32 +0,0 @@
|
||||
---
|
||||
title: "Agent File Structure"
|
||||
type: concept
|
||||
tags: [ai-agents, structure]
|
||||
sources: [the-agency-contributing]
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
The Agency 项目定义的智能体文件结构规范，区分 Persona（身份）与 Operations（操作）两大语义组。
|
||||
|
||||
## Persona Group（身份相关）
|
||||
|
||||
- **Identity & Memory** — 角色、个性、背景
|
||||
- **Communication Style** — 语调、声音、沟通方式
|
||||
- **Critical Rules** — 边界和约束
|
||||
|
||||
## Operations Group（操作相关）
|
||||
|
||||
- **Core Mission** — 主要职责
|
||||
- **Technical Deliverables** — 具体输出和模板
|
||||
- **Workflow Process** — 步骤化方法论
|
||||
- **Success Metrics** — 可衡量成果
|
||||
- **Advanced Capabilities** — 专业技巧
|
||||
|
||||
## Purpose
|
||||
|
||||
此结构支持 OpenClaw 工作区格式，并被 `convert.sh` 脚本用于自动拆分为特定工具格式。
|
||||
|
||||
## Relation to
|
||||
|
||||
- 由 [[AgentDesignPrinciples]] 定义的设计原则指导
|
||||
- 与 [[PersonaOperationsSplit]] 概念关联
|
||||
@@ -1,32 +0,0 @@
|
||||
---
|
||||
title: "Agentic AI"
|
||||
type: concept
|
||||
tags: [AI, Autonomous-AI, Agentic-AI]
|
||||
sources: [How-Agentic-AI-can-help-for-Cloud-DevOps, designing-for-agentic-ai]
|
||||
last_updated: 2026-04-18
|
||||
---
|
||||
|
||||
## Summary
|
||||
Agentic AI（智能体 AI）是指具备自主决策和任务执行能力的 AI 系统，能够在没有人类干预的情况下完成复杂任务。
|
||||
|
||||
## Definition
|
||||
具备自主决策、规划和执行能力的 AI 系统，可感知环境、制定计划并自动执行任务以达成目标。
|
||||
|
||||
## Key Characteristics
|
||||
- **自主决策**：无需人类干预即可做出决策
|
||||
- **任务执行**：自动执行多步骤复杂工作流
|
||||
- **环境感知**：感知和理解运行环境状态
|
||||
- **自我修复**：检测异常并自动修复问题
|
||||
- **持续学习**：从历史数据学习并优化决策
|
||||
|
||||
## Key Applications in Cloud DevOps
|
||||
- 自主事件检测与响应（MTTR 缩短）
|
||||
- 智能成本优化（动态扩缩、Spot 实例优化）
|
||||
- 自动化安全审计与合规执行
|
||||
- 智能日志分析与可观测性
|
||||
- AI 辅助决策（What-If 模拟）
|
||||
|
||||
## Connections
|
||||
- [[DevOps]] ← extends ← [[Agentic AI]]：Agentic AI 扩展 DevOps 自动化能力
|
||||
- [[Cloud Security]] ← enhanced_by ← [[Agentic AI]]：Agentic AI 增强云安全自动化
|
||||
- [[Auto-scaling]] ← extends ← [[Agentic AI]]：Agentic AI 提供更智能的动态扩缩
|
||||
@@ -1,42 +0,0 @@
|
||||
---
|
||||
title: "Alertmanager"
|
||||
type: concept
|
||||
tags: [alerting, prometheus, notification, devops]
|
||||
sources: [家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]
|
||||
last_updated: 2026-04-16
|
||||
---
|
||||
|
||||
## Definition
|
||||
Alertmanager 是 Prometheus 告警处理组件，负责接收 Prometheus server 发送的告警，进行抑制、分组后推送到各种通知渠道。
|
||||
|
||||
## Key Features
|
||||
- **抑制（Inhibition）**：避免冗余告警
|
||||
- **分组（Grouping）**：将相似告警合并
|
||||
- **路由（Routing）**：基于标签匹配发送到不同接收者
|
||||
- **通知渠道**：邮件、Slack、Teams、Telegram、PagerDuty、webhook 等
|
||||
|
||||
## Configuration Structure
|
||||
```yaml
|
||||
route:
|
||||
receiver: default
|
||||
group_wait: 10s
|
||||
group_interval: 5m
|
||||
repeat_interval: 3h
|
||||
|
||||
receivers:
|
||||
- name: default
|
||||
email_configs:
|
||||
- to: "example@example.com"
|
||||
```
|
||||
|
||||
## Common Notification Types
|
||||
- 邮件（email）
|
||||
- Slack
|
||||
- Microsoft Teams
|
||||
- Telegram
|
||||
- PagerDuty
|
||||
- Webhook
|
||||
|
||||
## Connections
|
||||
- [[Alertmanager]] ← receives_alerts ← [[Prometheus]]
|
||||
- [[Alertmanager]] → sends_notifications → [[Grafana]]（可选集成）
|
||||
@@ -1,26 +0,0 @@
|
||||
---
|
||||
title: "Amazon Bedrock"
|
||||
type: concept
|
||||
tags: [AWS, AI, generative-AI]
|
||||
sources: [public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machine-learning-20240206]
|
||||
last_updated: 2024-02-06
|
||||
---
|
||||
|
||||
## Summary
|
||||
Amazon Bedrock 是 AWS 提供的全托管服务，用于使用基础模型构建和扩展生成式 AI 应用。
|
||||
|
||||
## Definition
|
||||
Amazon Bedrock 是 AWS 的全托管服务，允许客户访问和定制强大的基础模型 (Foundation Models)，包括 Amazon Titan 和第三方模型，无需管理底层基础设施。
|
||||
|
||||
## Key Attributes
|
||||
- **类型**：AWS AI/ML 服务
|
||||
- **核心功能**：基础模型访问、微调、持续预训练、RAG、Agents
|
||||
- **数据安全**：数据仅在请求响应周期存储
|
||||
- **定制方法**：Fine-tuning、Continued Pre-training
|
||||
|
||||
## Connections
|
||||
- [[AWS]] ← provides ← [[Amazon Bedrock]]
|
||||
- [[Amazon Bedrock]] ← hosts ← [[Foundation Model]]
|
||||
- [[Amazon Bedrock]] ← implements ← [[RAG]]
|
||||
- [[Amazon Bedrock]] ← uses ← [[Agents]]
|
||||
- [[Generative AI]] ← powered_by ← [[Amazon Bedrock]]
|
||||
@@ -1,31 +0,0 @@
|
||||
---
|
||||
id: ambient-mode
|
||||
title: "Ambient Mode（环境模式）"
|
||||
type: concept
|
||||
tags: []
|
||||
aliases:
|
||||
- Ambient
|
||||
last_updated: 2026-04-17
|
||||
---
|
||||
|
||||
## Definition
|
||||
AI Agent 在后台被动监控环境（消息、日历、文件系统等），当检测到可执行事项时主动采取行动，无需用户主动请求。
|
||||
|
||||
## Why It Matters
|
||||
- 传统 AI 交互是"请求-响应"模式，用户必须明确告诉 AI 要做什么
|
||||
- Ambient Mode 实现"感知-行动"模式，AI 主动识别用户需求并提前处理
|
||||
- 本用例中：AI 监控 iMessage，发现牙医预约确认短信后自动创建日历事件并添加驾驶时间缓冲
|
||||
|
||||
## Use Cases
|
||||
- 日历自动创建（从消息中识别预约）
|
||||
- 待办事项提取（从邮件/对话中识别承诺）
|
||||
- 库存变化检测（从购物小票照片更新库存）
|
||||
|
||||
## Related Concepts
|
||||
- [[Cron-Jobs]]：定时任务调度
|
||||
- [[上下文记忆]]：保留对话历史
|
||||
- [[Preference-Learning]]：学习用户偏好
|
||||
|
||||
## Related Entities
|
||||
- [[OpenClaw]]：支持 Ambient Mode 的 AI Agent 平台
|
||||
- [[Mac-Mini]]：适合长期运行的设备
|
||||
@@ -1,48 +0,0 @@
|
||||
---
|
||||
title: "Anachronism"
|
||||
type: concept
|
||||
tags: [history, worldbuilding, validation]
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
时代错误（Anachronism）是指在历史背景中引入不属于该时期的人物、物体、观念或技术的错误。
|
||||
|
||||
## Two Types
|
||||
|
||||
### Obvious Anachronism（明显时代错误）
|
||||
- 哥伦布前的欧洲出现土豆
|
||||
- 古罗马使用电力
|
||||
- 中世纪欧洲出现印刷机（古腾堡印刷机约1440年）
|
||||
|
||||
### Subtle Anachronism（微妙时代错误）
|
||||
更难检测，通常涉及：
|
||||
- **Attitudes（态度）**：赋予古代人物现代价值观
|
||||
- **Social structures（社会结构）**：使用现代组织概念理解古代社会
|
||||
- **Economic systems（经济系统）**：用现代经济逻辑理解古代贸易
|
||||
- **Language（语言）**：使用后来才出现的词汇或表达方式
|
||||
|
||||
## Why It Matters
|
||||
- 破坏历史叙事的可信度
|
||||
- 反映对历史的误解或刻板印象
|
||||
- 强化流行的历史神话
|
||||
|
||||
## Academic Historian 的检测方法
|
||||
1. 建立坐标：时间和地点要精确
|
||||
2. 先检查物质基础：经济、技术、农业
|
||||
3. 再检查社会结构：权力、阶级、性别、宗教
|
||||
4. 评估声明的可信度：标注置信度
|
||||
|
||||
## Examples of Subtle Anachronism
|
||||
- 认为中世纪农民渴望"自由"（"自由"概念在工业革命后才普遍化）
|
||||
- 用现代"民族国家"概念理解古代帝国
|
||||
- 认为古代人物有现代意义上的"个人权利"概念
|
||||
|
||||
## Related Concepts
|
||||
- [[Historical Coherence Check]]：检测时代错误的工具
|
||||
- [[Period Authenticity Report]]：系统性避免时代错误的框架
|
||||
- [[Material Culture]]：物质文化是检测时代错误的基础
|
||||
- [[Presentism]]：现代价值观投射，是一种微妙时代错误
|
||||
|
||||
## Source
|
||||
Academic Historian Agent — The Agency 项目
|
||||
@@ -1,30 +0,0 @@
|
||||
---
|
||||
title: "Analytics Feedback Loop"
|
||||
type: concept
|
||||
tags: [marketing, data-analysis, optimization, ai-agent]
|
||||
sources: [marketing-carousel-growth-engine]
|
||||
last_updated: 2026-04-21
|
||||
---
|
||||
|
||||
## Definition
|
||||
数据驱动的持续优化循环，通过收集、分析和应用性能数据不断提升内容效果。
|
||||
|
||||
## Cycle Process
|
||||
1. **Fetch**：获取分析数据（Upload-Post API）
|
||||
2. **Extract**：提取洞察（表现最佳的 hook、发布时间、视觉风格）
|
||||
3. **Update**：更新 learnings.json 知识库
|
||||
4. **Plan**：规划下一个轮播内容
|
||||
|
||||
## Tracked Metrics
|
||||
- Hook 性能：问题型 vs 声明型 vs 痛点型
|
||||
- 发布时机：最佳日期/小时
|
||||
- 视觉风格：相关 slide prompts 与 engagement 关联
|
||||
- 参与率：likes + comments + shares / views
|
||||
|
||||
## Storage
|
||||
- `/tmp/carousel/learnings.json`
|
||||
- 滚动 100 期历史记录
|
||||
|
||||
## Aliases
|
||||
- 分析反馈循环
|
||||
- 数据驱动优化
|
||||
@@ -1,32 +0,0 @@
|
||||
---
|
||||
title: "Analytics Reporter"
|
||||
type: concept
|
||||
tags: []
|
||||
last_updated: 2026-04-21
|
||||
---
|
||||
|
||||
## Definition
|
||||
数据分析与商业智能专家智能体，将原始数据转化为可操作的业务洞察。
|
||||
|
||||
## Core Capabilities
|
||||
- 统计分析与假设检验
|
||||
- 仪表盘设计与 KPI 监控
|
||||
- RFM 客户分层分析
|
||||
- 营销归因建模
|
||||
- 预测模型构建（A/B 测试、流失预测、增长预测）
|
||||
|
||||
## Key Metrics
|
||||
- 分析准确率目标：95%+
|
||||
- 业务建议采纳率目标：70%+
|
||||
- 仪表盘月活用户：95%+
|
||||
- KPI 提升目标：20%+
|
||||
|
||||
## Related Concepts
|
||||
- [[Data-Driven Decision Making]]
|
||||
- [[RFM Analysis]]
|
||||
- [[Customer Lifetime Value]]
|
||||
- [[Statistical Significance Testing]]
|
||||
|
||||
## Source
|
||||
- [[support-analytics-reporter]]
|
||||
|
||||
@@ -1,48 +0,0 @@
|
||||
---
|
||||
title: "Annales School"
|
||||
type: concept
|
||||
tags: [history, historiography, methodology, france]
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
年鉴学派是20世纪法国最重要的史学运动之一，强调历史研究的跨学科方法，关注长时段、物质条件和结构力量，对全球史学产生深远影响。
|
||||
|
||||
## Historical Development
|
||||
### 第一代（1929-1946）
|
||||
- 创始人：马克·布洛赫（Marc Bloch）和吕西安·费弗尔（Lucien Febvre）
|
||||
- 期刊：《年鉴：物质文明、经济史和社会》（Annales d'histoire économique et sociale）
|
||||
|
||||
### 第二代（1950-1970）
|
||||
- 核心人物：费尔南·布罗代尔（Fernand Braudel）
|
||||
- 代表作：《菲利普二世时代的地中海和地中海世界》（1949）
|
||||
- 提出三层时间结构：地理时间、社会时间、事件时间
|
||||
|
||||
### 第三代（1970年代后）
|
||||
- 转向计量史、新文化史
|
||||
- 关注心态史、身体史、记忆史
|
||||
|
||||
## Core Principles
|
||||
1. **长时段（Longue Durée）**：历史变化发生在缓慢的时间尺度上
|
||||
2. **物质条件优先**：经济、技术、地理决定社会结构
|
||||
3. **跨学科**：融合地理学、经济学、社会学、人类学
|
||||
4. **反事件史**：批评过分关注政治事件和伟大人物
|
||||
|
||||
## Key Figures
|
||||
- 马克·布洛赫：《封建社会》（1939）
|
||||
- 吕西安·费弗尔：《16世纪的信奉问题》（1940）
|
||||
- 费尔南·布罗代尔：《地中海》（1949）、《资本主义与物质生活》（1967）
|
||||
- 雅克·勒高夫：《中世纪的身体与怜悯》（1974）
|
||||
|
||||
## Critical Reception
|
||||
- **贡献**：拓宽史学视野，强调结构和社会底层
|
||||
- **批评**：过度决定论，忽视人类能动性；欧洲中心主义倾向
|
||||
|
||||
## Related Concepts
|
||||
- [[Longue Durée]]：年鉴学派的核心方法论
|
||||
- [[Material Culture]]：年鉴学派的核心关注点
|
||||
- [[Microhistory]]：作为对年鉴学派的回应而兴起
|
||||
- [[Academic Historian]]：Academic Historian 的方法论工具
|
||||
|
||||
## Source
|
||||
《年鉴》杂志，费弗尔和布洛赫创办（1929）
|
||||
@@ -1,42 +0,0 @@
|
||||
---
|
||||
title: "Attachment Theory"
|
||||
type: concept
|
||||
tags: [developmental-psychology, relationships, attachment]
|
||||
sources: []
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
# Attachment Theory
|
||||
|
||||
## Aliases
|
||||
- 依恋理论
|
||||
- 依恋风格
|
||||
- Attachment Style
|
||||
|
||||
## Summary
|
||||
John Bowlby 提出的发展心理学理论，描述亲子间的情感纽带如何影响个体的成人关系模式。Mary Ainsworth 通过陌生情境实验识别出三种幼儿依恋类型，后扩展为四种成人依恋风格。
|
||||
|
||||
## Core Concepts
|
||||
### 依恋风格分类
|
||||
- **安全型（Secure）**：信任他人，舒适亲密关系，能依赖也能独立
|
||||
- **焦虑-先占型（Anxious-Preoccupied）**：过度依赖，害怕被抛弃，高度情绪化
|
||||
- **回避-忽视型（Dismissive-Avoidant）**：情感隔离，贬低亲密价值，强调独立
|
||||
- **恐惧-回避型（Fearful-Avoidant）**：既渴望又恐惧亲密，关系中犹豫不决
|
||||
|
||||
### 核心机制
|
||||
- 内在运作模型（Internal Working Model）：基于早期经历形成的自我和他人的心理表征
|
||||
- 依恋对象的可及性（Attachment Figure's Accessibility）
|
||||
|
||||
## Applications
|
||||
- [[Academic Psychologist Agent]] 分析浪漫、家庭、友谊关系动态
|
||||
- 识别角色触发点和冲突升级模式
|
||||
- 设计可信的角色发展弧线
|
||||
|
||||
## Cultural Considerations
|
||||
- 依恋理论源于西方个体主义语境
|
||||
- 集体主义文化中"健康"依恋模式可能呈现不同表现
|
||||
|
||||
## Connections
|
||||
- [[Academic Psychologist Agent]] ← 分析框架 ← [[依恋理论]]
|
||||
- [[Big Five Personality Framework]] ← 互补框架 ← [[依恋理论]]
|
||||
- [[John Bowlby]] ← 理论创始人 ← [[依恋理论]]
|
||||
@@ -1,26 +0,0 @@
|
||||
---
|
||||
title: "Audience Engineering"
|
||||
type: concept
|
||||
tags: [advertising, audience, targeting, paid-media]
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
受众工程（Audience Engineering）是基于数据构建精准定向策略的过程，包括自定义受众创建、相似受众扩展和受众分层。
|
||||
|
||||
## Key Techniques
|
||||
- **Pixel-based Custom Audiences**：基于网站 Pixel 的用户行为数据构建
|
||||
- **CRM List Uploads**：上传 CRM 客户列表进行定向
|
||||
- **Engagement Audiences**：基于互动行为（视频观看、页面访问、表单开启）的受众
|
||||
- **Exclusion Strategy**：排除已转化用户，避免浪费预算
|
||||
- **Audience Overlap Analysis**：分析跨平台受众重叠，避免频次超限
|
||||
|
||||
## Audience Types
|
||||
- 自定义受众（Custom Audience）：基于种子用户的精确定向
|
||||
- 相似受众（Lookalike Audience）：基于种子用户扩展的相似受众
|
||||
- 兴趣定向受众（Interest Audience）：基于平台兴趣分类的泛定向
|
||||
|
||||
## Connections
|
||||
- [[Audience Engineering]] ← requires ← [[Custom Audience]]
|
||||
- [[Audience Engineering]] ← extends ← [[Lookalike Audience]]
|
||||
- [[Full-Funnel Advertising]] ← uses ← [[Audience Engineering]]
|
||||
@@ -1,30 +0,0 @@
|
||||
---
|
||||
title: "Audit Readiness"
|
||||
type: concept
|
||||
tags: [compliance, audit, security]
|
||||
---
|
||||
|
||||
## 定义
|
||||
评估组织当前安全态势是否符合目标框架（如 SOC 2、ISO 27001、HIPAA、PCI-DSS）要求的状态。
|
||||
|
||||
## 目的
|
||||
提供领导层对认证时间线的真实可见性，识别需要修复的控制差距。
|
||||
|
||||
## 组成部分
|
||||
- 当前安全态势评估
|
||||
- 控制差距识别
|
||||
- 优先修复计划
|
||||
- 就绪度评分卡
|
||||
|
||||
## 关键原则
|
||||
- 每个差距发现必须包含：具体控制参考、当前状态、目标状态、修复步骤、估计工作量
|
||||
- 就绪度评分应基于实际测试，而非仅文档审查
|
||||
|
||||
## 相关框架
|
||||
- [[SOC-2]]
|
||||
- [[ISO-27001]]
|
||||
- [[HIPAA]]
|
||||
- [[PCI-DSS]]
|
||||
|
||||
## 相关实体
|
||||
- [[Compliance Auditor]]
|
||||
@@ -1,22 +0,0 @@
|
||||
---
|
||||
title: "Audit Trail"
|
||||
type: concept
|
||||
tags: [compliance, audit, operations]
|
||||
sources: [accounts-payable-agent]
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
Audit Trail 是记录关键操作、决策与结果的可追溯日志，通常包含对象、金额、时间、状态和执行主体。
|
||||
|
||||
## Core Principles
|
||||
- 每个关键动作都应可回放与审计
|
||||
- 记录应尽量完整、结构化且不可歧义
|
||||
- 支持事后核查、对账和责任归属
|
||||
- 审计记录应避免遗漏审批上下文
|
||||
|
||||
## Related Entities
|
||||
- [[Accounts Payable Agent]]
|
||||
- [[Agentic Identity & Trust Architect]]
|
||||
- [[Sales Data Extraction Agent]]
|
||||
- [[The Agency]]
|
||||
@@ -1,20 +0,0 @@
|
||||
---
|
||||
title: "Auto Healing"
|
||||
type: concept
|
||||
tags: [deployment, reliability, self-recovery]
|
||||
sources: []
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
Auto Healing（自动修复）是云原生系统的核心能力，自动检测故障并恢复服务，无需人工干预即可恢复正常运行状态。
|
||||
|
||||
## Rationale
|
||||
- 提高系统可用性
|
||||
- 减少人工干预
|
||||
- 缩短故障恢复时间
|
||||
|
||||
## Related Concepts
|
||||
- [[ECS (Elastic Container Services)]]
|
||||
- [[Auto Scaling]]
|
||||
- [[Infrastructure as Code (IaC)]]
|
||||
@@ -1,25 +0,0 @@
|
||||
---
|
||||
title: Auto-scaling
|
||||
type: concept
|
||||
tags: [Cloud, Cost-Optimization, Elasticity]
|
||||
sources: [The-Myths-and-Misconceptions-About-Cloud-Computing-LinkedIn.md, How-Agentic-AI-can-help-for-Cloud-DevOps]
|
||||
last_updated: 2025-03-02
|
||||
---
|
||||
|
||||
## Definition
|
||||
自动扩展（Auto-scaling）是一种根据实时负载自动调整计算资源的技术，确保系统在高峰期有足够资源，在低峰期避免资源浪费。
|
||||
|
||||
## Core Features
|
||||
- 动态资源分配：根据负载自动增减实例
|
||||
- 成本优化：在低需求时自动缩减资源
|
||||
- 性能保障：在高负载时自动扩容
|
||||
- 预测性扩展：基于历史数据预测未来需求
|
||||
|
||||
## Key Claims
|
||||
- 自动扩展是降低云成本的关键策略之一
|
||||
- 云平台提供灵活的定价，配合自动扩展帮助企业实现成本效益
|
||||
|
||||
## Connections
|
||||
- [[Pay-as-you-go]] ← optimizes ← [[Auto-scaling]]：自动扩展优化按需付费成本
|
||||
- [[Cloud-Native]] ← uses ← [[Auto-scaling]]：云原生应用广泛使用自动扩展
|
||||
- [[IaaS]] ← provides ← [[Auto-scaling]]：IaaS 提供自动扩展功能
|
||||
@@ -1,30 +0,0 @@
|
||||
---
|
||||
title: "Autonomous QA"
|
||||
type: concept
|
||||
tags: [ai, quality-assurance, vision, automation]
|
||||
sources: [marketing-carousel-growth-engine]
|
||||
last_updated: 2026-04-21
|
||||
---
|
||||
|
||||
## Definition
|
||||
自主质量保证系统，通过视觉模型验证每张生成的幻灯片，仅重生成不合格的幻灯片。
|
||||
|
||||
## Verification Criteria
|
||||
- 文字可读性
|
||||
- 拼写准确性
|
||||
- 视觉质量
|
||||
- 底部 20% 无文字覆盖
|
||||
|
||||
## Process
|
||||
1. Agent 使用视觉模型检查每张幻灯片
|
||||
2. 任何失败仅重生成该幻灯片（保留 slide-1.jpg 作为参考）
|
||||
3. 重新验证直到全部通过
|
||||
4. 零人工干预
|
||||
|
||||
## Technical Stack
|
||||
- Vision Model：Agent 内置视觉能力
|
||||
- Gemini：仅重生成失败幻灯片
|
||||
|
||||
## Aliases
|
||||
- 自主质量保证
|
||||
- Vision-Based Verification
|
||||
@@ -1,28 +0,0 @@
|
||||
---
|
||||
title: Awesome Claude Skills
|
||||
type: concept
|
||||
tags: []
|
||||
---
|
||||
|
||||
## Definition
|
||||
Awesome Claude Skills 是一类系统性整理各类标准化 "LLM Skills" 工作流的精选 GitHub 仓库。
|
||||
|
||||
## Repositories
|
||||
- ComposioHQ/awesome-claude-skills
|
||||
- VoltAgent/awesome-claude-skills
|
||||
- BehiSecc/awesome-claude-skills
|
||||
|
||||
## Coverage
|
||||
涵盖以下类别：
|
||||
- 文档处理
|
||||
- 开发工具
|
||||
- 数据分析
|
||||
- 内容创作
|
||||
- 生产力工具
|
||||
|
||||
## Usage
|
||||
可以系统性扫一遍这些仓库，找灵感、找模式，用于构建自己的 Skills。
|
||||
|
||||
## Related
|
||||
- [[Claude Skills]]
|
||||
- [[GitHub]]
|
||||
@@ -1,22 +0,0 @@
|
||||
---
|
||||
title: "Azure Cloud Adoption Framework"
|
||||
type: concept
|
||||
tags: [Cloud, Framework, Azure]
|
||||
sources: [Cloud-Maturity-Model-A-Detailed-Guide-For-Cloud-Adoption]
|
||||
last_updated: 2025-02-28
|
||||
---
|
||||
|
||||
## Summary
|
||||
Azure Cloud Adoption Framework（Azure CAF）是微软 Azure 的云采纳框架，提供针对 Azure 的指导和最佳实践。
|
||||
|
||||
## Definition
|
||||
Azure CAF 使组织能够采用云技术并有信心地实现业务目标。
|
||||
|
||||
## Key Capabilities
|
||||
- 针对 Azure 的定制指导
|
||||
- 最佳实践
|
||||
- 业务目标对齐
|
||||
- 迁移支持
|
||||
|
||||
## Connections
|
||||
- [[Azure-Cloud-Adoption-Framework]] ← extends ← [[Cloud-Maturity-Model]]
|
||||
@@ -1,25 +0,0 @@
|
||||
---
|
||||
title: "B2B Social Selling"
|
||||
type: concept
|
||||
tags: [marketing, sales, b2b]
|
||||
---
|
||||
|
||||
## Definition
|
||||
面向企业客户的社交销售策略，通过 LinkedIn 等专业平台建立关系、培育潜在客户并推动销售漏斗转化。
|
||||
|
||||
## Core Tactics
|
||||
- **LinkedIn Mastery**: 公司页面、个人品牌、文章、新闻通讯、广告
|
||||
- **Professional Networking**: 行业群组参与、合作伙伴开发、B2B 社区建设
|
||||
- **Social Selling Playbook**: 销售团队社交内容策略和参与指南
|
||||
|
||||
## Performance Targets
|
||||
- LinkedIn 公司页面参与率 3%+
|
||||
- 50%+ 帖子达到平台基准
|
||||
- 可衡量的渠道贡献线索
|
||||
|
||||
## Related Concepts
|
||||
- [[Thought Leadership]]
|
||||
- [[Cross-Platform Strategy]]
|
||||
|
||||
## Source
|
||||
- [[Social Media Strategist]]
|
||||
@@ -1,23 +0,0 @@
|
||||
---
|
||||
title: "BCG Pyramid Principle"
|
||||
type: concept
|
||||
tags: [consulting, strategic-communication, framework]
|
||||
sources: []
|
||||
last_updated: 2026-04-21
|
||||
---
|
||||
|
||||
## Definition
|
||||
波士顿咨询集团的自上而下逻辑表达原则，先给出核心论点再分层展开支撑论据
|
||||
|
||||
## Core Concept
|
||||
- **核心论点（Key Message）**：首先传达最重要的结论
|
||||
- **支撑论据（Supporting Arguments）**：按重要性排序的次级论点
|
||||
- **数据支撑（Data/Evidence）**：每项论据的具体证据
|
||||
|
||||
## Application
|
||||
用于 Executive Summary Generator 的第二步"关键发现"，确保发现按业务影响排序
|
||||
|
||||
## Related Concepts
|
||||
- [[McKinsey SCQA Framework]]
|
||||
- [[Bain Action-Oriented Model]]
|
||||
- [[Executive Summary]]
|
||||
@@ -1,20 +0,0 @@
|
||||
---
|
||||
title: "BM25"
|
||||
type: concept
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-17
|
||||
---
|
||||
|
||||
## Definition
|
||||
BM25（Best Matching 25）是一种基于关键词的全文搜索算法，用于信息检索。
|
||||
|
||||
## Principle
|
||||
基于词频（TF）和逆文档频率（IDF）计算关键词与文档的相关度评分。
|
||||
|
||||
## Use Case
|
||||
- 与向量嵌入结合实现混合搜索，通过 RRF reranking 合并结果
|
||||
|
||||
## Aliases
|
||||
- BM25
|
||||
- Okapi BM25
|
||||
@@ -1,29 +0,0 @@
|
||||
---
|
||||
title: "BOOTSTRAP.md"
|
||||
type: concept
|
||||
tags: [OpenClaw, Agent]
|
||||
---
|
||||
|
||||
## 定义
|
||||
BOOTSTRAP.md 是 OpenClaw workspace 中的首次启动引导文件，是一次性使用组件，使命是将全新 workspace 引导到"可正常使用"的状态。
|
||||
|
||||
## 职责
|
||||
BOOTSTRAP.md 引导 Agent 完成以下初始化步骤：
|
||||
1. 和用户聊几句，搞清楚 Agent 应该叫什么名字、是什么性格、用什么 emoji
|
||||
2. 把结果写进 IDENTITY.md
|
||||
3. 记录用户的基本信息到 USER.md
|
||||
4. 一起打开 SOUL.md，把真正的性格和边界写进去
|
||||
5. （可选）引导用户接入渠道（WhatsApp、Telegram 等）
|
||||
|
||||
## 关键特性
|
||||
- **一次性**：官方模板会要求 Agent 在完成初始化后把它删除
|
||||
- 官方模板最后一句话："Delete this file. You don't need a bootstrap script anymore — you're you now."
|
||||
|
||||
## 来源
|
||||
- [[万字讲透OpenClaw🦞从"能用"到"真好用"的分水岭：Workspace 深度解析]]
|
||||
|
||||
## 相关
|
||||
- [[IDENTITY.md]]：初始化时创建的身份元数据
|
||||
- [[USER.md]]：初始化时创建的用户画像
|
||||
- [[SOUL.md]]：初始化时创建的的性格文档
|
||||
- [[Workspace]]：包含 BOOTSTRAP.md 的工作台目录
|
||||
@@ -1,40 +0,0 @@
|
||||
# BOSCARD
|
||||
|
||||
> BOSCARD 是定义复杂新工作的技术，通过系统化方式明确项目的背景、目标、范围、约束、假设、风险、角色和可交付成果。
|
||||
|
||||
## 定义
|
||||
|
||||
BOSCARD 各要素含义：
|
||||
|
||||
| 要素 | 全称 | 说明 |
|
||||
|------|------|------|
|
||||
| B | Background | 项目背景，解释为什么存在这个项目 |
|
||||
| O | Objectives | 项目目标，期望达成的成果 |
|
||||
| S | Scope | 项目范围，涵盖和不涵盖的内容 |
|
||||
| C | Constraints | 约束条件，如时间、预算、资源限制 |
|
||||
| A | Assumptions | 假设前提，项目成功的前提条件 |
|
||||
| R | Risks | 风险识别，可能影响项目的因素 |
|
||||
| R | Roles | 角色分工，项目成员职责 |
|
||||
| D | Deliverables | 可交付成果，项目产出的具体内容 |
|
||||
|
||||
## 应用场景
|
||||
|
||||
- 项目启动前的需求定义
|
||||
- 变更请求的评估
|
||||
- 新技术引入的可行性分析
|
||||
- 跨部门协作的范围界定
|
||||
|
||||
## 与敏捷的结合
|
||||
|
||||
BOSCARD 在敏捷环境中可作为史诗（Epic）或大型用户故事的补充文档，帮助团队在迭代开始前对复杂工作有全面理解。
|
||||
|
||||
## 起源
|
||||
|
||||
BOSCARD 源自业务分析领域，是将传统需求分析技术应用于现代项目管理的方法之一。
|
||||
|
||||
## 相关术语
|
||||
|
||||
- [[RACI 图]]：责任分配矩阵
|
||||
- [[用户故事 (User Stories)]]：以"谁、什么、为什么"格式捕获需求
|
||||
- [[SAFe (Scaled Agile Framework)]]：大规模敏捷框架
|
||||
- [[相关方轮盘 (Stakeholder Wheel)]]：识别项目相关方的方法论
|
||||
@@ -1,18 +0,0 @@
|
||||
---
|
||||
title: "BYOD"
|
||||
type: concept
|
||||
tags: []
|
||||
---
|
||||
|
||||
## Definition
|
||||
Bring Your Own Device，自带设备。允许员工使用个人设备（笔记本、手机、平板）访问企业资源的工作模式。
|
||||
|
||||
## Security Considerations
|
||||
- 终端数据保护
|
||||
- 企业数据与个人数据隔离
|
||||
- 远程擦除能力
|
||||
- 多因素认证
|
||||
|
||||
## Related Concepts
|
||||
- [[VDI]]
|
||||
- [[SAML]]
|
||||
@@ -1,22 +0,0 @@
|
||||
---
|
||||
title: "Barthes 五代码"
|
||||
type: concept
|
||||
tags: [narrative-theory, semiotics, meaning-codes]
|
||||
---
|
||||
|
||||
## 定义
|
||||
Roland Barthes 在《S/Z》中提出的叙事符号学框架，将文本意义分解为五个代码系统。
|
||||
|
||||
## 五个代码
|
||||
1. **Hermeneutic Code（谜团代码）**：制造和延迟揭示谜底的问题序列
|
||||
2. **Proairetic Code（行为代码）**：行动结果的序列，标识接下来会发生什么
|
||||
3. **Semantic Code（语义代码）**：意义层次的标记，揭示角色的社会、心理属性
|
||||
4. **Symbolic Code（象征代码）**：通过反复出现形成更深层主题的意象
|
||||
5. **Cultural Code（文化代码）**：引用社会、历史、科学、文学等共同知识的代码
|
||||
|
||||
## 核心方法
|
||||
- **Les cinq codes**：将叙事文本分解为五种意义生成路径
|
||||
- **Lexies（lexia）**：最小叙事单元，每个lexia可归属不同代码
|
||||
|
||||
## 来源框架
|
||||
- [[Narratologist]] 使用此框架进行 semiotic analysis of narrative meaning
|
||||
@@ -1,18 +0,0 @@
|
||||
---
|
||||
title: "BibTeX/BibLaTeX"
|
||||
type: concept
|
||||
tags: []
|
||||
last_updated: 2026-04-17
|
||||
---
|
||||
|
||||
## Definition
|
||||
BibTeX 和 BibLaTeX 是 LaTeX 文档中管理参考文献的格式系统，通过 .bib 文件存储文献条目。
|
||||
|
||||
## Mechanism
|
||||
- .bib 文件包含文献条目（作者、标题、年份、期刊等）
|
||||
- 编译时通过 \cite{key} 引用
|
||||
- 支持多种引用风格（APA、IEEE、Harvard 等）
|
||||
|
||||
## Connections
|
||||
- [[LaTeX编译]]：引用解析依赖编译过程
|
||||
- [[LaTeX模板]]：模板决定引用样式
|
||||
@@ -1,38 +0,0 @@
|
||||
---
|
||||
title: "Big Five Personality Framework"
|
||||
type: concept
|
||||
tags: [personality-psychology, big-five, trait-theory]
|
||||
sources: []
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
# Big Five Personality Framework
|
||||
|
||||
## Aliases
|
||||
- 大五人格框架
|
||||
- Five-Factor Model (FFM)
|
||||
- OCEAN Model
|
||||
|
||||
## Summary
|
||||
描述人格结构的五因素模型，通过开放性、尽责性、外向性、宜人性、神经质五个维度评估个体差异，是人格心理学中经验支持最充分的框架之一。
|
||||
|
||||
## Core Dimensions
|
||||
- **Openness（开放性）**：想象力、好奇心、审美能力
|
||||
- **Conscientiousness（尽责性）**：自律、条理性、成就导向
|
||||
- **Extraversion（外向性）**：社交性、活力、主导性
|
||||
- **Agreeableness（宜人性）**：信任、利他、顺从
|
||||
- **Neuroticism（神经质）**：情绪不稳定、焦虑、抑郁倾向
|
||||
|
||||
## Applications
|
||||
- [[Academic Psychologist Agent]] 角色心理画像核心框架
|
||||
- 评估角色行为一致性
|
||||
- 预测角色在压力下的反应模式
|
||||
|
||||
## Limitations
|
||||
- 描述性而非解释性（不说明人格如何形成）
|
||||
- 文化偏差：某些特质在不同文化中内涵不同
|
||||
- 过度简化：五因素可能遗漏重要特质
|
||||
|
||||
## Connections
|
||||
- [[Academic Psychologist Agent]] ← 分析框架 ← [[Big Five Personality Framework]]
|
||||
- [[依恋理论]] ← 互补框架 ← [[Big Five Personality Framework]]
|
||||
@@ -1,28 +0,0 @@
|
||||
---
|
||||
title: "Bind Mount"
|
||||
type: concept
|
||||
tags: [docker, volume]
|
||||
---
|
||||
|
||||
## 定义
|
||||
Bind Mount（绑定挂载）是 Docker 的一种卷挂载方式，将宿主机上的文件或目录直接映射到容器内部，实现宿主机与容器间的文件共享。
|
||||
|
||||
## 工作原理
|
||||
- 将宿主机目录 `/home/user/project` 挂载到容器内的 `/app`
|
||||
- 宿主机上的文件修改可实时反映到容器内
|
||||
- 容器内生成的文件可直接在宿主机访问
|
||||
|
||||
## 应用场景
|
||||
- 开发环境：代码修改实时生效，无需重新构建镜像
|
||||
- 日志收集：容器日志直接写入宿主机目录
|
||||
- 配置文件：共享配置文件
|
||||
|
||||
## 优点
|
||||
- 实现代码修改实时生效
|
||||
- 无需重新构建镜像即可测试代码变更
|
||||
- 便于调试和迭代开发
|
||||
|
||||
## 关联概念
|
||||
- [[Docker]]：容器化平台
|
||||
- [[docker-compose.yml]]：Docker Compose 配置
|
||||
- [[Volume]]：Docker 持久化数据的另一种方式
|
||||
@@ -1,29 +0,0 @@
|
||||
---
|
||||
title: "Bird Skill"
|
||||
type: concept
|
||||
tags: [ai-agent, automation, social-media]
|
||||
last_updated: 2026-04-17
|
||||
---
|
||||
|
||||
## Definition
|
||||
Bird Skill 是 OpenClaw 内置的 X/Twitter 操作技能，用于获取和分析用户推文数据。
|
||||
|
||||
## Capabilities
|
||||
- 获取指定用户的最近 N 条推文
|
||||
- 分析推文模式和质量
|
||||
- 支持定性分析而非仅定量统计
|
||||
|
||||
## Technical Details
|
||||
- 安装方式：`clawhub install bird` 或预置（`it comes pre-bundled`）
|
||||
- 依赖：需要提供 X 账户的 Cookie 信息（`auth-token`、`ct0`）
|
||||
|
||||
## Related Concepts
|
||||
- [[TweetClaw]] — X/Twitter 自动化插件，提供更完整的操作能力
|
||||
- [[OpenClaw]] — Bird Skill 的宿主工具
|
||||
|
||||
## Related Entities
|
||||
- [[OpenClaw]] — AI Agent 管理工具
|
||||
|
||||
## Notes
|
||||
- Bird Skill 侧重于数据获取和分析
|
||||
- TweetClaw 侧重于操作执行（发推、互动、抽奖等）
|
||||
@@ -1,48 +0,0 @@
|
||||
---
|
||||
title: "Blackbox_exporter"
|
||||
type: concept
|
||||
tags: [exporter, prometheus, blackbox, monitoring]
|
||||
sources: [家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]
|
||||
last_updated: 2026-04-16
|
||||
---
|
||||
|
||||
## Definition
|
||||
Blackbox_exporter 是 Prometheus 官方提供的黑盒探测 exporter，通过 HTTP、HTTPS、TCP、ICMP、DNS 等协议探测目标可用性和性能。
|
||||
|
||||
## Supported Modules
|
||||
- **HTTP/HTTPS**：探测状态码、响应时间、TLS 证书
|
||||
- **TCP**：端口连通性
|
||||
- **ICMP**：主机可达性（ping）
|
||||
- **DNS**：域名解析
|
||||
|
||||
## Use Cases
|
||||
- 网站可用性监控
|
||||
- TLS 证书到期告警
|
||||
- DNS 解析监控
|
||||
- 内网服务健康检查
|
||||
|
||||
## Key Metrics
|
||||
- `probe_success`：探测是否成功（0/1）
|
||||
- `probe_duration_seconds`：探测耗时
|
||||
- `probe_http_status_code`：HTTP 状态码
|
||||
- `probe_ssl_earliest_cert_expiry`：SSL 证书到期时间
|
||||
|
||||
## Common Alert Rules
|
||||
- HTTP 探测失败（连续 3 次）
|
||||
- TLS 证书剩余 < 14 天
|
||||
- 响应时间 > 阈值
|
||||
|
||||
## Docker 部署
|
||||
```yaml
|
||||
blackbox:
|
||||
image: prom/blackbox-exporter:latest
|
||||
ports:
|
||||
- "9115:9115"
|
||||
```
|
||||
|
||||
## Default Port
|
||||
- 9115
|
||||
|
||||
## Connections
|
||||
- [[Blackbox_exporter]] ← scrapes_by ← [[Prometheus]]
|
||||
- [[Blackbox_exporter]] ← blackbox_monitoring ← [[Uptime Kuma]]（可选集成）
|
||||
@@ -1,22 +0,0 @@
|
||||
---
|
||||
title: "Bloom's Taxonomy"
|
||||
type: concept
|
||||
tags: [instructional-design, learning-objectives]
|
||||
sources: []
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
对学习目标进行分类的认知层级框架，由 Benjamin Bloom 提出，用于指导学习目标设计和评估标准制定。
|
||||
|
||||
## Six Cognitive Levels
|
||||
1. **Remember（记忆）**：识记事实、定义、概念
|
||||
2. **Understand（理解）**：解释含义、总结内容
|
||||
3. **Apply（应用）**：将知识用于新情境
|
||||
4. **Analyze（分析）**：分解结构、识别关系
|
||||
5. **Evaluate（评估）**：判断价值、做决策
|
||||
6. **Create（创造）**：生成新知识或产品
|
||||
|
||||
## Related Concepts
|
||||
- [[ADDIE 模型]]：课程设计框架
|
||||
- [[Kirkpatrick 四级评估模型]]：效果评估
|
||||
@@ -1,41 +0,0 @@
|
||||
---
|
||||
title: "Book Co-Author Agent"
|
||||
type: concept
|
||||
tags: [agent, writing, the-agency]
|
||||
sources: [sources/workflow-book-chapter.md]
|
||||
last_updated: 2026-04-21
|
||||
---
|
||||
|
||||
## 定义
|
||||
The Agency 项目中的书籍共创智能体，将源素材（语音笔记、片段、战略笔记）转化为版本化章节草稿，并附带编辑注释和下一步问题。
|
||||
|
||||
## 核心职责
|
||||
- 将粗糙素材转化为战略性第一人称书籍章节草稿
|
||||
- 保持作者声音一致性
|
||||
- 强化品类定位
|
||||
- 暴露开放编辑决策
|
||||
|
||||
## 工作流程
|
||||
1. 接收原始素材（voice memo、notes、story fragment、positioning angle）
|
||||
2. 产出章节目标和战略角色
|
||||
3. 提出澄清问题
|
||||
4. 生成版本化草稿
|
||||
5. 提供编辑注释（假设和证据缺口）
|
||||
6. 明确下一步修订请求
|
||||
|
||||
## 输出格式
|
||||
1. Target Outcome（目标结果）
|
||||
2. Chapter Draft（章节草稿）
|
||||
3. Editorial Notes（编辑注释）
|
||||
4. Feedback Loop（反馈循环）
|
||||
5. Next Step（下一步）
|
||||
|
||||
## 质量标准
|
||||
- 草稿保持第一人称声音
|
||||
- 章节有一个清晰的承诺和内部逻辑
|
||||
- 声明与源素材关联或标记为假设
|
||||
- 移除通用激励语言
|
||||
- 输出以明确修订问题结束
|
||||
|
||||
## Aliases
|
||||
- Book Co-Author
|
||||
@@ -1,19 +0,0 @@
|
||||
---
|
||||
title: "Bootable USB"
|
||||
type: concept
|
||||
tags: [usb, boot, recovery, storage]
|
||||
date: 2026-04-16
|
||||
---
|
||||
|
||||
## Definition
|
||||
可启动 USB（Bootable USB）是一种将操作系统或恢复工具（如 Clonezilla）写入 U 盘，使其可从 BIOS/UEFI 启动的存储介质。用于系统安装、修复或备份恢复场景。
|
||||
|
||||
## Related Concepts
|
||||
- [[Clonezilla]]：通过 Bootable USB 提供磁盘镜像备份功能
|
||||
- [[Rufus]]：制作 Bootable USB 的工具
|
||||
- [[灾难恢复]]：Bootable USB 在灾难恢复流程中的作用
|
||||
|
||||
## Use Cases
|
||||
- 系统重装：从 USB 启动安装操作系统
|
||||
- 磁盘备份：使用 Clonezilla Live USB 进行全盘镜像备份
|
||||
- 系统修复：使用 Windows PE 或 Linux rescue USB 修复系统故障
|
||||
@@ -1,26 +0,0 @@
|
||||
---
|
||||
title: "Bot（智能体）"
|
||||
type: concept
|
||||
tags: [ai, 智能体, 对话]
|
||||
---
|
||||
|
||||
## Description
|
||||
Bot（智能体）在 Coze 平台中指对话型 AI 智能体，是最基础的智能体开发模式。用户通过自然语言与 Bot 对话，Bot 根据预设的提示词和知识库生成回复。Bot 模式适合快速创建轻量级对话应用。
|
||||
|
||||
## Key Features
|
||||
- **自然语言对话**：用户通过自然语言与 Bot 交互
|
||||
- **提示词配置**：通过编写提示词定义 Bot 的行为和角色
|
||||
- **知识库集成**：可挂载知识库实现 RAG（检索增强生成）
|
||||
- **插件扩展**：支持调用外部插件扩展能力
|
||||
- **对话历史**：支持多轮对话上下文记忆
|
||||
|
||||
## Use Cases
|
||||
- 智能客服
|
||||
- 问答助手
|
||||
- 内容创作
|
||||
- 教育辅导
|
||||
|
||||
## Related
|
||||
- [[Coze（扣子）]] — Bot 所在的开发平台
|
||||
- [[Coze Workflow]] — Coze 的另一种开发模式
|
||||
- [[RAG]] — 检索增强生成技术
|
||||
@@ -1,40 +0,0 @@
|
||||
---
|
||||
id: boto3
|
||||
title: "Boto3"
|
||||
type: concept
|
||||
tags:
|
||||
- AWS
|
||||
- Python
|
||||
- SDK
|
||||
last_updated: 2026-04-18
|
||||
---
|
||||
|
||||
## Summary
|
||||
AWS SDK for Python，用于通过 Python 代码与 AWS 服务交互。
|
||||
|
||||
## Definition
|
||||
Boto3 是 Amazon 官方提供的 Python SDK，允许开发者通过 Python 代码调用 AWS API，管理 AWS 资源和服务。
|
||||
|
||||
## Key Attributes
|
||||
- **类型**：AWS SDK
|
||||
- **语言**：Python
|
||||
- **安装方式**：pip install boto3
|
||||
- **认证方式**：IAM 凭证、环境变量、AWS CLI 配置
|
||||
|
||||
## Core Concepts
|
||||
|
||||
### Clients vs Resources
|
||||
- **Clients**：底层服务 API，提供精确控制
|
||||
- **Resources**：高层次、面向对象的抽象
|
||||
|
||||
### Waiters
|
||||
自动轮询服务响应直到特定状态
|
||||
|
||||
### Paginators
|
||||
自动处理分页结果
|
||||
|
||||
## Common Use Cases
|
||||
- 扫描 EC2 实例、安全组、负载均衡器
|
||||
- 创建、修改、删除 S3 存储桶
|
||||
- 触发 Lambda 函数
|
||||
- 查询 CloudWatch 指标
|
||||
@@ -1,24 +0,0 @@
|
||||
---
|
||||
title: "BottleRocket"
|
||||
description: EKS Auto Mode 使用的 Linux 操作系统，专为容器工作负载优化
|
||||
type: concept
|
||||
tags:
|
||||
- AWS
|
||||
- EKS
|
||||
- Operating-System
|
||||
---
|
||||
|
||||
## Definition
|
||||
BottleRocket 是 AWS 开发的 Linux 操作系统，专为容器工作负载设计，被 EKS Auto Mode 采用作为默认操作系统。它支持自动化补丁管理和安全更新。
|
||||
|
||||
## Features
|
||||
- 专为容器优化的轻量级 OS
|
||||
- 自动化补丁管理和安全更新
|
||||
- 与 EKS Auto Mode 深度集成
|
||||
|
||||
## Relationship
|
||||
- 由 [[Carpenter]] 管理
|
||||
- 运行在 [[EKS-Auto-Mode]] 集群节点上
|
||||
|
||||
## References
|
||||
- [[public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks-auto-mode]]
|
||||
@@ -1,37 +0,0 @@
|
||||
---
|
||||
title: "Bottlerocket OS"
|
||||
type: concept
|
||||
tags: [AWS, Container, Operating-System, Security]
|
||||
date: 2026-04-19
|
||||
---
|
||||
|
||||
## Definition
|
||||
Bottlerocket OS 是专为托管容器工作负载而设计的最小化 Linux 操作系统，与通用操作系统不同，仅包含必要组件。
|
||||
|
||||
## Key Characteristics
|
||||
- **最小化设计**：无包管理器、无默认 shell 解释器、无默认 SSH 访问，仅包含必要的内核组件
|
||||
- **变体机制**：通过变体满足特定工作负载需求（如 GPU 支持）
|
||||
- **安全更新**：原地更新和节点替换两种方式，使用 dm-verity 验证根文件系统完整性
|
||||
- **不可变根文件系统**：根文件系统默认不可变，/etc 是临时文件系统
|
||||
- **SELinux**：默认强制启用
|
||||
- **CIS Benchmark**：提供专门的硬化基准
|
||||
|
||||
## Variants
|
||||
Bottlerocket 变体是平台、处理器架构和必要二进制组件的组合：
|
||||
- 基础变体
|
||||
- GPU 变体（支持 NVIDIA 驱动）
|
||||
- 与 EKS、Carpenter 集成的优化变体
|
||||
|
||||
## Use Cases
|
||||
- EKS 节点操作系统
|
||||
- 自托管 Kubernetes 集群
|
||||
- 容器化工作负载生产环境
|
||||
|
||||
## Related Concepts
|
||||
- [[dm-verity]] — 根文件系统完整性验证
|
||||
- [[CIS-Benchmarks]] — 安全配置基准
|
||||
- [[EKS]] — 支持的 Kubernetes 服务
|
||||
|
||||
## Related Entities
|
||||
- [[Bottlerocket]] — 维护的开源项目
|
||||
- [[AWS]] — 核心维护者和赞助商
|
||||
@@ -1,15 +0,0 @@
|
||||
---
|
||||
title: "Brain Dump"
|
||||
type: concept
|
||||
tags: []
|
||||
---
|
||||
|
||||
## Definition
|
||||
一次性输入所有目标、使命和任务的上下文设定方式。用户将所有目标（职业、个人、商业）写入 Agent 上下文，作为后续所有任务的参考依据。
|
||||
|
||||
## Usage
|
||||
用户在初始阶段一次性输入所有目标，之后 Agent 每天自动生成任务来推进这些目标。
|
||||
|
||||
## Related
|
||||
- [[Goal-Driven Autonomous Tasks]]
|
||||
- [[每日任务生成]]
|
||||
@@ -1,28 +0,0 @@
|
||||
---
|
||||
title: "Brand Foundation Framework"
|
||||
type: concept
|
||||
tags: [brand-strategy, framework]
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Concept Definition
|
||||
品牌基础框架是创建 cohesive brand identities 的系统性方法，包含品牌核心元素的完整定义。
|
||||
|
||||
## Core Components
|
||||
1. **Brand Purpose（品牌使命）**：品牌存在的意义超越盈利的价值创造
|
||||
2. **Brand Vision（品牌愿景）**：品牌追求的未来状态
|
||||
3. **Brand Mission（品牌任务）**：品牌做什么、为谁做
|
||||
4. **Brand Values（品牌价值观）**：指导品牌行为的核心理念
|
||||
5. **Brand Personality（品牌个性）**：定义品牌特征的人类特质
|
||||
6. **Brand Promise（品牌承诺）**：对客户和利益相关方的承诺
|
||||
|
||||
## Application
|
||||
- 先于战术实施建立全面的品牌基础
|
||||
- 确保所有品牌元素作为 cohesive system 协同工作
|
||||
- 在保护品牌完整性的同时允许创意表达
|
||||
- 连接品牌决策到业务目标和市场定位
|
||||
|
||||
## Related Concepts
|
||||
- [[Visual-Identity-System]]：视觉识别系统
|
||||
- [[Brand-Voice]]：品牌声音与语调
|
||||
- [[Brand-Protection]]：品牌保护策略
|
||||
@@ -1,24 +0,0 @@
|
||||
---
|
||||
title: "Break-Glass Access"
|
||||
type: concept
|
||||
tags:
|
||||
- Security
|
||||
- Emergency
|
||||
---
|
||||
|
||||
## Definition
|
||||
Break-Glass Access（紧急访问）是指在紧急情况下绕过正常安全控制流程，获得系统访问权限的机制。通常作为备份方案，仅在无法通过正常渠道访问时使用。
|
||||
|
||||
## Application
|
||||
在 AWS Landing Zone 安全策略中，长期目标是基础设施即代码（IaC）以减少控制台访问和 break-glass access 需求，紧急访问仅作为极端情况的最后手段。
|
||||
|
||||
## Best Practices
|
||||
- 严格限制使用频率
|
||||
- 完整记录访问日志
|
||||
- 事后审查和报告
|
||||
- 逐步减少对它的依赖
|
||||
|
||||
## Related Concepts
|
||||
- [[Zero-Trust-Access]]
|
||||
- [[AWS-Landing-Zone]]
|
||||
- [[Infrastructure-as-Code-IaC]]
|
||||
@@ -1,39 +0,0 @@
|
||||
---
|
||||
title: "Budget Control"
|
||||
type: concept
|
||||
tags: []
|
||||
sources: [Public-Cloud-Learning-Sessions-Budget-Control]
|
||||
last_updated: 2024-03-19
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- AWS Budget Control
|
||||
- 预算控制自动化
|
||||
|
||||
## Definition
|
||||
AWS账户预算控制自动化系统，提供账户所有者详细的支出警报和成本分析报告，实现成本控制。
|
||||
|
||||
## Mechanism
|
||||
- 警报类型：forecast（预测）、actual（实际）、severe（严重）、enforcement（强制执行）四级
|
||||
- 评估间隔：8小时
|
||||
- 执行机制：100%阈值触发SCP阻止新资源创建
|
||||
- 评分系统：考虑账户规模和月末时间，避免惩罚月末轻微超支的账户
|
||||
|
||||
## Components
|
||||
- AWS Budget Alerts：触发SNS主题
|
||||
- Lambda：解析邮件数据，创建详细消息
|
||||
- Step Functions：丰富账户信息、预算详情、联系人数据
|
||||
- SCP：Service Control Policy，限制AWS服务使用
|
||||
|
||||
## Reports
|
||||
- Top Services Report：展示月度服务成本占比（基于Athena数据）
|
||||
- Top Users Report：展示每日用户支出（基于Cost Explorer数据）
|
||||
- Detailed Excel Report：资源级别的成本明细（资源ID、创建者、成本）
|
||||
|
||||
## Related
|
||||
- [[FinOps Team]]
|
||||
- [[SRE Core Team]]
|
||||
- [[Public Cloud Learning Sessions - Budget Control - 20240319]]
|
||||
- [[SCP]]
|
||||
- [[Source Identity]]
|
||||
- [[AWS]]
|
||||
@@ -1,15 +0,0 @@
|
||||
---
|
||||
title: "Budget Framework"
|
||||
type: concept
|
||||
tags: [finance]
|
||||
sources: [support-finance-tracker]
|
||||
last_updated: 2026-04-21
|
||||
---
|
||||
|
||||
定义：组织年度预算的结构化方法，包含按部门/类别拆分、季度差异分析、偏差分类与再分配规则，用于把控支出与指导战略资源分配。
|
||||
|
||||
## Typical Components
|
||||
- 部门与类别分解
|
||||
- 季度/月度差异分析
|
||||
- 偏差触发与纠正流程
|
||||
- 预算再分配规范
|
||||
@@ -1,22 +0,0 @@
|
||||
---
|
||||
title: "Build Mode"
|
||||
type: concept
|
||||
tags: [ai-coding, workflow]
|
||||
---
|
||||
|
||||
## 定义
|
||||
OpenCode 的实际执行模式，接收指令后进行代码修改。
|
||||
|
||||
## 使用方式
|
||||
在 OpenCode TUI 中按 Tab 键从 Plan 模式切换回 Build 模式。
|
||||
|
||||
## 作用
|
||||
- 执行 AI 生成的实现方案
|
||||
- 接收自然语言指令进行代码修改
|
||||
- 支持 /undo 撤销修改
|
||||
- 支持 /redo 重做修改
|
||||
|
||||
## 关联
|
||||
- [[Plan Mode]]
|
||||
- [[Vibe Coding]]
|
||||
- [[OpenCode]]
|
||||
@@ -1,28 +0,0 @@
|
||||
---
|
||||
title: "Bulkification"
|
||||
type: concept
|
||||
tags: [salesforce, triggers, best-practices]
|
||||
sources: [specialized-salesforce-architect.md]
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
# Bulkification
|
||||
|
||||
Salesforce 触发器必须能够批量处理多条记录的机制。
|
||||
|
||||
## 要求
|
||||
- 触发器逻辑绝不能一次只处理一条记录
|
||||
- 代码必须能在 200 条记录的批量操作下正常工作
|
||||
- 如果代码在 200 条记录时会失败，则视为错误
|
||||
|
||||
## 实现方式
|
||||
- 使用 Maps 存储数据
|
||||
- 避免在循环中执行 SOQL 或 DML
|
||||
- 使用 Sets 和 Lists 批量操作
|
||||
|
||||
## 相关概念
|
||||
- [[Governor-Limits]] — 批量处理是为了遵守 Governor Limits
|
||||
- [[Trigger-Framework]] — 触发器框架实现
|
||||
|
||||
## 来源
|
||||
[[Salesforce-Architect]] 智能体的核心设计原则
|
||||
@@ -1,62 +0,0 @@
|
||||
---
|
||||
title: Byox - Build Your Own X
|
||||
description: Learning programming by rebuilding technologies from scratch
|
||||
tags: [learning, methodology, programming, open-source]
|
||||
---
|
||||
|
||||
# Byox (Build Your Own X)
|
||||
|
||||
## Definition
|
||||
|
||||
**Byox** (Build Your Own X) is a learning methodology that advocates for mastering programming and technology understanding by **rebuilding complex systems from scratch**. The guiding principle comes from physicist Richard Feynman:
|
||||
|
||||
> *"What I cannot create, I do not understand."*
|
||||
|
||||
## Core Philosophy
|
||||
|
||||
Instead of passively consuming knowledge about how a technology works, practitioners:
|
||||
|
||||
1. **Choose a technology** they want to understand deeply
|
||||
2. **Study existing implementations** and documentation
|
||||
3. **Rebuild it from scratch** using a chosen programming language
|
||||
4. **Gain deep insight** into how it works internally
|
||||
|
||||
## Coverage
|
||||
|
||||
The Byox methodology covers **26 technology domains**:
|
||||
|
||||
- **Systems**: Operating System, Docker, Container
|
||||
- **Languages**: Programming Language, Compiler, Interpreter, Regex Engine
|
||||
- **Data**: Database, NoSQL, Key-Value Store
|
||||
- **Web**: Web Browser, Web Server, Search Engine
|
||||
- **Tools**: Git, Shell, Command-Line Tool, Text Editor, Template Engine
|
||||
- **Graphics**: 3D Renderer, Voxel Engine, Physics Engine
|
||||
- **AI/ML**: Neural Network, Visual Recognition
|
||||
- **Networks**: Network Stack, BitTorrent Client
|
||||
- **Entertainment**: Game, Emulator/Virtual Machine
|
||||
- **Other**: Blockchain/Cryptocurrency, Augmented Reality, Bot
|
||||
|
||||
## Resources
|
||||
|
||||
Primary resource: [[codecrafters-io/build-your-own-x]] — A curated collection of 500+ step-by-step tutorials
|
||||
|
||||
Complementary platform: [[CodeCrafters]] — Interactive challenges that guide learners through building technologies step by step
|
||||
|
||||
## Notable Examples
|
||||
|
||||
| Technology | Language | Resource |
|
||||
|------------|----------|----------|
|
||||
| Database | C | [Let's Build a Simple Database](https://cstack.github.io/db_tutorial/) |
|
||||
| OS | Rust | [Writing an OS in Rust](https://os.phil-opp.com/) |
|
||||
| Programming Language | Multiple | [Crafting Interpreters](http://www.craftinginterpreters.com/) |
|
||||
| Web Browser | Python | [Browser Engineering](https://browser.engineering/) |
|
||||
| Git | Python | [Write yourself a Git](https://wyag.thb.lt/) |
|
||||
| Docker | Go | [Build Your Own Container](https://www.infoq.com/articles/build-a-container-golang) |
|
||||
|
||||
## Why Byox Works
|
||||
|
||||
1. **Active Learning**: Building forces deep engagement
|
||||
2. **Hidden Complexity**: Reveals implementation details textbooks skip
|
||||
3. **Transferable Skills**: Generalizes to understanding other systems
|
||||
4. **Portfolio Building**: Creates tangible proof of understanding
|
||||
5. **Confidence**: Only truly knowing something if you can create it
|
||||
@@ -1,31 +0,0 @@
|
||||
---
|
||||
title: "CAPA"
|
||||
type: concept
|
||||
tags: [incident-management, postmortem]
|
||||
sources: [ctp-topic-30-managing-change]
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Summary
|
||||
CAPA（Corrective and Preventive Action，纠正和预防措施）是事故管理的重要组成部分，通过根因分析防止同类问题再次发生。
|
||||
|
||||
## Definition
|
||||
CAPA 即 Post-mortem 回顾，目的是从事故中提取根因并预防同类问题再次发生。
|
||||
|
||||
## Aliases
|
||||
- Corrective and Preventive Action：纠正和预防措施
|
||||
- Post-mortem：事故回顾
|
||||
|
||||
## Process
|
||||
1. 事故响应：立即采取行动缓解影响
|
||||
2. 根因分析：识别问题的根本原因
|
||||
3. 纠正措施：修复已发现的问题
|
||||
4. 预防措施：制定措施防止同类问题再次发生
|
||||
5. 文档记录：完整记录分析和改进措施
|
||||
|
||||
## Related Concepts
|
||||
- [[Incident Management]]：事件管理，CAPA 的上游流程
|
||||
- [[SRE]]：CAPA 的执行者
|
||||
|
||||
## Connections
|
||||
- [[ctp-topic-30-managing-change]] ← is_the_source_for
|
||||
@@ -1,22 +0,0 @@
|
||||
---
|
||||
title: "CAPEX to OPEX"
|
||||
type: concept
|
||||
tags: [Cloud, Finance]
|
||||
sources: [Cloud-Maturity-Model-A-Detailed-Guide-For-Cloud-Adoption]
|
||||
last_updated: 2025-02-28
|
||||
---
|
||||
|
||||
## Summary
|
||||
CAPEX to OPEX（从资本支出到运营支出）是云采纳带来的财务模式转变。
|
||||
|
||||
## Definition
|
||||
传统 IT 采用资本支出（CAPEX）模式购买硬件，而云采纳转向运营支出（OPEX）模式按需付费使用服务。
|
||||
|
||||
## Key Benefits
|
||||
- 将固定成本转化为可变成本
|
||||
- 按需扩展
|
||||
- 无需前期大量投资
|
||||
- 通过云采纳管理成本
|
||||
|
||||
## Connections
|
||||
- [[CAPEX-to-OPEX]] ← enabled_by ← [[Cloud-Adoption]]
|
||||
@@ -1,29 +0,0 @@
|
||||
---
|
||||
title: "CES"
|
||||
type: concept
|
||||
tags: [Customer Analytics, Effort Metric]
|
||||
sources: []
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
CES（Customer Effort Score，客户努力程度评分）衡量客户完成某项任务（如解决问题）所需付出的努力程度。
|
||||
|
||||
## Calculation
|
||||
通常使用李克特7点量表（强烈不同意到强烈同意）：
|
||||
```
|
||||
"这个产品/服务让我轻松完成了我的任务"
|
||||
```
|
||||
|
||||
低 CES 分数表示更好的用户体验。
|
||||
|
||||
## Purpose
|
||||
- 衡量客户体验流程的顺畅程度
|
||||
- 识别需要改进的摩擦点
|
||||
- 预测客户留存可能性
|
||||
|
||||
## Connections
|
||||
- [[Product Feedback Synthesizer]]：收集和分析CES数据
|
||||
- [[CSAT]]：客户满意度指标
|
||||
- [[NPS分析]]：忠诚度指标
|
||||
- [[流失预测]]：流失预警的输入指标
|
||||
@@ -1,26 +0,0 @@
|
||||
---
|
||||
title: "CI/CD 流水线"
|
||||
type: concept
|
||||
tags: [devops, automation, continuous-integration, continuous-delivery]
|
||||
sources: [cloud-devop-maturity-guideline]
|
||||
last_updated: 2026-04-16
|
||||
---
|
||||
|
||||
## Definition
|
||||
CI/CD 流水线（持续集成/持续交付流水线）是自动化软件构建、测试和部署的流程管道，实现从代码提交到生产发布的全自动化。
|
||||
|
||||
## Components
|
||||
- **持续集成（CI）**：代码提交后自动构建、编译、单元测试
|
||||
- **持续交付（CD）**：通过自动化测试后将代码部署到预生产环境
|
||||
- **持续部署（Continuous Deployment）**：自动部署到生产环境
|
||||
|
||||
## Key Tools
|
||||
- [[Terraform]]：IaC 配置
|
||||
- [[Ansible]]：配置管理
|
||||
- [[Jenkins]]：（常见但未在本源文件中提及）
|
||||
- [[GitLab CI]]：（常见但未在本源文件中提及）
|
||||
|
||||
## Connections
|
||||
- [[DevOps 成熟度模型]] ← 技术基础 ← [[CI/CD 流水线]]
|
||||
- [[IaC]] ← 依赖 ← [[CI/CD 流水线]]
|
||||
- [[DORA 指标]] ← 受影响 ← [[CI/CD 流水线]]
|
||||
@@ -1,24 +0,0 @@
|
||||
---
|
||||
title: "CIS Benchmarks"
|
||||
type: concept
|
||||
tags: [Security, Compliance, AWS]
|
||||
---
|
||||
|
||||
## Definition
|
||||
CIS Benchmarks（互联网安全中心基准）是由 CIS（Center for Internet Security）制定的安全配置基准，用于衡量系统是否符合行业最佳安全实践。
|
||||
|
||||
## Purpose
|
||||
- 提供标准化的安全配置指南
|
||||
- 评估系统安全状态
|
||||
- 符合合规性要求
|
||||
- 减少系统攻击面
|
||||
|
||||
## Application
|
||||
- 操作系统（Linux, Windows）
|
||||
- 云平台（AWS, Azure, GCP）
|
||||
- 应用软件
|
||||
|
||||
## Related Concepts
|
||||
- [[Foundation AMI]] — 应用 CIS Benchmarks 的镜像类型
|
||||
- [[OS Hardening]] — 实施基准的技术手段
|
||||
- [[Standard AMI]] — 企业标准化镜像
|
||||
@@ -1,26 +0,0 @@
|
||||
---
|
||||
title: "CMMI"
|
||||
type: concept
|
||||
tags: [maturity-model, process-improvement, capability]
|
||||
sources: [cloud-devop-maturity-guideline]
|
||||
last_updated: 2026-04-16
|
||||
---
|
||||
|
||||
## Definition
|
||||
CMMI（Capability Maturity Model Integration，能力成熟度模型集成）是一套过程改进框架，用于评估和改进组织流程能力。
|
||||
|
||||
## Maturity Levels
|
||||
1. **初始级（Initial）**：过程不可预测，依赖个人能力
|
||||
2. **可管理级（Managed）**：过程已建立但依赖经验
|
||||
3. **已定义级（Defined）**：过程标准化和文档化
|
||||
4. **量化管理级（Quantitatively Managed）**：基于数据的量化管理
|
||||
5. **优化级（Optimizing）**：持续过程改进
|
||||
|
||||
## Relationship with DevOps
|
||||
- CMMI 是 DevOps 成熟度模型的先驱和理论基础
|
||||
- DevOps 成熟度模型借鉴了 CMMI 的分级方法论
|
||||
- CMMI 更通用，DevOps 成熟度模型更专注于交付实践
|
||||
|
||||
## Connections
|
||||
- [[DevOps 成熟度模型]] ← 借鉴 ← [[CMMI]]
|
||||
- [[DORA 指标]] ← 量化评估 ← [[CMMI]] 相关方法
|
||||
@@ -1,32 +0,0 @@
|
||||
---
|
||||
title: "CSAT"
|
||||
type: concept
|
||||
tags: [Customer Analytics, Satisfaction Metric]
|
||||
sources: []
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
CSAT（Customer Satisfaction Score，客户满意度评分）是一种衡量客户对特定交互或整体体验满意程度的指标。
|
||||
|
||||
## Calculation
|
||||
通常采用李克特量表（1-5分或1-10分）问卷调查：
|
||||
```
|
||||
CSAT = (满意客户数 / 总客户数) × 100%
|
||||
```
|
||||
|
||||
或计算平均分：
|
||||
```
|
||||
平均CSAT = 总满意度分数 / 响应数
|
||||
```
|
||||
|
||||
## Usage
|
||||
- 交易后立即测量客户满意度
|
||||
- 跟踪服务或功能满意度变化
|
||||
- 与 NPS 结合使用形成完整的客户体验视图
|
||||
|
||||
## Connections
|
||||
- [[Product Feedback Synthesizer]]：收集和分析CSAT数据
|
||||
- [[NPS分析]]：结合使用的忠诚度指标
|
||||
- [[CES]]：衡量客户努力程度
|
||||
- [[流失预测]]：满意度建模的输入指标
|
||||
@@ -1,29 +0,0 @@
|
||||
---
|
||||
title: "CSS 设计系统"
|
||||
type: concept
|
||||
tags: [UX, CSS, 设计规范]
|
||||
---
|
||||
|
||||
## 定义
|
||||
通过 CSS 变量（Custom Properties）定义颜色、字体、间距、布局的系统化方法，为项目提供一致性的视觉语言和可维护的样式基础。
|
||||
|
||||
## 核心要素
|
||||
- **颜色变量**：语义化命名（--bg-primary, --text-primary, --accent-color）
|
||||
- **字体系统**：层级化字号（--text-xs 到 --text-3xl）
|
||||
- **间距系统**：基于 4px 网格的间距变量（--space-1 到 --space-16）
|
||||
- **布局系统**：容器尺寸（--container-sm 到 --container-xl）
|
||||
|
||||
## 主题支持
|
||||
- Light Theme：浅色背景和深色文字
|
||||
- Dark Theme：深色背景和浅色文字
|
||||
- System Theme：通过 prefers-color-scheme 自动匹配系统偏好
|
||||
|
||||
## 实践
|
||||
- 使用语义化命名而非具体颜色值
|
||||
- 建立设计 tokens 供组件复用
|
||||
- 通过 CSS 变量实现主题动态切换
|
||||
|
||||
## 相关概念
|
||||
- [[主题切换]]
|
||||
- [[组件架构]]
|
||||
- [[响应式断点策略]]
|
||||
@@ -1,38 +0,0 @@
|
||||
---
|
||||
title: "Calendar API"
|
||||
type: concept
|
||||
tags: [google-workspace, api, calendar]
|
||||
---
|
||||
|
||||
## Definition
|
||||
Calendar API 是 Google 提供的编程接口，允许第三方应用程序通过 OAuth 2.0 认证访问 Google Calendar 日历服务，实现事件查询、创建、修改和删除等功能。
|
||||
|
||||
## Key Operations
|
||||
| 操作 | 描述 |
|
||||
|------|------|
|
||||
| events.list | 列出日历事件 |
|
||||
| events.get | 获取事件详情 |
|
||||
| events.insert | 创建日历事件 |
|
||||
| events.patch | 部分更新事件 |
|
||||
| events.delete | 删除事件 |
|
||||
| colors.get | 获取颜色配置 |
|
||||
|
||||
## Prerequisites for Access
|
||||
1. **Google Cloud Console** 中启用 Calendar API
|
||||
2. 配置 **OAuth 2.0 凭证**（桌面应用类型）
|
||||
3. 用户完成 OAuth 授权流程
|
||||
4. 添加**测试用户**（未验证应用场景）
|
||||
|
||||
## Common Error
|
||||
- `403 accessNotConfigured`：API 未启用
|
||||
- `403 accessDenied`：OAuth 未授权
|
||||
|
||||
## Related Concepts
|
||||
- [[OAuth]]：认证机制
|
||||
- [[Google-Cloud-Console]]：凭证配置
|
||||
- [[测试用户]]：绕过未验证应用限制
|
||||
- [[API-Enablement]]：启用 API 的操作
|
||||
|
||||
## Related Entities
|
||||
- [[Google]]：API 提供方
|
||||
- [[gog CLI]]：使用 Calendar API 的命令行工具
|
||||
@@ -1,24 +0,0 @@
|
||||
---
|
||||
title: "Calibration Testing"
|
||||
type: concept
|
||||
tags: [ml-ops, evaluation, calibration]
|
||||
sources: [specialized-model-qa]
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
校准测试用于评估模型预测概率是否与真实发生率一致。
|
||||
|
||||
## Common Methods
|
||||
- Hosmer-Lemeshow test
|
||||
- Brier score
|
||||
- Reliability diagrams
|
||||
|
||||
## Use in Model QA
|
||||
- 检查概率输出是否可信
|
||||
- 比较不同子群体的校准差异
|
||||
- 评估分布漂移下的概率稳定性
|
||||
|
||||
## Related Concepts
|
||||
- [[Model Audit]]
|
||||
- [[Discrimination Metrics]]
|
||||
@@ -1,35 +0,0 @@
|
||||
---
|
||||
title: "Campbell 英雄之旅"
|
||||
type: concept
|
||||
tags: [narrative-theory, story-structure, hero-journey]
|
||||
---
|
||||
|
||||
## 定义
|
||||
Joseph Campbell 在《千面英雄》中提出的单一神话理论（The Hero with a Thousand Faces），认为全世界的神话故事都遵循同一个基本叙事结构。
|
||||
|
||||
## 核心阶段
|
||||
1. **分离（Departure）**：离开日常世界，进入冒险领域
|
||||
- Call to Adventure（冒险召唤）
|
||||
- Refusal of the Call（拒绝召唤）
|
||||
- Meeting the Mentor（遇见导师）
|
||||
- Crossing the Threshold（跨越门槛）
|
||||
2. **启蒙（Initiation）**：经历考验和转变
|
||||
- Trials and Tribulations（考验与磨难）
|
||||
- Approach to the Inmost Cave（接近最深处洞穴）
|
||||
- Ordeal（严峻考验）
|
||||
- Reward（获得奖赏）
|
||||
3. **回归（Return）**：带着力量回归日常世界
|
||||
- The Road Back（回归之路）
|
||||
- Resurrection（复活/重生）
|
||||
- Return with the Elixir（带着灵药回归）
|
||||
|
||||
## 变体
|
||||
- [[Vogler 作家旅程]]：Christopher Vogler 将 Campbell 理论应用于现代编剧实践
|
||||
|
||||
## 应用领域
|
||||
- 电影剧本结构分析
|
||||
- 游戏叙事设计
|
||||
- 品牌故事构建
|
||||
|
||||
## 来源框架
|
||||
- [[Narratologist]] 使用此框架分析英雄叙事结构
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user