diff --git a/sources/EXECUTIVE-BRIEF.md b/sources/EXECUTIVE-BRIEF.md deleted file mode 100644 index e69de29b..00000000 diff --git a/sources/n8n调用hermes-agents的工作流架构.md b/sources/n8n调用hermes-agents的工作流架构.md deleted file mode 100644 index e69de29b..00000000 diff --git a/summary_knowledgebase/csd-wiki/ICSD/Toggle-plaftform-offline-NG-for-Native-SACM_686073929.md b/summary_knowledgebase/csd-wiki/ICSD/Toggle-plaftform-offline-NG-for-Native-SACM_686073929.md deleted file mode 100644 index b806c065..00000000 --- a/summary_knowledgebase/csd-wiki/ICSD/Toggle-plaftform-offline-NG-for-Native-SACM_686073929.md +++ /dev/null @@ -1,56 +0,0 @@ -# 摘要：Toggle Platform Offline NG for Native SACM - -## 一句话说明 -Platform Offline NG Pod（24.2版本引入）用于解决 Native SACM CI 通知处理中的资源瓶颈问题，通过分担离线任务负载提升高并发场景下的系统稳定性。 - ---- - -## 关键概念 - -| 概念 | 说明 | -|------|------| -| **Platform Offline NG Pod** | 24.2版本引入的新Pod，用于分散 Native SACM CI 同步任务负载 | -| **Native SACM** | 默认依赖 Offline NG Pod 运行；可切换回原始Offline Pod | -| **UCMDB** | CI数据来源，高峰期大量CI涌入时容易造成资源瓶颈 | -| **ConfigMap** | `itom-xruntime-infra-config`，控制开关的核心配置 | -| **开关参数** | `ENABLE_SCALABLE_NATIVE_SACM: "true"/"false"` | - ---- - -## 操作流程对比 - -### 禁用（Disable） - -| 步骤 | 操作 | -|------|------| -| 1 | 编辑ConfigMap：`kubectl edit cm itom-xruntime-infra-config -n ` | -| 2 | 设置 `ENABLE_SCALABLE_NATIVE_SACM: "false"` | -| 3 | 重启Offline NG Pod：`kubectl rollout restart deployment itom-xruntime-platform-offline-ng -n ` | -| 4 | 重缩放Offline Pod：`kubectl scale deployment itom-xruntime-platform-offline -n --replicas=0` → `--replicas=1` | - -### 启用（Enable） - -| 步骤 | 操作 | -|------|------| -| 1 | 编辑ConfigMap：`kubectl edit cm itom-xruntime-infra-config -n ` | -| 2 | 设置 `ENABLE_SCALABLE_NATIVE_SACM: "true"` | -| 3 | 重启Offline NG Pod：`kubectl rollout restart deployment itom-xruntime-platform-offline-ng -n ` | -| 4 | 重缩放Offline Pod：`kubectl scale deployment itom-xruntime-platform-offline -n --replicas=0` → `--replicas=1` | -| 5 | 确认Offline NG副本数为1：`kubectl scale deployment itom-xruntime-platform-offline-ng -n --replicas=1` | - ---- - -## 核心差异（禁用 vs 启用） - -- **禁用**：Native SACM 回退至原始Offline Pod处理CI -- **启用**：Native SACM 使用新版Offline NG Pod处理CI -- **注意**：启用步骤比禁用多一步——需确保Offline NG副本数重缩放为1 - ---- - -## 相关链接 - -- 原始文档：`knowledgebase/csd-wiki/ICSD/Toggle-plaftform-offline-NG-for-Native-SACM_686073929.md` - -## 信息图 -![信息图](./Toggle-plaftform-offline-NG-for-Native-SACM_686073929_infographic.jpg) diff --git a/summary_knowledgebase/csd-wiki/ICSD/Toggle-plaftform-offline-NG-for-Native-SACM_686073929_infographic.jpg b/summary_knowledgebase/csd-wiki/ICSD/Toggle-plaftform-offline-NG-for-Native-SACM_686073929_infographic.jpg deleted file mode 100644 index be44b99b..00000000 Binary files a/summary_knowledgebase/csd-wiki/ICSD/Toggle-plaftform-offline-NG-for-Native-SACM_686073929_infographic.jpg and /dev/null differ diff --git a/wiki/bookmarks.md b/wiki/bookmarks.md deleted file mode 100644 index a5f5d254..00000000 --- a/wiki/bookmarks.md +++ /dev/null @@ -1,455 +0,0 @@ -# Chrome Bookmarks - -> 共 332 条书签（已排除 OpenText） -> 导出时间: 2026-04-21 09:30 - ---- - -## Bookmark Bar - -| Title | -|---| -| Agent Base | -| Google Tasks | -| Grafana Dashboard | -| Immersive Translate | -| Inoreader | -| Quartz | -| Synology Photos | - -### AI - - - - - - - - - - - - -
Prompt EngineeringText Image to Video
Anthropic Runway
Google Vertex AI Prompts Hailuo AI
Github ChatGPT Prompts Capcut
Prompt Hero Pictory
Anthropic Prompt Library
OpenAI Prompt Libary
Snack Prompt
Hero Prompt Library
Prompt Gallary
- - - - - - - - - - - -
Vibe Coding图片编辑
Vibe Coding Dreamina
vibe-coding-cn Image Prompt (TTV, ITV)
Claude Skills
ComposioHQ awesome-claude-skills
VoltAgent awesome-claude-skills
BehiSecc awesome-claude-skills
Skills Mp
Claude Marketplace
- - - - - - - - - - -
宝藏网站算力平台
Decopy.ai Wavespeed AI
Siliconflow
端脑云
KIE AI
Mega LLM
Vidu
Open Router
- - -| Title | -|---| -| AI Comparison | -| AI 星踪岛 | -| ChatGPT | -| ChatGPT | -| ComfyUI | -| DeepSeek | -| Deepsider | -| DesignKit | -| F5-TTS Local | -| Firecrawl | -| Fliki: AI Video Generator - Turn Ideas into Videos | -| Google Gemini | -| Google Gemini API | -| Heygen | -| https://www.perplexity.ai/ | -| Keling AI | -| MCP Documentation | -| Note GPT | -| Notebook LM | -| Notegpt youtube video summarizer | -| Open AI | -| Open AI Platform - Open AI API key | -| Open Router | -| Pippit | -| SillyTavern | -| Smithery - MCP marketplace | -| wavespeed image edit | -| wavespeed image translator | -| Weights & Biases - AI platform | -| YouMind | -| 象寄 (图片翻译，编辑） | - -### Finance - -| Title | -|---| -| 中银香港 | -| 汇丰香港 | - -### Google - -| Title | -|---| -| Gmail | -| Google Account | -| Google AI Studio | -| Google Calendar | -| Google Cloud | -| Google Cloud Console | -| Google Doc | -| Google Driver | -| Google Finance | -| Google Gemini API | -| Google Keep | -| Google NotebookLM | -| Google Opal | -| Google Sheets | -| Google Vids | - -### Home Network - - - - - - - - - - - - - - - - - - - - - - - -
MacminiNAS
Macmini - Portainer - Local NAS - Portainer - Internal
Macmini - vaultwarden - External NAS - SHENWEI_DS718 - Internal
Macmini - RabbitMQ - Internal NAS - SHENWEI_DS718 - External
MacMini - OpenCode Server - Local NAS - Vaultwarden - Internal
Macmini - Glance - Local NAS - Vaultwarden - External
Macmini - Quartz - Local NAS - CloudDrive2 - Internal
NAS-V2RAYA - Internal
NAS - Calibre Web - Internal
NAS - Calibre Web - External
NAS - Navidrome - Internal
NAS - Navidrome - External
NAS - Obsidian WebDAV - External
NAS - zipline - Internal
NAS - zipline - External
NAS - minio console - Internal
NAS - Web Portal - External
NAS - Web Portal - Internal
NAS - Jellyfin - Internal
NAS - Jellyfin - External
NAS - Gitea - Local
- - - - - - - - - - - - - - - - - - - - - - -
Ubuntu1Ubuntu2
Ubuntu1 - Portainer - Internal Ubuntu2 - ragflow - Internal
Ubuntu1 - ddns go - Internal Ubuntu2 - Portainer - Internal
Ubuntu1 - IT Tools - Internal Ubuntu2 - Vibe Kanban - Internal
Ubuntu1 - Transmission Web - Internal Ubuntu2 - tiktok pm dev - Internal
Ubuntu1 - Transmission Web - External Ubuntu2 - Glances - Local
Ubuntu1 - cAdvisor - Internal Ubuntu2 - MD - Local
Ubuntu1 - Prometheus - Internal Ubuntu2 - it-tools - External
Ubuntu1 - Grafana - Internal Ubuntu2 - Grafana- Internal
Ubuntu1 - Grafana - External Ubuntu2 - drawio - External
Ubuntu1 - Blackbox Exporter - Internal Ubuntu2 - n8n - local
Ubuntu1 - Node Exporter - Internal Ubuntu2 - n8n - External
Ubuntu1 - superset - Internal Ubuntu2 - AgentBase - Local
Ubuntu1 - superset - External
Ubuntu1 - tiktok_pm - Internal
Ubuntu1 - tiktok_pm - External
Ubuntu1 - Prompt Optimizer - Internal
Ubuntu1 - Homarr - Internal
Ubuntu1 - Homarr - External
Ubuntu1 - Glances - Local
- - - - - - - - -
VPS
Remote - RackNerd 1GB KVM VPS - FRP - External
Remote - RackNerd 1 GB KVM VPS
Remote - RackNerd 1 GB KVM VPS - Control Panel
Bandwagon Host - Request IP Change
Bandwagon - 3X UI Console
- - -| Title | -|---| -| Aliyun Console | -| Bandwagon VPS | -| Cloudflare | -| Cloudflare Worker - Nodewarden - External | -| Grafana Dashboard | -| Ping, mtr, dig, TCP port check and real time BGP looking glass from multiple locations | -| RAX 50 | -| ThinkBook - Portainer - Internal | -| 华为凌霄子母路由 Q6 网线版 | -| 糖果云 | - -### Learning - -| Title | -|---| -| AI 知乎学堂 | -| Engoo Daily News | -| Google Trend Tutorial | -| Slide Share | -| TED Talks List | - -### Music - - - - -
Guitar
C大调音阶系统练习方法
- - -### Others - - - - - - - -
TableauYoutube Video
Tableau Community Every Type of Math Explained in 9 Minutes
Tableau Training Videos Colors Family Song
Awesome Alphabet
Count 1 to 5!
- - -| Title | -|---| -| Brookings - Quality. Independence. Impact. | -| Foreign Affairs Magazine | -| FOSSHUB | -| Free eBooks \| Project Gutenberg | -| https://ieltsonlinetests.com/ielts-exam-library | -| Musicca – Learn music theory for free | -| Oreilly | -| Pocket Explore | -| Reddit | -| ShapeZ | -| Snopes.com \| The definitive fact-checking site and reference source for urban legends, folklore, myths, rumors, and misinformation. | -| Study English, Stay Informed - Engoo Daily News | -| Tableau 举个栗子 | -| The Economist \| World News, Economics, Politics, Business & Finance | -| Welcome \| Open Yale Courses | -| xbox game pass | -| yotube download | -| 发送至 Kindle | -| 照片上传 | - -### Productivity - -| Title | -|---| -| AWS Cost Estimation | -| Chrome Settings | -| Convert HTML to PDF | -| Crontab.guru - The cron schedule expression generator | -| DAX 函数 | -| Exchange Admin Center | -| FOSSHUB | -| IFIXIT | -| Internet Archive: Digital Library of Free & Borrowable Texts, Movies, Music & Wayback Machine | -| InVision – Free Web & Mobile Mockup and UI Prototyping Tool | -| it-tools | -| MajorGeeks | -| Office 365 | -| PowerBI | -| Raindrop | -| Shortcuts.design \| Every shortcut for designers in one place 🚀 | -| Stack Overflow - Where Developers Learn, Share, & Build Careers | -| Wiki Template | -| Word New | -| 字幕 | -| 常用字符串图案 | -| 常用网络&特殊符号大全 | - -### STQ - -| Title | -|---| -| stq-admin | -| stq-n8n | -| stq-web | - -### Shen Wei - - - - - - - -
GameMovie
Internet Game Database TMDB
Moby Game Sub HD
Diep.io
Backloggery
- - - - - -
MusicNAS
MusicBrainz 矿神源
矿神源
- - - - - - - - - - - - - -
PTTV
BT School 智能电视网
Torrentleech 银河录像局
PT邀请网
Milkie
Milkie
GTK
PT Fans
PTFans - Powered by NexusPHP
PT China 铂金学院
纪录片之家
- - -| Title | -|---| -| 1024 | -| Backloggd - A Video Game Collection Tracker | -| https://whc.unesco.org/ | -| https://www.bacancytechnology.com/ | -| TowardsDataScience | -| wechat format | -| 免费图床 | -| 老画报 | - -### Social - -| Title | -|---| -| linkedin | - -### Technical - - - - - - -
视频剪辑课程
剪映创作课堂
视频滑动教程
分屏定格卡点
- - -| Title | -|---| -| Bright Data | -| Django | -| Fast API | -| Jinjia | -| Mermaid Liv 自动渲染图形化 ER 图 | -| Trendshift - A better way to find open source project | - -### Tools - - - - - - - - - - - - -
IP 检查
测试IP纯净度
显示查询自己的IP地址
ip111.cn -测试三个地方IP一致性
IP伪装检查
ipconfig.me
What's My IP
Test IPv6
db-ip (JSON)
真实地址生成器
- - -| Title | -|---| -| Adobe Color | -| AdsPower - 指纹浏览器 | -| Anna's Archive | -| Bilibili视频下载工具 | -| Coolors | -| EasyPeasyEase - 免费工具，用于拼接短视频并应用缓动曲线 | -| https://uptime.is/ | -| Immersive Translate | -| IPv6 Tunnel Broker | -| Koodo Web | -| Magazine Lib | -| My IP | -| Opencut | -| PDF convert to Markdown | -| Pingme - 接受美国短信验证 | -| Slideshare Downloader | -| Snapany视频下载插件 | -| Strong Password Generator | -| TinyWoW | -| Ubuntu1 - IT Tools - Internal | -| WildCard 虚拟信用卡 | -| World Time Buddy | -| 临时邮箱 | -| 在线格式转换 | - -### eCommerce - - - - - -
公司报税财务
国家税务总局 上海税务局 PingPong
全国统一规范电子税务局
- - - - - - - - -
货代物流选品工具
方舟跨境 erank
腾飞速达 货小易 Fastmoss
腾飞速达 遨虾
3X 货代 Echotik
超达系统
- - -| Title | -|---| -| 1688 | -| 1688开放平台 | -| AMZ 123 | -| Bright Data | -| FurryNest Supplies | -| Rapid API | -| TikTok 123 | -| TikTok Business Suite | -| TikTok for Developer | -| TikTok Shop | -| TikTok Shop Seller Log In \| Cross Border | -| TikTok Shop Seller Log In \| Cross Border | -| TikTok 学习中心 | -| TIKTOK 跨境商家 | -| 买方工作台 | -| 国家企业信用信息公示系统 | -| 妙手ERP | -| 海外跨境Kevin | -| 淘宝开放平台 | - ---- - -## Other - -| Title | -|---| -| Google | - -### Shen Wei - -| Title | -|---| -| APKMirror - Free APK Downloads - Free and safe Android APK downloads | -| Google | -| Pluto TV - Drop In. Watch Free. | -| Sao.Fm-思奥FM,在线电台收听,在线听广播,网络收音机在线收听 | -| 来自半岛电视台的突发新闻、世界新闻和视频 --- Breaking News, World News and Video from Al Jazeera | -| 欢迎来到 Steam | - ---- - -## Synced - -| Title | -|---| -| Bt7086 - bt7086.com，xp1024.com-  1024核工厂 | - ---- diff --git a/wiki/concepts/2D-First-Spatial-Second.md b/wiki/concepts/2D-First-Spatial-Second.md deleted file mode 100644 index b732fe5a..00000000 --- a/wiki/concepts/2D-First-Spatial-Second.md +++ /dev/null @@ -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]]：最终平台（验证后） diff --git a/wiki/concepts/360度反馈.md b/wiki/concepts/360度反馈.md deleted file mode 100644 index cf00ae01..00000000 --- a/wiki/concepts/360度反馈.md +++ /dev/null @@ -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 计划]]：人才识别与发展 diff --git a/wiki/concepts/3X-UI.md b/wiki/concepts/3X-UI.md deleted file mode 100644 index bd1a8640..00000000 --- a/wiki/concepts/3X-UI.md +++ /dev/null @@ -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 加速等功能 diff --git a/wiki/concepts/90-10-Rule.md b/wiki/concepts/90-10-Rule.md deleted file mode 100644 index 0e7babf3..00000000 --- a/wiki/concepts/90-10-Rule.md +++ /dev/null @@ -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 diff --git a/wiki/concepts/A-B-Testing.md b/wiki/concepts/A-B-Testing.md deleted file mode 100644 index ee0d1e89..00000000 --- a/wiki/concepts/A-B-Testing.md +++ /dev/null @@ -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]] - diff --git a/wiki/concepts/ABC-Classification.md b/wiki/concepts/ABC-Classification.md deleted file mode 100644 index e2f365e7..00000000 --- a/wiki/concepts/ABC-Classification.md +++ /dev/null @@ -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 分级调整 - diff --git a/wiki/concepts/ACOS.md b/wiki/concepts/ACOS.md deleted file mode 100644 index e41a2c77..00000000 --- a/wiki/concepts/ACOS.md +++ /dev/null @@ -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 \ No newline at end of file diff --git a/wiki/concepts/ADDIE.md b/wiki/concepts/ADDIE.md deleted file mode 100644 index 609dd00d..00000000 --- a/wiki/concepts/ADDIE.md +++ /dev/null @@ -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 四级评估模型]]：评估框架 diff --git a/wiki/concepts/ADOT.md b/wiki/concepts/ADOT.md deleted file mode 100644 index 1fc2f93d..00000000 --- a/wiki/concepts/ADOT.md +++ /dev/null @@ -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 \ No newline at end of file diff --git a/wiki/concepts/AECR-Framework.md b/wiki/concepts/AECR-Framework.md deleted file mode 100644 index 1e88c8b8..00000000 --- a/wiki/concepts/AECR-Framework.md +++ /dev/null @@ -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]] \ No newline at end of file diff --git a/wiki/concepts/AI-ChatOps.md b/wiki/concepts/AI-ChatOps.md deleted file mode 100644 index 569aff89..00000000 --- a/wiki/concepts/AI-ChatOps.md +++ /dev/null @@ -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 增强可观测性 diff --git a/wiki/concepts/AI-driven-RCA.md b/wiki/concepts/AI-driven-RCA.md deleted file mode 100644 index 593108c7..00000000 --- a/wiki/concepts/AI-driven-RCA.md +++ /dev/null @@ -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 缩短平均修复时间 diff --git a/wiki/concepts/AI-powered-Runbooks.md b/wiki/concepts/AI-powered-Runbooks.md deleted file mode 100644 index 1c0eeb8e..00000000 --- a/wiki/concepts/AI-powered-Runbooks.md +++ /dev/null @@ -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]]：无责复盘结果改进运维手册 diff --git a/wiki/concepts/AI-摘要.md b/wiki/concepts/AI-摘要.md deleted file mode 100644 index 0e387509..00000000 --- a/wiki/concepts/AI-摘要.md +++ /dev/null @@ -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 -- [[信息提取]]：从非结构化数据中提取结构化信息 -- [[内容压缩]]：将长内容压缩为简短形式 \ No newline at end of file diff --git a/wiki/concepts/AI-简报工作流.md b/wiki/concepts/AI-简报工作流.md deleted file mode 100644 index c2ec75d5..00000000 --- a/wiki/concepts/AI-简报工作流.md +++ /dev/null @@ -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]] 进行设计输出 -- 核心概念：[[防彈筆記法]] \ No newline at end of file diff --git a/wiki/concepts/AI-簡報流程.md b/wiki/concepts/AI-簡報流程.md deleted file mode 100644 index da6ab9d7..00000000 --- a/wiki/concepts/AI-簡報流程.md +++ /dev/null @@ -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 輸出簡報]] diff --git a/wiki/concepts/AI.md b/wiki/concepts/AI.md deleted file mode 100644 index 774d4a1d..00000000 --- a/wiki/concepts/AI.md +++ /dev/null @@ -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]] \ No newline at end of file diff --git a/wiki/concepts/AI代理.md b/wiki/concepts/AI代理.md deleted file mode 100644 index 2e0f0faf..00000000 --- a/wiki/concepts/AI代理.md +++ /dev/null @@ -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]]：实际执行模式 \ No newline at end of file diff --git a/wiki/concepts/AI生成技能.md b/wiki/concepts/AI生成技能.md deleted file mode 100644 index 94043e22..00000000 --- a/wiki/concepts/AI生成技能.md +++ /dev/null @@ -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生成技能]] \ No newline at end of file diff --git a/wiki/concepts/AI结对执行.md b/wiki/concepts/AI结对执行.md deleted file mode 100644 index 04db8d19..00000000 --- a/wiki/concepts/AI结对执行.md +++ /dev/null @@ -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]] \ No newline at end of file diff --git a/wiki/concepts/AI自动回复.md b/wiki/concepts/AI自动回复.md deleted file mode 100644 index 78de00ad..00000000 --- a/wiki/concepts/AI自动回复.md +++ /dev/null @@ -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 ← [[业务知识库]] \ No newline at end of file diff --git a/wiki/concepts/AI视频生成.md b/wiki/concepts/AI视频生成.md deleted file mode 100644 index 45aa5422..00000000 --- a/wiki/concepts/AI视频生成.md +++ /dev/null @@ -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 \ No newline at end of file diff --git a/wiki/concepts/AI辅助剪辑.md b/wiki/concepts/AI辅助剪辑.md deleted file mode 100644 index e2231e3d..00000000 --- a/wiki/concepts/AI辅助剪辑.md +++ /dev/null @@ -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辅助剪辑]] diff --git a/wiki/concepts/AI配音.md b/wiki/concepts/AI配音.md deleted file mode 100644 index 43d4cf38..00000000 --- a/wiki/concepts/AI配音.md +++ /dev/null @@ -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技术 \ No newline at end of file diff --git a/wiki/concepts/AMI-End-of-Life.md b/wiki/concepts/AMI-End-of-Life.md deleted file mode 100644 index 81ab9a6a..00000000 --- a/wiki/concepts/AMI-End-of-Life.md +++ /dev/null @@ -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 -- 保持现有应用兼容性的同时完成操作系统升级 \ No newline at end of file diff --git a/wiki/concepts/AMI-Roadmap.md b/wiki/concepts/AMI-Roadmap.md deleted file mode 100644 index 80198b6a..00000000 --- a/wiki/concepts/AMI-Roadmap.md +++ /dev/null @@ -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 \ No newline at end of file diff --git a/wiki/concepts/AMI-Sharing.md b/wiki/concepts/AMI-Sharing.md deleted file mode 100644 index 67b5e12a..00000000 --- a/wiki/concepts/AMI-Sharing.md +++ /dev/null @@ -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]] — 跨账号管理 \ No newline at end of file diff --git a/wiki/concepts/ANSI-Escape-Sequence.md b/wiki/concepts/ANSI-Escape-Sequence.md deleted file mode 100644 index 7a2a00c1..00000000 --- a/wiki/concepts/ANSI-Escape-Sequence.md +++ /dev/null @@ -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]]：终端仿真 \ No newline at end of file diff --git a/wiki/concepts/API-Enablement.md b/wiki/concepts/API-Enablement.md deleted file mode 100644 index dec3b919..00000000 --- a/wiki/concepts/API-Enablement.md +++ /dev/null @@ -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 工具 diff --git a/wiki/concepts/API-Gateway.md b/wiki/concepts/API-Gateway.md deleted file mode 100644 index 054ea35b..00000000 --- a/wiki/concepts/API-Gateway.md +++ /dev/null @@ -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 \ No newline at end of file diff --git a/wiki/concepts/ARM64.md b/wiki/concepts/ARM64.md deleted file mode 100644 index c3a35108..00000000 --- a/wiki/concepts/ARM64.md +++ /dev/null @@ -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 \ No newline at end of file diff --git a/wiki/concepts/ATS.md b/wiki/concepts/ATS.md deleted file mode 100644 index 46f8b936..00000000 --- a/wiki/concepts/ATS.md +++ /dev/null @@ -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]] diff --git a/wiki/concepts/AWS-Backup.md b/wiki/concepts/AWS-Backup.md deleted file mode 100644 index 5c0118e0..00000000 --- a/wiki/concepts/AWS-Backup.md +++ /dev/null @@ -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 门户]] \ No newline at end of file diff --git a/wiki/concepts/AWS-Cloud-Adoption-Framework.md b/wiki/concepts/AWS-Cloud-Adoption-Framework.md deleted file mode 100644 index 814ca90c..00000000 --- a/wiki/concepts/AWS-Cloud-Adoption-Framework.md +++ /dev/null @@ -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]] diff --git a/wiki/concepts/AWS-Landing-Zone.md b/wiki/concepts/AWS-Landing-Zone.md deleted file mode 100644 index 394c1502..00000000 --- a/wiki/concepts/AWS-Landing-Zone.md +++ /dev/null @@ -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]] \ No newline at end of file diff --git a/wiki/concepts/AWS-SES.md b/wiki/concepts/AWS-SES.md deleted file mode 100644 index 897fdef9..00000000 --- a/wiki/concepts/AWS-SES.md +++ /dev/null @@ -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]] \ No newline at end of file diff --git a/wiki/concepts/AcademicDetailingCompliance.md b/wiki/concepts/AcademicDetailingCompliance.md deleted file mode 100644 index a8399d17..00000000 --- a/wiki/concepts/AcademicDetailingCompliance.md +++ /dev/null @@ -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]] diff --git a/wiki/concepts/Access-Control.md b/wiki/concepts/Access-Control.md deleted file mode 100644 index f51cee18..00000000 --- a/wiki/concepts/Access-Control.md +++ /dev/null @@ -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]] \ No newline at end of file diff --git a/wiki/concepts/Ad-Strength.md b/wiki/concepts/Ad-Strength.md deleted file mode 100644 index 884e1703..00000000 --- a/wiki/concepts/Ad-Strength.md +++ /dev/null @@ -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]] diff --git a/wiki/concepts/Agent-Archive.md b/wiki/concepts/Agent-Archive.md deleted file mode 100644 index 368f3e48..00000000 --- a/wiki/concepts/Agent-Archive.md +++ /dev/null @@ -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]] \ No newline at end of file diff --git a/wiki/concepts/Agent-Chain.md b/wiki/concepts/Agent-Chain.md deleted file mode 100644 index af42f060..00000000 --- a/wiki/concepts/Agent-Chain.md +++ /dev/null @@ -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]] \ No newline at end of file diff --git a/wiki/concepts/Agent-Skill-设计模式.md b/wiki/concepts/Agent-Skill-设计模式.md deleted file mode 100644 index 297ebbf1..00000000 --- a/wiki/concepts/Agent-Skill-设计模式.md +++ /dev/null @@ -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]] -- [[渐进式披露]] \ No newline at end of file diff --git a/wiki/concepts/Agent-Task-Visibility.md b/wiki/concepts/Agent-Task-Visibility.md deleted file mode 100644 index 6f918230..00000000 --- a/wiki/concepts/Agent-Task-Visibility.md +++ /dev/null @@ -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]] \ No newline at end of file diff --git a/wiki/concepts/AgentDesignPrinciples.md b/wiki/concepts/AgentDesignPrinciples.md deleted file mode 100644 index c0d71b8e..00000000 --- a/wiki/concepts/AgentDesignPrinciples.md +++ /dev/null @@ -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]] 结合使用 \ No newline at end of file diff --git a/wiki/concepts/AgentFileStructure.md b/wiki/concepts/AgentFileStructure.md deleted file mode 100644 index 1ac966c0..00000000 --- a/wiki/concepts/AgentFileStructure.md +++ /dev/null @@ -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]] 概念关联 \ No newline at end of file diff --git a/wiki/concepts/Agentic-AI.md b/wiki/concepts/Agentic-AI.md deleted file mode 100644 index 9011eddc..00000000 --- a/wiki/concepts/Agentic-AI.md +++ /dev/null @@ -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 提供更智能的动态扩缩 diff --git a/wiki/concepts/Alertmanager.md b/wiki/concepts/Alertmanager.md deleted file mode 100644 index 0c665bb5..00000000 --- a/wiki/concepts/Alertmanager.md +++ /dev/null @@ -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]]（可选集成） \ No newline at end of file diff --git a/wiki/concepts/Amazon-Bedrock.md b/wiki/concepts/Amazon-Bedrock.md deleted file mode 100644 index bf15fb55..00000000 --- a/wiki/concepts/Amazon-Bedrock.md +++ /dev/null @@ -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]] \ No newline at end of file diff --git a/wiki/concepts/Ambient-Mode.md b/wiki/concepts/Ambient-Mode.md deleted file mode 100644 index 836af1e5..00000000 --- a/wiki/concepts/Ambient-Mode.md +++ /dev/null @@ -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]]：适合长期运行的设备 \ No newline at end of file diff --git a/wiki/concepts/Anachronism.md b/wiki/concepts/Anachronism.md deleted file mode 100644 index e90980b3..00000000 --- a/wiki/concepts/Anachronism.md +++ /dev/null @@ -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 项目 diff --git a/wiki/concepts/Analytics-Feedback-Loop.md b/wiki/concepts/Analytics-Feedback-Loop.md deleted file mode 100644 index a267d88f..00000000 --- a/wiki/concepts/Analytics-Feedback-Loop.md +++ /dev/null @@ -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 -- 分析反馈循环 -- 数据驱动优化 \ No newline at end of file diff --git a/wiki/concepts/Analytics-Reporter.md b/wiki/concepts/Analytics-Reporter.md deleted file mode 100644 index 58afb38f..00000000 --- a/wiki/concepts/Analytics-Reporter.md +++ /dev/null @@ -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]] - diff --git a/wiki/concepts/Annales-School.md b/wiki/concepts/Annales-School.md deleted file mode 100644 index 2b5b8217..00000000 --- a/wiki/concepts/Annales-School.md +++ /dev/null @@ -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） diff --git a/wiki/concepts/Attachment-Theory.md b/wiki/concepts/Attachment-Theory.md deleted file mode 100644 index e9ea1ca0..00000000 --- a/wiki/concepts/Attachment-Theory.md +++ /dev/null @@ -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]] ← 理论创始人 ← [[依恋理论]] diff --git a/wiki/concepts/Audience-Engineering.md b/wiki/concepts/Audience-Engineering.md deleted file mode 100644 index 16f2a94d..00000000 --- a/wiki/concepts/Audience-Engineering.md +++ /dev/null @@ -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]] \ No newline at end of file diff --git a/wiki/concepts/Audit-Readiness.md b/wiki/concepts/Audit-Readiness.md deleted file mode 100644 index 0943e2cb..00000000 --- a/wiki/concepts/Audit-Readiness.md +++ /dev/null @@ -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]] diff --git a/wiki/concepts/Audit-Trail.md b/wiki/concepts/Audit-Trail.md deleted file mode 100644 index f4094f12..00000000 --- a/wiki/concepts/Audit-Trail.md +++ /dev/null @@ -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]] diff --git a/wiki/concepts/Auto-Healing.md b/wiki/concepts/Auto-Healing.md deleted file mode 100644 index 0d1a89ca..00000000 --- a/wiki/concepts/Auto-Healing.md +++ /dev/null @@ -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)]] \ No newline at end of file diff --git a/wiki/concepts/Auto-scaling.md b/wiki/concepts/Auto-scaling.md deleted file mode 100644 index 11899d89..00000000 --- a/wiki/concepts/Auto-scaling.md +++ /dev/null @@ -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 提供自动扩展功能 diff --git a/wiki/concepts/Autonomous-QA.md b/wiki/concepts/Autonomous-QA.md deleted file mode 100644 index d91b1d0c..00000000 --- a/wiki/concepts/Autonomous-QA.md +++ /dev/null @@ -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 \ No newline at end of file diff --git a/wiki/concepts/Awesome-Claude-Skills.md b/wiki/concepts/Awesome-Claude-Skills.md deleted file mode 100644 index ae34d212..00000000 --- a/wiki/concepts/Awesome-Claude-Skills.md +++ /dev/null @@ -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]] \ No newline at end of file diff --git a/wiki/concepts/Azure-Cloud-Adoption-Framework.md b/wiki/concepts/Azure-Cloud-Adoption-Framework.md deleted file mode 100644 index 4ced6198..00000000 --- a/wiki/concepts/Azure-Cloud-Adoption-Framework.md +++ /dev/null @@ -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]] diff --git a/wiki/concepts/B2B-Social-Selling.md b/wiki/concepts/B2B-Social-Selling.md deleted file mode 100644 index b8f9bd7c..00000000 --- a/wiki/concepts/B2B-Social-Selling.md +++ /dev/null @@ -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]] \ No newline at end of file diff --git a/wiki/concepts/BCG-Pyramid-Principle.md b/wiki/concepts/BCG-Pyramid-Principle.md deleted file mode 100644 index 66752c4f..00000000 --- a/wiki/concepts/BCG-Pyramid-Principle.md +++ /dev/null @@ -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]] \ No newline at end of file diff --git a/wiki/concepts/BM25.md b/wiki/concepts/BM25.md deleted file mode 100644 index 1156f8af..00000000 --- a/wiki/concepts/BM25.md +++ /dev/null @@ -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 \ No newline at end of file diff --git a/wiki/concepts/BOOTSTRAP.md b/wiki/concepts/BOOTSTRAP.md deleted file mode 100644 index ef02d1f6..00000000 --- a/wiki/concepts/BOOTSTRAP.md +++ /dev/null @@ -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 的工作台目录 \ No newline at end of file diff --git a/wiki/concepts/BOSCARD.md b/wiki/concepts/BOSCARD.md deleted file mode 100644 index 141ca5b1..00000000 --- a/wiki/concepts/BOSCARD.md +++ /dev/null @@ -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)]]：识别项目相关方的方法论 \ No newline at end of file diff --git a/wiki/concepts/BYOD.md b/wiki/concepts/BYOD.md deleted file mode 100644 index f4c5ca50..00000000 --- a/wiki/concepts/BYOD.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -title: "BYOD" -type: concept -tags: [] ---- - -## Definition -Bring Your Own Device，自带设备。允许员工使用个人设备（笔记本、手机、平板）访问企业资源的工作模式。 - -## Security Considerations -- 终端数据保护 -- 企业数据与个人数据隔离 -- 远程擦除能力 -- 多因素认证 - -## Related Concepts -- [[VDI]] -- [[SAML]] \ No newline at end of file diff --git a/wiki/concepts/Barthes-五代码.md b/wiki/concepts/Barthes-五代码.md deleted file mode 100644 index 152e5e14..00000000 --- a/wiki/concepts/Barthes-五代码.md +++ /dev/null @@ -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 diff --git a/wiki/concepts/BibTeX-BibLaTeX.md b/wiki/concepts/BibTeX-BibLaTeX.md deleted file mode 100644 index f2657237..00000000 --- a/wiki/concepts/BibTeX-BibLaTeX.md +++ /dev/null @@ -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模板]]：模板决定引用样式 \ No newline at end of file diff --git a/wiki/concepts/Big-Five-Personality-Framework.md b/wiki/concepts/Big-Five-Personality-Framework.md deleted file mode 100644 index a4a75e55..00000000 --- a/wiki/concepts/Big-Five-Personality-Framework.md +++ /dev/null @@ -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]] diff --git a/wiki/concepts/Bind-Mount.md b/wiki/concepts/Bind-Mount.md deleted file mode 100644 index 21776014..00000000 --- a/wiki/concepts/Bind-Mount.md +++ /dev/null @@ -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 持久化数据的另一种方式 \ No newline at end of file diff --git a/wiki/concepts/Bird-Skill.md b/wiki/concepts/Bird-Skill.md deleted file mode 100644 index 97719e4a..00000000 --- a/wiki/concepts/Bird-Skill.md +++ /dev/null @@ -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 侧重于操作执行（发推、互动、抽奖等） \ No newline at end of file diff --git a/wiki/concepts/Blackbox_exporter.md b/wiki/concepts/Blackbox_exporter.md deleted file mode 100644 index c557e2e0..00000000 --- a/wiki/concepts/Blackbox_exporter.md +++ /dev/null @@ -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]]（可选集成） \ No newline at end of file diff --git a/wiki/concepts/Bloom's-Taxonomy.md b/wiki/concepts/Bloom's-Taxonomy.md deleted file mode 100644 index ba0a483a..00000000 --- a/wiki/concepts/Bloom's-Taxonomy.md +++ /dev/null @@ -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 四级评估模型]]：效果评估 diff --git a/wiki/concepts/Book-Co-Author-Agent.md b/wiki/concepts/Book-Co-Author-Agent.md deleted file mode 100644 index b78cfc69..00000000 --- a/wiki/concepts/Book-Co-Author-Agent.md +++ /dev/null @@ -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 diff --git a/wiki/concepts/Bootable-USB.md b/wiki/concepts/Bootable-USB.md deleted file mode 100644 index bce7970f..00000000 --- a/wiki/concepts/Bootable-USB.md +++ /dev/null @@ -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 修复系统故障 \ No newline at end of file diff --git a/wiki/concepts/Bot.md b/wiki/concepts/Bot.md deleted file mode 100644 index 861c1ea1..00000000 --- a/wiki/concepts/Bot.md +++ /dev/null @@ -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]] — 检索增强生成技术 \ No newline at end of file diff --git a/wiki/concepts/Boto3.md b/wiki/concepts/Boto3.md deleted file mode 100644 index 10f7c2fa..00000000 --- a/wiki/concepts/Boto3.md +++ /dev/null @@ -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 指标 \ No newline at end of file diff --git a/wiki/concepts/BottleRocket.md b/wiki/concepts/BottleRocket.md deleted file mode 100644 index 0cce43c9..00000000 --- a/wiki/concepts/BottleRocket.md +++ /dev/null @@ -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]] \ No newline at end of file diff --git a/wiki/concepts/Bottlerocket-OS.md b/wiki/concepts/Bottlerocket-OS.md deleted file mode 100644 index 8ce843d3..00000000 --- a/wiki/concepts/Bottlerocket-OS.md +++ /dev/null @@ -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]] — 核心维护者和赞助商 diff --git a/wiki/concepts/Brain-Dump.md b/wiki/concepts/Brain-Dump.md deleted file mode 100644 index 36474c7d..00000000 --- a/wiki/concepts/Brain-Dump.md +++ /dev/null @@ -1,15 +0,0 @@ ---- -title: "Brain Dump" -type: concept -tags: [] ---- - -## Definition -一次性输入所有目标、使命和任务的上下文设定方式。用户将所有目标（职业、个人、商业）写入 Agent 上下文，作为后续所有任务的参考依据。 - -## Usage -用户在初始阶段一次性输入所有目标，之后 Agent 每天自动生成任务来推进这些目标。 - -## Related -- [[Goal-Driven Autonomous Tasks]] -- [[每日任务生成]] \ No newline at end of file diff --git a/wiki/concepts/Brand-Foundation-Framework.md b/wiki/concepts/Brand-Foundation-Framework.md deleted file mode 100644 index 6f247c2b..00000000 --- a/wiki/concepts/Brand-Foundation-Framework.md +++ /dev/null @@ -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]]：品牌保护策略 \ No newline at end of file diff --git a/wiki/concepts/Break-Glass-Access.md b/wiki/concepts/Break-Glass-Access.md deleted file mode 100644 index d6ff67dd..00000000 --- a/wiki/concepts/Break-Glass-Access.md +++ /dev/null @@ -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]] \ No newline at end of file diff --git a/wiki/concepts/Budget-Control.md b/wiki/concepts/Budget-Control.md deleted file mode 100644 index 35bf9e3e..00000000 --- a/wiki/concepts/Budget-Control.md +++ /dev/null @@ -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]] \ No newline at end of file diff --git a/wiki/concepts/BudgetFramework.md b/wiki/concepts/BudgetFramework.md deleted file mode 100644 index b6969f71..00000000 --- a/wiki/concepts/BudgetFramework.md +++ /dev/null @@ -1,15 +0,0 @@ ---- -title: "Budget Framework" -type: concept -tags: [finance] -sources: [support-finance-tracker] -last_updated: 2026-04-21 ---- - -定义：组织年度预算的结构化方法，包含按部门/类别拆分、季度差异分析、偏差分类与再分配规则，用于把控支出与指导战略资源分配。 - -## Typical Components -- 部门与类别分解 -- 季度/月度差异分析 -- 偏差触发与纠正流程 -- 预算再分配规范 diff --git a/wiki/concepts/Build-Mode.md b/wiki/concepts/Build-Mode.md deleted file mode 100644 index 27bbb266..00000000 --- a/wiki/concepts/Build-Mode.md +++ /dev/null @@ -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]] \ No newline at end of file diff --git a/wiki/concepts/Bulkification.md b/wiki/concepts/Bulkification.md deleted file mode 100644 index bb23bd70..00000000 --- a/wiki/concepts/Bulkification.md +++ /dev/null @@ -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]] 智能体的核心设计原则 diff --git a/wiki/concepts/Byox.md b/wiki/concepts/Byox.md deleted file mode 100644 index 68b20bc2..00000000 --- a/wiki/concepts/Byox.md +++ /dev/null @@ -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 diff --git a/wiki/concepts/CAPA.md b/wiki/concepts/CAPA.md deleted file mode 100644 index 9f059fc9..00000000 --- a/wiki/concepts/CAPA.md +++ /dev/null @@ -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 \ No newline at end of file diff --git a/wiki/concepts/CAPEX-to-OPEX.md b/wiki/concepts/CAPEX-to-OPEX.md deleted file mode 100644 index a8152ddd..00000000 --- a/wiki/concepts/CAPEX-to-OPEX.md +++ /dev/null @@ -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]] diff --git a/wiki/concepts/CES.md b/wiki/concepts/CES.md deleted file mode 100644 index 89df8f8b..00000000 --- a/wiki/concepts/CES.md +++ /dev/null @@ -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分析]]：忠诚度指标 -- [[流失预测]]：流失预警的输入指标 diff --git a/wiki/concepts/CI-CD-流水线.md b/wiki/concepts/CI-CD-流水线.md deleted file mode 100644 index 98d07fb8..00000000 --- a/wiki/concepts/CI-CD-流水线.md +++ /dev/null @@ -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 流水线]] diff --git a/wiki/concepts/CIS-Benchmarks.md b/wiki/concepts/CIS-Benchmarks.md deleted file mode 100644 index b9de720c..00000000 --- a/wiki/concepts/CIS-Benchmarks.md +++ /dev/null @@ -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]] — 企业标准化镜像 \ No newline at end of file diff --git a/wiki/concepts/CMMI.md b/wiki/concepts/CMMI.md deleted file mode 100644 index 5e946da5..00000000 --- a/wiki/concepts/CMMI.md +++ /dev/null @@ -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]] 相关方法 diff --git a/wiki/concepts/CSAT.md b/wiki/concepts/CSAT.md deleted file mode 100644 index 3758a644..00000000 --- a/wiki/concepts/CSAT.md +++ /dev/null @@ -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]]：衡量客户努力程度 -- [[流失预测]]：满意度建模的输入指标 diff --git a/wiki/concepts/CSS-设计系统.md b/wiki/concepts/CSS-设计系统.md deleted file mode 100644 index 444eafdd..00000000 --- a/wiki/concepts/CSS-设计系统.md +++ /dev/null @@ -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 变量实现主题动态切换 - -## 相关概念 -- [[主题切换]] -- [[组件架构]] -- [[响应式断点策略]] \ No newline at end of file diff --git a/wiki/concepts/Calendar-API.md b/wiki/concepts/Calendar-API.md deleted file mode 100644 index 1b04cff9..00000000 --- a/wiki/concepts/Calendar-API.md +++ /dev/null @@ -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 的命令行工具 diff --git a/wiki/concepts/Calibration-Testing.md b/wiki/concepts/Calibration-Testing.md deleted file mode 100644 index 980b5788..00000000 --- a/wiki/concepts/Calibration-Testing.md +++ /dev/null @@ -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]] \ No newline at end of file diff --git a/wiki/concepts/Campbell-英雄之旅.md b/wiki/concepts/Campbell-英雄之旅.md deleted file mode 100644 index feaba0f5..00000000 --- a/wiki/concepts/Campbell-英雄之旅.md +++ /dev/null @@ -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]] 使用此框架分析英雄叙事结构 diff --git a/wiki/concepts/Canary-Deployment.md b/wiki/concepts/Canary-Deployment.md deleted file mode 100644 index addcf4e0..00000000 --- a/wiki/concepts/Canary-Deployment.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: "Canary Deployment" -type: concept -tags: [deployment, release, strategy] -sources: [] -last_updated: 2026-04-20 ---- - -## Definition -Canary Deployment（金丝雀部署）是一种软件发布策略，逐步将新版本替换为旧版本，通过小范围试点验证新功能的稳定性和可靠性，降低全量部署的风险。 - -## Rationale -- 降低新版本带来的风险 -- 实时监控新版本性能 -- 快速回滚能力 - -## Related Concepts -- [[ECS (Elastic Container Services)]] -- [[Infrastructure as Code (IaC)]] \ No newline at end of file diff --git a/wiki/concepts/Candidate-Experience.md b/wiki/concepts/Candidate-Experience.md deleted file mode 100644 index fe3ff26f..00000000 --- a/wiki/concepts/Candidate-Experience.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: "Candidate Experience" -type: concept -tags: [hr, recruiting, experience] -sources: [recruitment-specialist] -last_updated: 2026-04-20 ---- - -## Definition -Candidate Experience 是候选人从投递、筛选、面试、offer 到入职全过程的体验质量。 - -## Core Principles -- 快速反馈，避免候选人长期等待 -- 尊重候选人时间与信息透明 -- 拒绝也要保持礼貌和专业 -- 候选人体验会反向影响雇主品牌 - -## Related Entities -- [[Recruitment Specialist]] -- [[Employer Brand]] diff --git a/wiki/concepts/Carousel-Narrative-Arc.md b/wiki/concepts/Carousel-Narrative-Arc.md deleted file mode 100644 index ca619715..00000000 --- a/wiki/concepts/Carousel-Narrative-Arc.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "Carousel Narrative Arc" -type: concept -tags: [marketing, content-strategy, social-media, tiktok, instagram] -sources: [marketing-carousel-growth-engine] -last_updated: 2026-04-21 ---- - -## Definition -6-slide 标准叙事结构，用于 TikTok/Instagram 轮播内容，确保内容转化率最大化。 - -## Structure -1. **Hook**：停止滚动 — 使用问题、大胆声明或共鸣痛点 -2. **Problem**：问题域 — 识别目标受众核心痛点 -3. **Agitation**：激化 — 强化问题严重性，可引用竞争对手 -4. **Solution**：解决方案 — 提供产品/服务作为答案 -5. **Feature**：特性 — 展示具体功能/优势/数据 -6. **CTA**：行动号召 — 引导下一步操作 - -## Key Principles -- 视觉一致性：Slide 1 建立所有视觉风格，Slides 2-6 通过 Gemini image-to-image 保持一致 -- 9:16 竖屏格式：768x1376 分辨率，移动端优先 -- 底部 20% 无文字：TikTok 控件覆盖区域 - -## Aliases -- 轮播叙事结构 -- 6-slide Narrative Arc \ No newline at end of file diff --git a/wiki/concepts/Carpenter.md b/wiki/concepts/Carpenter.md deleted file mode 100644 index ec06e417..00000000 --- a/wiki/concepts/Carpenter.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "Carpenter" -description: EKS Auto Mode 的计算控制器，负责基础设施管理和节点生命周期 -type: concept -tags: - - AWS - - EKS - - Controller ---- - -## Definition -Carpenter 是 EKS Auto Mode 的计算控制器，运行在作为核心能力的 Pod 中，负责管理节点生命周期、基础设施配置和 AMI 滚动更新。 - -## Functionality -- 管理节点池配置和实例类型选择 -- 响应控制平面版本变化，自动拉取新 AMI -- 通过滚动升级跨集群部署新 AMI -- 支持动态实例确定和自动整合 - -## Relationship -- 与 [[EKS-Auto-Mode]] 紧密集成，是其核心能力之一 -- 管理 [[BottleRocket]] 操作系统实例 - -## References -- [[public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks-auto-mode]] \ No newline at end of file diff --git a/wiki/concepts/CashFlowManagement.md b/wiki/concepts/CashFlowManagement.md deleted file mode 100644 index 4ea863f5..00000000 --- a/wiki/concepts/CashFlowManagement.md +++ /dev/null @@ -1,15 +0,0 @@ ---- -title: "Cash Flow Management" -type: concept -tags: [finance] -sources: [support-finance-tracker] -last_updated: 2026-04-21 ---- - -定义：系统化的现金收支预测与优化方法，包含滚动预测、季节性因子、低现金预警规则与支付时点优化，用以保证短中期流动性并发现投资机会。 - -## Typical Components -- 收入与付款模式分析 -- 滚动预测（12 个月示例） -- 低现金阈值与行动建议 -- 支付优先级与折扣收益优化 diff --git a/wiki/concepts/Centralized-Logging.md b/wiki/concepts/Centralized-Logging.md deleted file mode 100644 index 995347d0..00000000 --- a/wiki/concepts/Centralized-Logging.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "Centralized Logging" -type: concept -tags: [AWS, Observability, Monitoring] -sources: [how-to-simplify-multi-account-deployments-monitoring-centralized-logs-for-aws-cloudformation-stacksets] -last_updated: 2026-04-19 ---- - -## Summary -集中日志是一种将分散在各处的日志汇聚到统一位置进行监控和分析的可观测性模式。 - -## Definition -Centralized Logging（集中日志）是指将来自多个账号、多个区域或多个服务的日志统一收集到一个中心位置进行存储、查询和分析的架构模式。在 AWS 环境中，通常使用 CloudWatch Logs 或第三方 SIEM 工具实现。 - -## Key Attributes -- **目的**：统一监控、问题排查、安全审计、合规 -- **实现**：CloudWatch Logs、EventBridge、KMS -- **核心组件**：日志组、跨账号订阅、生命周期策略 - -## Why -- 多账号环境下，单个账号登录排查效率低 -- 安全合规要求日志集中存储保留 -- 跨账号问题关联分析需要统一视图 - -## Connections -- [[CloudWatch]] ← 存储 ← [[Centralized Logging]] -- [[EventBridge]] ← 事件转发 ← [[Centralized Logging]] \ No newline at end of file diff --git a/wiki/concepts/Challenger-Sale.md b/wiki/concepts/Challenger-Sale.md deleted file mode 100644 index 0a76b0bf..00000000 --- a/wiki/concepts/Challenger-Sale.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: "Challenger Sale" -type: concept -tags: [sales, methodology, challenger] -last_updated: 2026-04-20 ---- - -## Summary -- 定义：挑战者销售方法论，通过"商业教学"引导买家重新思考自身问题 -- 全称：The Challenger Sale -- 核心：销售不是"满足需求"而是"创造新认知" - -## Core Principles - -### Teaching for Differentiation -- 通过独特洞察挑战买家现有假设 -- 让买家从新角度看待自身问题 - -### 销售代表类型分类 -1. The Hard Worker：努力型，精力充沛但缺乏差异化 -2. The Relationship Builder：关系型，与客户建立良好关系但可能"只做好人" -3. The Lone Wolf：独行侠，自我驱动但难以管理 -4. The Reactive Problem Solver：响应型，快速响应但缺乏主动性 -5. The Challenger：挑战型，挑战客户认知并引导决策 — 最有效 - -### Commercial Teaching Sequence -1. **The Warmer**：展示对客户领域的理解，建立可信度 -2. **The Reframe**：引入挑战客户现有假设的洞察 -3. **Rational Drowning**：量化现状成本，堆砌证据 -4. **Emotional Impact**：将问题个人化，触及决策者情感 -5. **A New Way**：呈现替代方案（还不是产品） -6. **Your Solution**：将产品与新方法连接 - -## Key Differences -- 传统销售：发现需求 → 满足需求 -- Challenger Sale：创造新认知 → 引导决策 - -## Usage -- 适用于复杂 B2B 销售 -- 需要销售代表具备行业深度洞察 -- 与 MEDDPICC 框架配合使用效果最佳 - -## Connections -- [[MEDDPICC]]：资格认证框架 -- [[Deal Strategist]]：实施 Challenger 方法的 AI Agent -- [[Command of the Message]]：价值主张框架 - -## Aliases -- Challenger Method -- Challenger Approach -- 挑战者销售 \ No newline at end of file diff --git a/wiki/concepts/Change-Management.md b/wiki/concepts/Change-Management.md deleted file mode 100644 index a16a36c0..00000000 --- a/wiki/concepts/Change-Management.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: "Change Management" -type: concept -tags: [ITSM, change-management, SRE] -sources: [ctp-topic-30-managing-change] -last_updated: 2026-04-19 ---- - -## Summary -变更管理是 ITSM 的核心流程之一，用于控制和管理 IT 环境的任何变更，降低变更风险并确保服务质量。 - -## Definition -在云转型项目中，变更管理涉及对生产环境或基础设施的任何修改的控制、审批和跟踪。 - -## Change Types - -### 标准变更 (Standard Change) -- 预批准变更，无需变更咨询委员会（CAB）批准 -- 风险低、影响小、高度可预测 -- 应尽可能实现完全自动化（IaC + CI/CD Pipeline） -- 示例：标签更新、配置参数调整等 - -### 正常变更 (Normal Change) -- 包含一定风险或影响的变更 -- 需要 CAB 批准，并可能需要跨团队协调 -- 有预定义的变更窗口 -- 示例：新服务部署、架构变更等 - -### 紧急变更 (Emergency Change) -- 为了缓解事故并尽快恢复服务到期望状态而需要立即执行的变更 -- 事后通过 CAPA/Post-mortem 修复根因 -- 示例：紧急安全补丁、热故障修复等 - -## Related Concepts -- [[ITSM]]：IT 服务管理框架 -- [[SRE]]：站点可靠性工程，变更管理的执行方 -- [[SMACKS Ticket]]：变更记录和管理工具 - -## Related Entities -- [[Brendan Starnig]]：CTP Topic 30 讲师 - -## Connections -- [[ctp-topic-30-managing-change]] ← is_the_source_for \ No newline at end of file diff --git a/wiki/concepts/Channel-ID.md b/wiki/concepts/Channel-ID.md deleted file mode 100644 index f7509463..00000000 --- a/wiki/concepts/Channel-ID.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: "Channel ID" -type: concept -tags: [YouTube, 标识符, API] -date: 2026-04-17 ---- - -## Definition -Channel ID 是 YouTube 频道的唯一标识符，格式为 UC 开头的一串字符，例如 UCPlwvN0w4qFSP1FllALB92w。 - -## Usage -- 用于 YouTube Data API 调用 -- 用于 RSS 订阅（格式：https://www.youtube.com/feeds/videos.xml?channel_id=XXX） -- 可在 n8n 等工作流自动化工具中集成 - -## How to Get -访问 YouTube 频道页面（如 @Numberblocks），使用 view-source 查看页面源码，搜索 channel_id 参数即可找到。 - -## Related -- [[YouTube]]: 提供 Channel ID 的平台 -- [[n8n]]: 可使用 Channel ID 进行工作流集成 \ No newline at end of file diff --git a/wiki/concepts/Character-Arc.md b/wiki/concepts/Character-Arc.md deleted file mode 100644 index b6d0d70d..00000000 --- a/wiki/concepts/Character-Arc.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: "Character Arc" -type: concept -tags: [narrative-theory, character, story-structure] ---- - -## 定义 -角色弧线是角色从故事开始到结束的心理和情感发展轨迹。 - -## 核心检查点（[[Narratologist]] 标准） -1. **Ordinary World（普通世界）**：角色初始状态 -2. **Catalyst（催化剂）**：打破平衡的事件 -3. **Midpoint Shift（转折点）**：虚假胜利或虚假失败 -4. **Dark Night（黑暗之夜）**：最低点 -5. **Transformation（转变）**：谎言/需要冲突的最终解决 - -## 弧线类型 -- **Transformative（转变型）**：角色经历根本性改变 -- **Steadfast（坚定型）**：角色坚守信念但影响他人 -- **Flat（扁平型）**：角色信念被验证但不改变 -- **Tragic（悲剧型）**：角色因致命缺陷而毁灭 -- **Comedic（喜剧型）**：角色通过放下执念获得成长 - -## Want vs Need 结构 -- **Want（欲望）**：角色外在追求的目标 -- **Need（需求）**：角色内心真正需要的成长 -- **Lie（谎言）**：角色持有的错误信念 -- **Truth（真相）**：最终打破谎言的认知 - -## 来源框架 -- [[Narratologist]] 使用此框架评估角色弧线的完整性和一致性 diff --git a/wiki/concepts/Checkpoint-Firewall.md b/wiki/concepts/Checkpoint-Firewall.md deleted file mode 100644 index 3a80739a..00000000 --- a/wiki/concepts/Checkpoint-Firewall.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -id: Checkpoint-Firewall -title: "Checkpoint Firewall" -type: concept -tags: - - AWS - - Cloud-Security - - Firewall - - Tagging -date_added: 2026-04-18 ---- - -## Definition -部署在云环境中的虚拟防火墙，通过集成 AWS 标签实现动态的对象识别和流量过滤。 - -## Key Features -- 基于标签而非 IP 的动态安全控制 -- 支持地理屏蔽、BU 隔离、产品隔离及环境隔离 -- 与 Transit Gateway 集成，作为跨 VPC、访问本地或互联网的流量检查节点 - -## Use Case -- 在 AWS Landing Zone 中实现精细化的流量过滤 -- 通过有序层逻辑按优先级执行安全策略 - -## Related Concepts -- [[Transit Gateway]] -- [[Tagging Methodology]] -- [[Ordered Layer]] \ No newline at end of file diff --git a/wiki/concepts/Checks-Effects-Interactions.md b/wiki/concepts/Checks-Effects-Interactions.md deleted file mode 100644 index 7d478751..00000000 --- a/wiki/concepts/Checks-Effects-Interactions.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: "Checks-Effects-Interactions" -type: concept -tags: [smart-contract, pattern, security] -sources: [blockchain-security-auditor] -last_updated: 2026-04-20 ---- - -## Definition -Checks-Effects-Interactions（检查-效果-交互）是一种智能合约安全设计模式，通过在执行外部调用前完成所有状态更新来防止重入攻击。 - -## Pattern -```solidity -function withdraw() external nonReentrant { - // 1. CHECKS: 验证条件 - uint256 amount = balances[msg.sender]; - require(amount > 0, "No balance"); - - // 2. EFFECTS: 更新状态 - balances[msg.sender] = 0; - - // 3. INTERACTIONS: 执行外部调用 - (bool success,) = msg.sender.call{value: amount}(""); - require(success, "Transfer failed"); -} -``` - -## Why It Works -1. 状态在外部调用前已更新 -2. 攻击者重入时检查失败 -3. 即使外部调用失败，状态也不会不一致 - -## Limitations -- 复杂业务逻辑可能无法严格遵循 -- 需要配合 ReentrancyGuard 作为额外防护 -- 异步操作（如 event emission）应在交互后执行 - -## Connections -- [[Reentrancy]] ← prevents ← [[Checks-Effects-Interactions]] -- [[Smart Contract Pattern]] ← is_type_of ← [[Checks-Effects-Interactions]] - diff --git a/wiki/concepts/Chrome-Profile-Cloning.md b/wiki/concepts/Chrome-Profile-Cloning.md deleted file mode 100644 index 74e49de4..00000000 --- a/wiki/concepts/Chrome-Profile-Cloning.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -id: Chrome-Profile-Cloning -title: Chrome Profile Cloning -type: concept -tags: [浏览器自动化, 认证, OpenClaw] -sources: - - raw/Agent/usecases/local-crm-framework.md -last_updated: 2026-04-17 ---- - -## Definition -复制用户 Chrome 浏览器配置，使 AI Agent 继承用户认证状态的技术手段。 - -## Mechanism -DenchClaw 复制用户的 Chrome profile，这样 Agent 可以直接访问用户已登录的网站，无需处理 OAuth 流程或 API 密钥。 - -## Benefits -- 绕过 OAuth 流程和 API 速率限制 -- Agent 看到和操作的内容与用户一致 -- 无需额外凭证管理 - -## Use Cases -- 从 HubSpot 导入数据 -- 抓取需要登录的网页内容 -- 自动化需要认证的 Web 操作 - -## Related -- [[DenchClaw]]：使用此技术的框架 -- [[Chrome]]：被克隆的浏览器 -- [[Local CRM Framework with DenchClaw]] \ No newline at end of file diff --git a/wiki/concepts/Clash.md b/wiki/concepts/Clash.md deleted file mode 100644 index af58ff37..00000000 --- a/wiki/concepts/Clash.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: Clash -type: concept -tags: [proxy, 科学上网] -date: 2026-04-16 ---- - -## Summary -- 定义：基于Go语言开发的代理客户端，支持规则分流 -- 内核：GitHub开源项目 clash/clash -- 特点：高性能、支持多种协议、支持规则分流 - -## Key Characteristics -- 支持代理协议：Shadowsocks、ShadowsocksR、V2Ray、Trojan、HTTP、SOCKS5 -- 支持规则分流：根据域名、IP、地理位置等分流 -- 支持策略组：自动测速、自动选择最优节点 -- 支持GeoIP规则：国内直连、海外代理 - -## Components -- 配置文件（YAML格式）：定义规则和节点 -- 订阅链接：远程配置文件URL -- Dashboard：Web管理界面 - -## Use Cases -- 路由器梅林固件上的科学上网（MerlinClash） -- PC/Mac端科学上网 -- 安卓/iOS端科学上网 - -## Connections -- [[Clash]] ← implements ← [[科学上网]] -- [[MerlinClash]] ← based_on ← [[Clash]] \ No newline at end of file diff --git a/wiki/concepts/Claude-Code-Templates.md b/wiki/concepts/Claude-Code-Templates.md deleted file mode 100644 index 9c592355..00000000 --- a/wiki/concepts/Claude-Code-Templates.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: "Claude Code Templates" -type: concept -tags: [] -date: 2026-04-17 ---- - -## Definition -Claude Code 预配置模板平台，提供开箱即用的 Skills、Agents、MCP 模板。 - -## Types -- Skills：可扩展的 Claude Code 技能模块 -- Agents：预配置的代理模板 -- MCP：Model Context Protocol 集成模板 - -## Installation -```bash -npx claude-code-templates@latest --skill= --yes -``` - -## Related Entities -- [[AITmpl]]：模板提供网站 \ No newline at end of file diff --git a/wiki/concepts/Claude-Skills.md b/wiki/concepts/Claude-Skills.md deleted file mode 100644 index 3a2dd3ed..00000000 --- a/wiki/concepts/Claude-Skills.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: Claude Skills -type: concept -tags: [] ---- - -## Definition -写给 Claude 的"说明书"和"SOP（标准作业程序）"，将反复执行、有固定流程的任务拆解为 AI 能理解、能稳定复用、能自动执行的一套流程。 - -## Core Components -- 任务拆解：将复杂任务分解为可复用的步骤 -- Prompt 结构：精确定义输入、输出和边界 -- 参数含义：明确各参数的作用和取值 -- 容错策略：处理异常情况的机制 - -## Categories -- 办公自动化（Office Suite）：Word/PDF/PPT/Excel 创建、编辑、分析 -- 开发者工具箱（Developer Tools）：MCP Server、Web 应用测试、Artifacts 构建 -- 创意类（Creative）：算法艺术、Canvas 设计、主题生成工厂 - -## Key Repositories -- anthropics/skills：官方仓库，3.2 万星 -- ComposioHQ/awesome-claude-skills -- VoltAgent/awesome-claude-skills -- BehiSecc/awesome-claude-skills - -## Skill Aggregators -- skillsmp.com -- aitmpl.com/skills -- claudemarketplaces.com - -## Significance -Claude Skills 的爆发标志着从提示词工程（Prompt Engineering）迈向流程工程（Process Engineering）。未来最有价值的不是谁 Prompt 写得最好，而是谁最懂业务流程、能把经验沉淀为 SOP、能把 SOP 交给 AI 稳定执行。 - -## Aliases -- AI Skills -- LLM Skills -- Claude Skill \ No newline at end of file diff --git a/wiki/concepts/Clone-Faces.md b/wiki/concepts/Clone-Faces.md deleted file mode 100644 index 8be049b1..00000000 --- a/wiki/concepts/Clone-Faces.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "Clone Faces" -type: concept -tags: [AI Generation, Bias, Image] -date: 2026-04-20 ---- - -## Definition -AI 在生成多元群体图像或视频时，生成多个版本相同面孔的问题。这是基础图像模型（如 Midjourney、Sora、Runway）的系统性缺陷，需要通过显式约束防止。 - -## Why It Happens -- 模型的训练数据偏向特定面部特征 -- 缺乏对面部多样性的显式约束 -- 文本到图像的映射在处理"多样化群体"时产生重复 - -## How to Counter -- 明确要求不同的面部结构、年龄和体型 -- 使用负向提示如"no duplicate faces"、"no cloned faces" -- 在提示词中指定 intersectional variance（交叉多样性） - -## Related Concepts -- [[InclusiveVisualsSpecialist]] — 对抗此问题的专家角色 -- [[NegativePromptLibrary]] — 提供防止此问题的负向提示库 -- [[GibberishText]] — 类似的 AI 幻觉问题 \ No newline at end of file diff --git a/wiki/concepts/Cloud-Adoption.md b/wiki/concepts/Cloud-Adoption.md deleted file mode 100644 index 28396d1e..00000000 --- a/wiki/concepts/Cloud-Adoption.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: "Cloud Adoption" -type: concept -tags: [Cloud, Process] -sources: [Cloud-Maturity-Model-A-Detailed-Guide-For-Cloud-Adoption] -last_updated: 2025-02-28 ---- - -## Summary -Cloud Adoption（云采纳）是将工作负载和服务从本地基础设施迁移到云环境的过程。 - -## Definition -云采纳涉及将应用程序、数据和工作负载从本地数据中心迁移到公有云、私有云或混合云环境。 - -## Key Stages -根据 Cloud Maturity Model，云采纳分为 6 个成熟度等级： -1. Level 0: 无云准备 -2. Level 1: 初始就绪 -3. Level 2: 可重复机会主义 -4. Level 3: 系统化和文档化 -5. Level 4: 可测量 -6. Level 5: 优化级 - -## Best Practices -1. 设定清晰的云采纳目标 -2. 评估当前成熟度等级 -3. 选择合适的云成熟度模型 -4. 遵循治理和合规要求 -5. 实施安全和风险管理 - -## Connections -- [[Cloud-Maturity-Model]] ← defines ← [[Cloud-Adoption]] -- [[Cloud-Adoption]] ← enables ← [[CAPEX-to-OPEX]] diff --git a/wiki/concepts/Cloud-Center-of-Excellence-CCOE.md b/wiki/concepts/Cloud-Center-of-Excellence-CCOE.md deleted file mode 100644 index 7685efee..00000000 --- a/wiki/concepts/Cloud-Center-of-Excellence-CCOE.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: "Cloud Center of Excellence (CCOE)" -type: concept -tags: [Cloud, Organization] -sources: [Cloud-Maturity-Model-A-Detailed-Guide-For-Cloud-Adoption] -last_updated: 2025-02-28 ---- - -## Summary -Cloud Center of Excellence（云卓越中心，CCOE）是推动云采纳和治理的核心组织单元。 - -## Definition -CCOE 是一个专门的团队，负责制定云策略、标准和最佳实践，指导组织内的云采纳工作。 - -## Key Responsibilities -- 建立云治理框架 -- 制定云标准和策略 -- 提供云专业知识 -- 支持云迁移项目 - -## Connections -- [[Cloud-Center-of-Excellence-CCOE]] ← supports ← [[Cloud-Maturity-Model]] diff --git a/wiki/concepts/Cloud-Computing.md b/wiki/concepts/Cloud-Computing.md deleted file mode 100644 index 7c1c8b53..00000000 --- a/wiki/concepts/Cloud-Computing.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: "Cloud Computing" -type: concept -tags: [Cloud, Computing-Model] -sources: [Public-vs-Private-vs-Hybrid-Cloud-Differences-Explained] -last_updated: 2025-06-18 ---- - -## Summary -Cloud Computing（云计算）是一种通过互联网远程访问计算资源（服务器、存储、应用程序）的服务模式，用户无需管理本地硬件。 - -## Definition -云计算是指通过互联网（"云"）远程使用计算资源和服务的方式。应用程序、数据和处理都在第三方服务器上运行，用户通过终端设备访问。与传统本地部署相比，云计算具有弹性扩展、按需付费和免维护等优势。 - -## Key Characteristics -- 远程访问：通过互联网连接使用 -- 资源共享：多个用户共享同一基础设施 -- 弹性扩展：根据需求快速增减资源 -- 按需付费：按实际使用量计费 -- 免维护：由服务商负责硬件管理和更新 - -## Service Models -- [[IaaS]]（基础设施即服务）：提供虚拟计算资源 -- [[PaaS]]（平台即服务）：提供应用开发和部署平台 -- [[SaaS]]（软件即服务）：以订阅方式提供软件应用 - -## Deployment Models -- [[Public-Cloud]]：公有云，共享交付 -- [[Private-Cloud]]：私有云，专属部署 -- [[Hybrid-Cloud]]：混合云，结合公有和私有云 - -## Shared Responsibility Model -云计算采用共享责任模型： -- 云服务商负责：基础设施运营、物理安全、服务器维护 -- 客户负责：访问权限管理、数据安全、加密、灾难恢复 - -## Key Drivers -- 减少复杂性 -- 优化 DevOps -- CapEx 转 OpEx -- 为未来做准备 - -## Connections -- [[Cloud-Computing]] ← delivers ← [[IaaS]] -- [[Cloud-Computing]] ← delivers ← [[PaaS]] -- [[Cloud-Computing]] ← delivers ← [[SaaS]] -- [[Cloud-Computing]] ← implements ← [[Public-Cloud]] -- [[Cloud-Computing]] ← implements ← [[Private-Cloud]] -- [[Cloud-Computing]] ← implements ← [[Hybrid-Cloud]] -- [[Cloud-Computing]] ← enables ← [[Cloud-Migration]] -- [[Cloud-Computing]] ← requires ← [[Cloud-Security]] diff --git a/wiki/concepts/Cloud-Guardrails.md b/wiki/concepts/Cloud-Guardrails.md deleted file mode 100644 index f5dbd807..00000000 --- a/wiki/concepts/Cloud-Guardrails.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: "Cloud Guardrails" -type: concept -tags: [Cloud, Security, Guardrails, Enterprise-Architecture] -last_updated: 2026-04-18 ---- - -## Definition -云守护栏（Cloud Guardrails）捕获可扩展性、成本最小化和灵活性的强制性要求和最佳实践。 - -## Key Attributes -- **Purpose**：确保云环境符合企业安全和治理标准 -- **Scope**：应用于所有云工作负载 -- **Implementation**：通过 Landing Zone 框架自动执行 - -## Core Components -- 设计概念（Design Concepts） -- 能力（Capabilities） -- 最佳实践（Best Practices） - -## Design Principles -- Cloud-First：优先使用云原生服务 -- Well-Architected Frameworks：遵循架构最佳实践 -- Infrastructure as Code (Terraform)：基础设施即代码 -- Resource Tagging：资源标签策略 - -## Executable Packaging -优先使用现有云服务和托管服务，最小化自定义代码。 - -## Functional Partitioning -将单体应用分解为更小的独立块或无服务器功能。 - -## Relationships -- [[Enterprise Architecture]] → defines → [[Cloud Guardrails]] -- [[Cloud Guardrails]] → enforces → [[Landing Zone]] -- [[Terraform]] → implements → [[Cloud Guardrails]] - -## See Also -- [[Landing Zone]] -- [[Enterprise Architecture]] -- [[Terraform]] -- [[Zero Trust Architecture]] \ No newline at end of file diff --git a/wiki/concepts/Cloud-Health.md b/wiki/concepts/Cloud-Health.md deleted file mode 100644 index 32e76ddf..00000000 --- a/wiki/concepts/Cloud-Health.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: "Cloud Health" -type: concept -tags: - - FinOps - - AWS - - Cost-Monitoring -date: 2026-04-19 ---- - -## Summary -- 定义：云成本分析和监控工具，由 CloudHealth Technologies 开发，后被 VMware 收购 -- 用途：提供资源清单、成本分析和月度账单洞察 -- 价值：帮助企业实现云成本可视化、优化资源使用 - -## Aliases -- AWS CloudHealth -- VMware CloudHealth - -## Key Features -- 资源清单管理 -- 成本分析报告 -- 月度账单洞察 -- 优化建议生成 -- 多云支持 - -## Connections -- [[PCG-Team]] — 使用 Cloud Health 进行成本监控 -- [[Cost-Optimization]] — 提供优化建议 - ---- - -*最后更新: 2026-04-19* \ No newline at end of file diff --git a/wiki/concepts/Cloud-Maturity-Model.md b/wiki/concepts/Cloud-Maturity-Model.md deleted file mode 100644 index 8af6a63d..00000000 --- a/wiki/concepts/Cloud-Maturity-Model.md +++ /dev/null @@ -1,52 +0,0 @@ ---- -title: "Cloud Maturity Model" -type: concept -tags: [Cloud, Framework, Maturity-Model] -sources: [Cloud-Maturity-Model-A-Detailed-Guide-For-Cloud-Adoption] -last_updated: 2025-02-28 ---- - -## Summary -Cloud Maturity Model（云成熟度模型，CMM）是一种用于评估组织云采纳就绪程度的框架，适用于各种规模和云经验水平的组织。 - -## Definition -CMM 通过 5 个等级帮助组织评估当前云采纳状态并规划迁移路径，同时覆盖业务和技术两大维度的多项能力领域。 - -## Key Components -### 5 成熟度等级 -- **Level 0: No Cloud Readiness** — 无云准备，完全依赖遗留系统 -- **Level 1: Initial Readiness** — 初始就绪，有少量云服务使用但无清晰策略 -- **Level 2: Repeatable, opportunistic** — 可重复，已建立 IT 和采购流程 -- **Level 3: Systematic and Documented** — 系统化，有文档化实践和合规性 -- **Level 4: Measured** — 可测量，有透明治理模型 -- **Level 5: Optimized** — 优化级，开放互操作的云环境 - -### 业务能力领域 (16项) -Finance、Enterprise Strategy、Organizational Structure、Culture、Governance、Skills、Compliance、Business Processes、Procurement、Commercial、Portfolio Management、Projects - -### 技术能力领域 (18项) -IT Architecture、Applications、Management Tools、Operations (IT) Processes、DevOps、Security、IaaS、PaaS、STaaS、SaaS、IPaaS、Information Services、Data、Network、AI、IoT、APIs - -## Benefits -1. 增强战略规划 -2. 改善团队沟通 -3. 提升应用性能 -4. 增强安全性和性能 -5. 缩短上市时间 -6. 行业基准对比 -7. 成本节约 - -## Best Practices -1. 设定云采纳目标 -2. 确定当前成熟度等级 -3. 选择合适的云成熟度模型 -4. 遵循治理和合规 -5. 遵循安全和风险管理 - -## Connections -- [[Cloud-Maturity-Model]] ← extends ← [[Cloud-Security-Maturity-Model-CSMM]] -- [[Cloud-Maturity-Model]] ← extends ← [[AWS-Cloud-Adoption-Framework]] -- [[Cloud-Maturity-Model]] ← extends ← [[Azure-Cloud-Adoption-Framework]] -- [[Cloud-Maturity-Model]] ← extends ← [[Google-Cloud-Adoption-Framework]] -- [[Cloud-Center-of-Excellence-CCOE]] ← supports ← [[Cloud-Maturity-Model]] -- [[Open-Alliance-for-Cloud-Adoption-OACA]] ← defines ← [[Cloud-Maturity-Model]] diff --git a/wiki/concepts/Cloud-Migration.md b/wiki/concepts/Cloud-Migration.md deleted file mode 100644 index cb2a5ce2..00000000 --- a/wiki/concepts/Cloud-Migration.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: Cloud Migration -type: concept -tags: [Cloud, Migration, DevOps] -sources: [The-Myths-and-Misconceptions-About-Cloud-Computing-LinkedIn.md] -last_updated: 2025-03-02 ---- - -## Definition -云迁移是指将工作负载、应用程序和数据从本地基础设施迁移到云环境的过程。 - -## Migration Strategies -- 阶段式迁移（Phased Migration）：分阶段逐步迁移工作负载 -- 混合云迁移（Hybrid Cloud Migration）：保留部分本地工作负载 -- 云迁移服务（Cloud Migration Services）：专业迁移工具和支持 - -## Key Claims -- 虽然迁移到云需要仔细规划，但云提供商提供广泛的工具和支持来促进这一过程 -- 阶段式迁移、混合云解决方案和专业云迁移服务有助于降低风险并确保平滑过渡 -- 借助正确的方法，企业可以以最小 disruption 将工作负载迁移到云 - -## Connections -- [[Cloud-Adoption]] ← includes ← [[Cloud-Migration]]：云采纳包含迁移阶段 -- [[Hybrid-Cloud]] ← uses ← [[Cloud-Migration]]：混合云是迁移策略之一 -- [[DevOps]] ← supports ← [[Cloud-Migration]]：DevOps 实践支持平滑迁移 diff --git a/wiki/concepts/Cloud-Native.md b/wiki/concepts/Cloud-Native.md deleted file mode 100644 index 21b77156..00000000 --- a/wiki/concepts/Cloud-Native.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: "Cloud Native" -type: concept -tags: [Cloud, Architecture] -sources: [Cloud-Maturity-Model-A-Detailed-Guide-For-Cloud-Adoption] -last_updated: 2025-02-28 ---- - -## Summary -Cloud Native（云原生）是一种利用云平台原生特性构建和运行应用程序的方法论。 - -## Definition -云原生应用充分利用云平台的动态特性，在公有云、私有云和混合云环境中运行。 - -## Key Characteristics -- 容器化部署 -- 微服务架构 -- 动态管理 -- 利用 CNCF 生态系统 - -## Connections -- [[Cloud-Native]] ← part_of ← [[Cloud-Maturity-Model]] diff --git a/wiki/concepts/Cloud-Operating-Model.md b/wiki/concepts/Cloud-Operating-Model.md deleted file mode 100644 index ba5cb6b8..00000000 --- a/wiki/concepts/Cloud-Operating-Model.md +++ /dev/null @@ -1,49 +0,0 @@ ---- -title: "Cloud Operating Model" -type: concept -tags: [cloud, governance, operating-model] -sources: [Cloud-Operating-Model-Key-Strategies-and-Best-Practices] -last_updated: 2026-04-16 ---- - -## Summary -Cloud Operating Model（云运营模型）是组织管理云资源、安全、成本和治理的框架，是现代云战略的支柱。 - -## Definition -云运营模型定义了组织如何在云环境中运营，确保治理、安全、成本优化和运营敏捷性的平衡。 - -## Four Pillars -1. **Governance & Compliance**（治理与合规）：标准化治理确保跨云环境合规 -2. **Automation**（自动化）：IaC、CI/CD、事件驱动自动化提升效率 -3. **Security**（安全）：Zero Trust、加密、实时监控 -4. **Cost Management（FinOps）**：成本追踪、优化和预算控制 - -## Implementation Steps -1. **评估云成熟度**：确定组织当前所处阶段（Ad-hoc → Cloud-Native） -2. **建立治理框架**：定义 IAM 角色、策略、审计规则 -3. **自动化运营**：采用 IaC、CI/CD、Serverless -4. **实施 FinOps**：实时成本监控、预留实例、自动扩缩容 -5. **强化安全**：Zero Trust、自动合规检查、威胁检测 -6. **持续优化**：AIOps、自我修复系统、AI 驱动决策 - -## Key Benefits -- 标准化治理 → 确保跨环境合规 -- 成本优化 → 防止超支 -- 改进安全 → 自动化策略和访问控制 -- 运营敏捷 → DevOps、CI/CD、自动扩缩容 -- 多云灵活性 → 减少供应商锁定 - -## Industry Applications -- **金融**：自动化合规、成本治理、Zero Trust -- **医疗**：自动合规执行、数据加密、AI 诊断 -- **零售**：自动扩缩容、多云策略 -- **SaaS**：DevOps 加速、容器化架构、DevSecOps - -## Connections -- [[Cloud Operating Model]] ← extends ← [[Cloud Maturity Model]] -- [[Cloud Operating Model]] ← includes ← [[Governance Framework]] -- [[Cloud Operating Model]] ← includes ← [[FinOps]] -- [[Cloud Operating Model]] ← includes ← [[Zero Trust Architecture]] -- [[Cloud Operating Model]] ← includes ← [[AIOps]] -- [[Multi-Cloud Strategy]] ← enabled_by ← [[Cloud Operating Model]] -- [[Cloud Adoption]] ← requires ← [[Cloud Operating Model]] \ No newline at end of file diff --git a/wiki/concepts/Cloud-Security-Maturity-Model-CSMM.md b/wiki/concepts/Cloud-Security-Maturity-Model-CSMM.md deleted file mode 100644 index 86654811..00000000 --- a/wiki/concepts/Cloud-Security-Maturity-Model-CSMM.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: "Cloud Security Maturity Model (CSMM)" -type: concept -tags: [Cloud, Security, Maturity-Model] -sources: [Cloud-Maturity-Model-A-Detailed-Guide-For-Cloud-Adoption] -last_updated: 2025-02-28 ---- - -## Summary -Cloud Security Maturity Model（云安全成熟度模型，CSMM）是一种评估云安全计划成熟度的框架。 - -## Definition -CSMM 评估组织云安全在 12 个类别和 3 个不同领域中的成熟度水平，通常由 IANS 或 Securosis 提供。 - -## Key Domains -CSMM 涵盖 12 个类别，分布在 3 个不同领域中。 - -## Connections -- [[Cloud-Security-Maturity-Model-CSMM]] ← extends ← [[Cloud-Maturity-Model]] diff --git a/wiki/concepts/Cloud-Security-Posture-Management.md b/wiki/concepts/Cloud-Security-Posture-Management.md deleted file mode 100644 index 20066ad1..00000000 --- a/wiki/concepts/Cloud-Security-Posture-Management.md +++ /dev/null @@ -1,49 +0,0 @@ ---- -title: "Cloud Security Posture Management" -type: concept -tags: [Security, Cloud, CSPM, Compliance, Monitoring] -date: 2026-04-14 ---- - -## Definition -云安全态势管理（Cloud Security Posture Management，CSPM）是一种持续监控云资源配置合规性的解决方案，解决多云环境安全割裂和缺乏统一视图的问题。 - -## Core Problems Solved -- 多云账户安全管理割裂 -- 缺乏公共云安全态势的集中视图 -- 事件响应时间长 -- 合规性评估困难 - -## Core Features -1. **发现（Discovery）**：自动发现云环境中的所有资产 -2. **监控（Monitoring）**：持续监控安全配置 -3. **评估（Assessment）**：基于合规框架（CIS、NIST、ISO）进行评估 -4. **保护（Protection）**：提供修复建议和自动修复能力 - -## Key Requirements -- 整合多个云账户的错误配置到单一平台 -- 提供合规框架视图（CIS、NIST、ISO） -- 支持自定义策略 - -## Selected Solution: Cloud Guard -经过 POC 测试后选中，核心功能包括： -- 态势管理（Posture Management） -- 资产管理（Asset Management） -- 网络配置探索（Network Configuration Exploration） -- 事件管理（Event Management） -- 身份管理（Identity Management） -- 威胁情报（Intelligence） - -## Onboarding Process -新账户在创建过程中自动接入 Cloud Guard，确保全面覆盖和相关规则集的应用。 - -## Related Entities -- [[Coyote]] — Head of Enterprise Application Security - -## Related Concepts -- [[Three-Lines-of-Defense]] -- [[Multi-Cloud]] -- [[Compliance-Enforcement]] - -## Related Sources -- [[CTP Topic 52 3 Lines of Defence (3LoD) framework Cloud Security Posture Management (CSPM)]] \ No newline at end of file diff --git a/wiki/concepts/Cloud-Security.md b/wiki/concepts/Cloud-Security.md deleted file mode 100644 index 9a4ffd13..00000000 --- a/wiki/concepts/Cloud-Security.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: Cloud Security -type: concept -tags: [Cloud, Security, Compliance] -sources: [The-Myths-and-Misconceptions-About-Cloud-Computing-LinkedIn.md] -last_updated: 2025-03-02 ---- - -## Definition -云安全是指保护云计算环境中的数据、应用程序和基础设施免受未经授权访问、泄露、盗窃和破坏的措施和技术的总称。 - -## Core Components -- 加密（Encryption）：数据传输和存储加密 -- 防火墙（Firewall）：网络边界防护 -- 多因素认证（Multi-factor Authentication）：增强身份验证 -- 自动化安全更新：持续漏洞修复 -- 24/7 监控：实时威胁检测 - -## Compliance Standards -- [[ISO-27001]]：信息安全管理系统国际标准 -- [[HIPAA]]：美国健康保险便携性和责任法案 -- [[GDPR]]：欧盟通用数据保护条例 - -## Key Claims -- 云安全通常比本地解决方案更 robust，云提供商投入大量资源于安全措施 -- 许多云平台符合 ISO 27001、HIPAA、GDPR 等严苛行业标准 -- 云提供商提供自动化安全更新和 24/7 监控，降低违规风险 - -## Connections -- [[Cloud-Adoption]] ← depends_on ← [[Cloud-Security]]：云采纳必须以云安全为基础 -- [[Cloud-Security-Maturity-Model-CSMM]] ← related_to ← [[Cloud-Security]]：CSMM 是云安全成熟度评估框架 -- [[DevSecOps]] ← extends ← [[Cloud-Security]]：DevSecOps 在 CI/CD 中集成安全 diff --git a/wiki/concepts/Cloud-Service-Delivery.md b/wiki/concepts/Cloud-Service-Delivery.md deleted file mode 100644 index 16d1e43c..00000000 --- a/wiki/concepts/Cloud-Service-Delivery.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: "Cloud Service Delivery" -type: concept -tags: [Cloud, DevOps, Cloud Operations] -sources: [What-I-know-about-Cloud-Service-Delivery-1] -last_updated: 2026-04-16 ---- - -## Definition -Cloud Service Delivery（云服务交付）是连接云技术能力（IaaS、PaaS、SaaS）与最终用户实际消费服务之间的桥梁，涵盖使云服务可操作、可访问、安全、高性能和有价值 的整个生命周期。 - -## Core Components（核心组成部分） - -### Cloud Service Delivery Team Roles（团队角色） -- Cloud Infrastructure Engineer -- Cloud Operation Engineer (DevOps/SRE) -- Cloud Security Specialists -- Cloud Support Engineer -- Cloud FinOps Engineer - -### 12 Core Management Areas（12个核心管理领域） -1. **Service Provisioning & Deployment**：服务配置与部署 -2. **Infrastructure Management**：基础设施管理 -3. **Platform Management (for PaaS)**：平台管理 -4. **Application Operations & Management**：应用运维管理 -5. **Security & Compliance Management**：安全与合规管理 -6. **Performance & Availability Monitoring**：性能与可用性监控 -7. **Incident & Problem Management**：事件与问题管理 -8. **Change & Configuration Management**：变更与配置管理 -9. **Cost Management & Optimization**：成本管理与优化 -10. **Customer Onboarding & Support**：客户支持与 onboarding -11. **Service Governance & Lifecycle Management**：服务治理与生命周期管理 -12. **Backup, Recovery & Disaster Management**：备份恢复与灾难管理 - -## Related Concepts -- [[DevOps]]：云服务交付的重要方法论基础 -- [[IaaS]]：云服务交付的底层服务模式 -- [[PaaS]]：云服务交付的平台层 -- [[SaaS]]：云服务交付的应用层 -- [[Cloud Native]]：云服务交付的目标架构状态 -- [[Cloud Maturity Model]]：评估云服务交付能力的成熟度框架 -- [[DevSecOps]]：云服务交付中安全管理的最佳实践 -- [[IaC]]：云服务交付中变更配置管理的核心方法 - -## Best Practices Mentioned（最佳实践） -- AWS CloudWatch 作为 Grafana 的数据源进行监控 -- Service Availability Check 使用 APM/BPM、New Relic、AWS CloudWatch Synthetic、Health Page -- WAF（Web Application Firewall）管理 -- IP 白名单支持到租户级别 -- Planned Change vs Emergency Change 区分 -- SLA 99.9% vs 99.99% 可用性对比（参考 uptime.is） diff --git a/wiki/concepts/Cloud-Volume-ONTAP.md b/wiki/concepts/Cloud-Volume-ONTAP.md deleted file mode 100644 index 00d78871..00000000 --- a/wiki/concepts/Cloud-Volume-ONTAP.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: "Cloud Volume ONTAP" -type: concept -tags: - - storage - - AWS - - NetApp -last_updated: 2026-04-18 ---- - -## Definition - -Cloud Volume ONTAP (CVO) 是 NetApp 的云端存储解决方案，纯软件定义的存储设备，运行在 AWS EC2 实例上。 - -## Architecture - -- **部署模式**：单节点或 HA 对（高可用） -- **存储后端**：AWS EBS 卷（GP3、GP2、IO1、IO2、ST1） -- **数据分层**：活跃数据存 EBS，非活跃数据（30天以上）自动迁移到 S3 -- **管理工具**：Cloud Manager - -## Features - -- **协议支持**：NFS、SMB/CIFS、iSCSI、FC -- **数据保护**：Snapshot、Snapmirror、SnapVault -- **加密**：支持 AWS KMS 或 NetApp 自带加密（256位） -- **安全集成**：与 McAfee 杀毒集成（VSES） - -## Components - -- **Aggregate**：磁盘组，组成 RAID 组 -- **FlexVolume**：数据容器，托管在 aggregate 上 -- **Qtree**：卷的子目录，支持权限和配额 -- **LUN**：逻辑单元号，FC 或 iSCSI 的块存储 -- **SVM**：存储虚拟机，支持多租户 - -## Links - -- 对应源页面：[[ctp-topic-46-netapps-on-aws]] \ No newline at end of file diff --git a/wiki/concepts/CloudDrive2.md b/wiki/concepts/CloudDrive2.md deleted file mode 100644 index 2124a8bf..00000000 --- a/wiki/concepts/CloudDrive2.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "CloudDrive2" -type: concept -tags: [cloud-storage, aliyun, nas, mount] -date: 2026-04-16 ---- - -## Definition -CloudDrive2 是一款第三方云盘挂载工具，可以将阿里云盘、115 等云存储服务挂载为本地磁盘，在 NAS 上使用时可通过 Web 界面管理。 - -## Key Features -- 云盘挂载：将云盘映射为本地文件系统路径 -- 多平台支持：支持 Synology、QNAP、威联通等 NAS 设备 -- Web 管理界面：提供图形化配置界面 -- 扫码授权：移动端 App 扫码即可完成云盘授权 -- 离线下载：部分版本支持云盘离线下载功能 - -## Installation (Synology) -1. 在套件中心添加矿神源 -2. 搜索 CloudDrive2 并安装 -3. DSM 7+ 需要执行命令修复权限：`sudo sed -i 's/package/root/g' /var/packages/CloudDrive2/conf/privilege` -4. 打开 Web 界面配置云盘 - -## Related -- [[阿里云盘]]：CloudDrive2 支持挂载的云盘之一 -- [[Synology]]：CloudDrive2 运行的平台 -- [[Docker]]：CloudDrive2 在 NAS 上的运行方式 \ No newline at end of file diff --git a/wiki/concepts/CloudFront.md b/wiki/concepts/CloudFront.md deleted file mode 100644 index 222c3e81..00000000 --- a/wiki/concepts/CloudFront.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: "CloudFront" -type: concept -tags: - - CDN - - AWS - - Content-Delivery -date-added: 2026-04-18 ---- - -## Description -Amazon CloudFront 是 AWS 的内容分发网络（CDN）服务，用于在全球边缘位置缓存和分发静态内容（如图像、视频、应用程序等），降低延迟并提高用户体验。 - -## Role in SaaS Landing Zone -- 在 Product Accounts 中可用作 CDN -- 加速静态内容分发 -- 与 WAF 集成提供安全防护 - -## Related -- [[AWS]]：云服务提供商 -- [[ctp-topic-7-saas-landing-zone-design]]：SaaS Landing Zone 设计 \ No newline at end of file diff --git a/wiki/concepts/Cloudflare-D1.md b/wiki/concepts/Cloudflare-D1.md deleted file mode 100644 index be566ebf..00000000 --- a/wiki/concepts/Cloudflare-D1.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: "Cloudflare D1" -type: concept -tags: [Cloudflare, Database, Serverless] -sources: [] -last_updated: 2026-04-16 ---- - -## Definition -Cloudflare D1 是 Cloudflare 提供的无服务器 SQL 数据库服务，基于 SQLite 实现。 - -## Core Features -- 完全托管，无需服务器管理 -- 按查询次数计费 -- 与 Cloudflare Workers 原生集成 -- 支持读写分离 -- 全球低延迟 - -## Use Cases -- 作为 Web 应用的后端数据库 -- 存储用户数据、会话信息 -- 作为 NodeWarden 等应用的数据库后端 - -## Connections -- [[Cloudflare Workers]] ← integrates_with ← [[Cloudflare D1]] -- [[Serverless-Computing]] ← uses ← [[Cloudflare D1]] \ No newline at end of file diff --git a/wiki/concepts/Cloudflare-R2.md b/wiki/concepts/Cloudflare-R2.md deleted file mode 100644 index a6586d30..00000000 --- a/wiki/concepts/Cloudflare-R2.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "Cloudflare R2" -type: concept -tags: [Cloudflare, Storage, Serverless] -sources: [] -last_updated: 2026-04-16 ---- - -## Definition -Cloudflare R2 是 Cloudflare 提供的无服务器对象存储服务，S3 兼容 API。 - -## Core Features -- 无服务器，按请求计费 -- S3 兼容 API -- 与 Cloudflare Workers 原生集成 -- 无带宽费用（与 S3 的主要区别） -- 支持大文件存储 - -## Use Cases -- 存储静态资源（图片、视频） -- 作为应用附件存储 -- 作为 NodeWarden 的附件存储后端 - -## Connections -- [[Cloudflare Workers]] ← integrates_with ← [[Cloudflare R2]] -- [[Serverless-Computing]] ← uses ← [[Cloudflare R2]] -- [[MinIO]] ← similar_to ← [[Cloudflare R2]] \ No newline at end of file diff --git a/wiki/concepts/Cluster-Autoscaler.md b/wiki/concepts/Cluster-Autoscaler.md deleted file mode 100644 index 524b5cf4..00000000 --- a/wiki/concepts/Cluster-Autoscaler.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: "Cluster Autoscaler" -type: concept -tags: [Kubernetes, Auto-Scaling, GKE, EKS] -sources: [] -last_updated: 2026-04-19 ---- - -## Definition -Cluster Autoscaler 是 Kubernetes 社区的自动扩缩容组件，与 Karpenter 功能类似但实现方式不同。 - -## Key Differences from Karpenter -- 不直接与 EC2 Fleet API 通信，依赖 Kubernetes scheduler -- 无原生 Spot 中断处理，需要额外组件（如 Node Termination Handler） -- 节点管理通过 Node Groups 而非原生资源 -- 不支持工作负载放置的细粒度控制 - -## Use Cases -- GKE：Google Kubernetes Engine 原生支持 -- AKS：Azure Kubernetes Service 支持 -- EKS：需要额外配置 - -## Related Concepts -- [[Karpenter]]：Cluster Autoscaler 的替代方案 -- [[Node-Pools]]：类似 Karpenter 的节点管理概念 - -## Aliases -- Kubernetes Cluster Autoscaler -- CA \ No newline at end of file diff --git a/wiki/concepts/Cognitive-Distortions.md b/wiki/concepts/Cognitive-Distortions.md deleted file mode 100644 index 42f64189..00000000 --- a/wiki/concepts/Cognitive-Distortions.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -title: "Cognitive Distortions" -type: concept -tags: [cognitive-psychology, cbt, cognitive-distortions] -sources: [] -last_updated: 2026-04-20 ---- - -# Cognitive Distortions - -## Aliases -- 认知扭曲 -- 非理性思维 -- Beck Cognitive Distortions - -## Summary -Aaron Beck 提出的概念，描述导致情绪困扰的常见非理性思维模式。认知扭曲是认知行为疗法（CBT）的核心干预目标。 - -## Common Types - -### 绝对化思维（All-or-Nothing Thinking） -非黑即白，无中间地带 -> "如果我不是完美，我就是失败" - -### 过度概括（Overgeneralization） -以单一负面事件得出普遍结论 -> "这件事失败了，所以我永远都不会成功" - -### 灾难化（Catastrophizing） -高估负面事件的可能性和影响 -> "如果这次面试失败，我的人生就完了" - -### 心理过滤（Mental Filter） -只关注负面细节而忽略正面证据 - -### 贬低积极体验（Disqualifying the Positive） -将正面经历归因为运气而非真实成就 - -### 跳跃式结论（Mind Reading / Fortune Telling） -在无证据情况下假设他人负面看法或预测负面结果 - -### 情感推理（Emotional Reasoning） -将情绪当作事实的证据 -> "我感到焦虑，所以一定有危险" - -### "应该"陈述（Should Statements） -使用强制性"应该"导致内疚或愤怒 - -### 标签化（Labeling） -以单一缺点给整个人贴标签 - -### 个人化（Personalization） -将外部事件过度个人化，无根据承担责任感 - -## Applications -- [[Academic Psychologist Agent]] 识别驱动角色决策的具体认知扭曲 -- 设计认知重构干预点 -- 分析角色在压力下的思维模式变化 - -## Connections -- [[Academic Psychologist Agent]] ← 分析工具 ← [[认知扭曲]] -- [[Aaron Beck]] ← 创始人 ← [[认知扭曲]] -- [[Cognitive Behavioral Therapy]] ← 相关疗法 ← [[认知扭曲]] diff --git a/wiki/concepts/Cognitive-Load-Reduction.md b/wiki/concepts/Cognitive-Load-Reduction.md deleted file mode 100644 index 5aeaecac..00000000 --- a/wiki/concepts/Cognitive-Load-Reduction.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: "Cognitive Load Reduction" -type: concept -tags: [ux, behavioral-psychology, productivity] -sources: [product-behavioral-nudge-engine] -last_updated: 2026-04-20 ---- - -## Definition -通过将大量工作流拆分为最小的无摩擦动作，防止用户因决策瘫痪而放弃的核心原则。 - -## Mechanism -- 不展示"你有 14 条未读通知" -- 只展示最关键的 1 个单一行动项 -- 每次推送都提供单一、可操作、低摩擦的下一步 - -## Key Rule -> "Never send a generic 'You have 14 unread notifications' alert. Always provide a single, actionable, low-friction next step." - -## Related Concepts -- [[Micro-Sprint]] -- [[Momentum Nudge]] -- [[Default Bias]] - -## Connections -- [[Behavioral Nudge Engine]] ← implements ← [[Cognitive Load Reduction]] diff --git a/wiki/concepts/Community-Integration.md b/wiki/concepts/Community-Integration.md deleted file mode 100644 index 4cb61f42..00000000 --- a/wiki/concepts/Community-Integration.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: "Community Integration" -type: concept -tags: [reddit, marketing, community-building, engagement] -sources: [] -last_updated: 2026-04-21 ---- - -## Summary -通过持续的有价值参与成为 Reddit 社区可信成员的过程。 - -## Definition -成为 subreddit 社区可信成员的战略方法，包括学习社区规则、文化、时机，并与版主建立良好关系。 - -## Key Phases -1. Subreddit Analysis：识别主要、次要、本地和细分社区 -2. Guidelines Mastery：掌握规则、文化、时机和版主关系 -3. Participation Strategy：开始无推广意图的真实参与 -4. Value Assessment：识别社区痛点和知识差距 - -## Related Concepts -- [[90/10 Rule]]：社区参与的内容比例原则 -- [[Educational Content Leadership]]：通过教育内容建立影响力 - -## Related Agents -- [[Marketing Reddit Community Builder]]：实现社区整合的专业智能体 diff --git a/wiki/concepts/Comparative-Mode.md b/wiki/concepts/Comparative-Mode.md deleted file mode 100644 index 8680eb4e..00000000 --- a/wiki/concepts/Comparative-Mode.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "Comparative Mode" -type: concept -tags: [comparison, research, mode] -last_updated: 2026-04-19 ---- - -## Definition - -Comparative Mode 是 Last30Days skill 的一种研究模式，通过 "X vs Y" 格式生成并排对比研究，帮助用户快速对比两个主题的热门内容、用户痛点和市场观点。 - -## Usage - -```bash -python3 ~/.openclaw/skills/last30days-official/scripts/last30days.py "cursor vs windsurf" -``` - -## Output Structure - -- 双方热门内容并排显示 -- 关键模式对比 -- 推荐行动并列 - -## Related Concepts - -- [[Last-30-Days-Skill]] -- [[Market-Research]] \ No newline at end of file diff --git a/wiki/concepts/Competitive-Intelligence.md b/wiki/concepts/Competitive-Intelligence.md deleted file mode 100644 index 345eba63..00000000 --- a/wiki/concepts/Competitive-Intelligence.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: "Competitive Intelligence" -type: concept -tags: [competition, swot, market-positioning] -sources: [raw/Agent/agency-agents/product/product-trend-researcher.md] -last_updated: 2026-04-20 ---- - -## Definition -竞争情报是系统化收集和分析竞争对手信息的方法，用于制定竞争定位和差异化策略。 - -## Competitive Landscape -- 直接竞争对手：功能对比、定价、市场定位 -- 间接竞争对手：替代方案、邻近市场 -- 新兴玩家：初创企业、新进入者 -- 技术提供商：平台策略、基础设施创新 -- 客户替代方案：DIY 解决方案、变通方案 - -## Frameworks -- SWOT 分析（优势/劣势/机会/威胁） -- 市场差距分析（Market Gap Analysis） -- 竞争定位分析（Competitive Positioning） -- 替代威胁评估（Substitution Threat Assessment） diff --git a/wiki/concepts/Compliance-Certification.md b/wiki/concepts/Compliance-Certification.md deleted file mode 100644 index 0d41ebf7..00000000 --- a/wiki/concepts/Compliance-Certification.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: Compliance & Certification -type: concept -tags: [compliance, certification, cross-border, product-safety] -aliases: [产品合规认证, CE, FCC, FDA, PSE, WEEE, EPR] ---- - -## Definition -跨境电商产品合规认证和法规遵循，是进入目标市场的必要条件。 - -## Key Certifications - -### US Market -- FCC：电子产品认证 -- FDA：食品、化妆品、医疗器械 -- CPC：儿童产品安全证书 - -### EU Market -- CE：电子产品安全认证（强制性） -- WEEE：电子废物回收指令 -- EPR：包装法（德国 VerpackG） - -### UK Market -- UKCA：英国符合性评估 -- UK VAT：增值税注册 - -### Japan Market -- PSE：电气产品安全认证 -- 进口关税和消费税 - -## Intellectual Property -- 商标注册：Madrid 马德里体系 -- 专利检索和设计规避 -- 版权保护和平台投诉响应 -- 反跟卖策略 - -## Compliance Red Lines -- 无认证不上架：CE/FCC/FDA 是强制要求，违规导致下架+罚款 -- VAT 必须如实申报 -- 零容忍 IP 侵权：假货、跟卖、品牌元素未经授权 - -## Connections -- [[Legal Compliance Checker]] ← validates ← [[Compliance & Certification]] -- [[Marketing Cross-Border E-Commerce Specialist]] ← requires ← [[Compliance & Certification]] \ No newline at end of file diff --git a/wiki/concepts/Compliance-Enforcement.md b/wiki/concepts/Compliance-Enforcement.md deleted file mode 100644 index 600b1c45..00000000 --- a/wiki/concepts/Compliance-Enforcement.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: "Compliance Enforcement" -type: concept -tags: [security, compliance, automation] -sources: [How-Agentic-AI-can-help-for-Cloud-DevOps] -last_updated: 2026-04-16 ---- - -## Summary -Compliance Enforcement（合规执行）是通过自动化工具持续监控和确保系统符合 SOC 2、FedRAMP、PCI DSS 等安全合规要求的实践。 - -## Definition -自动化监控、检测和修复安全合规违规行为，确保系统始终符合监管要求。 - -## Key Frameworks -- **SOC 2**：服务组织控制评估 -- **FedRAMP**：联邦风险和授权管理计划 -- **PCI DSS**：支付卡行业数据安全标准 -- **HIPAA**：美国健康保险便携性和责任法案 -- **GDPR**：欧盟通用数据保护条例 - -## Key Mechanisms -- **持续监控**：实时检测合规违规 -- **自动修复**：违规发生时自动修复 -- **审计追踪**：记录所有合规相关活动 -- **报告生成**：自动生成合规报告 - -## Connections -- [[Agentic AI]] ← implements ← [[Compliance Enforcement]]：Agentic AI 实现自动化合规执行 -- [[DevSecOps]] ← extends ← [[Compliance Enforcement]]：DevSecOps 强调自动化合规 -- [[Cloud Security]] ← depends_on ← [[Compliance Enforcement]]：云安全依赖合规执行 diff --git a/wiki/concepts/Composer模型.md b/wiki/concepts/Composer模型.md deleted file mode 100644 index ea525ab5..00000000 --- a/wiki/concepts/Composer模型.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: "Composer模型" -type: concept -tags: [ai, cursor, model] -date: 2026-04-17 ---- - -## Definition -Cursor 自研 AI 模型，主打生成速度优势，官方声称比同类模型快 4 倍。 - -## Context -- Cursor 2.0 使用的 AI 模型 - -## Features -- 专为代码生成优化 -- 比类似模型快 4 倍 -- 支持多代理并行操作 - -## Related Entities -- [[Cursor]] \ No newline at end of file diff --git a/wiki/concepts/Compositor-Services.md b/wiki/concepts/Compositor-Services.md deleted file mode 100644 index 371f5989..00000000 --- a/wiki/concepts/Compositor-Services.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: "Compositor Services" -type: concept -tags: [vision-pro, streaming, compositor, stereo] -date: 2026-04-20 ---- - -## Definition -Compositor Services 是 Apple 的 Vision Pro 立体帧流式传输框架，允许从 Mac 向 Vision Pro 远程流式传输沉浸式内容。 - -## Core Attributes -- 立体帧流式传输 -- LayerRenderer 配置 -- RemoteImmersiveSpace -- 双眼渲染支持 -- 深度纹理支持 -- 实时帧提交 - -## Related Concepts -- [[Spatial Computing]]：核心技术 -- [[Vision Pro]]：目标设备 -- [[Metal]]：渲染框架 - -## Related Entities -- Apple：框架开发者 - -## Application -Vision Pro 远程渲染、macOS 伴侣应用、沉浸式代码可视化 \ No newline at end of file diff --git a/wiki/concepts/Consolidation-Policies.md b/wiki/concepts/Consolidation-Policies.md deleted file mode 100644 index 1d62c7c2..00000000 --- a/wiki/concepts/Consolidation-Policies.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "Consolidation Policies" -type: concept -tags: [Kubernetes, Karpenter, Cost-Optimization] -sources: [] -last_updated: 2026-04-19 ---- - -## Definition -Consolidation Policies 是 Karpenter 的成本优化策略，控制节点的整合行为以减少空闲资源。 - -## Configuration Options -- **Budget-based**：基于预算的整合限制 -- **Time-based**：基于时间的整合控制（如业务高峰时段禁止整合） -- **Percentage-based**：限制每次中断的实例百分比 - -## Purpose -- 在保证性能的前提下最小化成本 -- 避免在业务高峰时段进行节点整合 -- 控制变更节奏，减少对工作负载的影响 - -## Related Concepts -- [[Karpenter]]：使用 Consolidation Policies -- [[Node-Pools]]：配置整合策略的组件 -- [[Cost-Optimization]]：成本优化 - -## Aliases -- Consolidation Policies -- Consolidation -- Node Consolidation \ No newline at end of file diff --git a/wiki/concepts/Consumer-Behavior-Analysis.md b/wiki/concepts/Consumer-Behavior-Analysis.md deleted file mode 100644 index 8147666e..00000000 --- a/wiki/concepts/Consumer-Behavior-Analysis.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: "Consumer Behavior Analysis" -type: concept -tags: [consumer, behavior, user-research] -sources: [raw/Agent/agency-agents/product/product-trend-researcher.md] -last_updated: 2026-04-20 ---- - -## Definition -消费者行为分析是研究用户决策过程、使用模式和未满足需求的方法，用于指导产品策略。 - -## Core Areas -- **Purchase Journey Mapping**：从认知到倡导的完整旅程 -- **Decision Factors**：价格敏感度、功能偏好、品牌忠诚度 -- **Usage Patterns**：使用频率、场景、满意度 -- **Unmet Needs**：差距分析、痛点、机会识别 -- **Adoption Barriers**：技术壁垒、金融壁垒、文化壁垒 - -## Research Methods -- 人口统计研究（Demographic Studies） -- 心理图形分析（Psychographics） -- 购买模式分析（Buying Patterns） -- 行为聚类（Behavioral Clustering） diff --git a/wiki/concepts/Container-Image-Scanning.md b/wiki/concepts/Container-Image-Scanning.md deleted file mode 100644 index ee8a686f..00000000 --- a/wiki/concepts/Container-Image-Scanning.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: "Container Image Scanning" -type: concept -tags: [Container, Security, Vulnerability] -last_updated: 2026-04-19 ---- - -## 定义 -容器镜像扫描是在构建和部署阶段自动检测容器镜像中已知安全漏洞的过程。通过扫描工具识别镜像中的组件漏洞、配置问题和安全风险。 - -## 扫描内容 -- 操作系统软件包漏洞 -- 应用依赖库漏洞 -- 配置文件安全风险 -- 敏感信息泄露检测 -- 合规性检查 - -## 工具示例 -- Snyk -- Trivy -- Clair -- Anchore - -## 相关资源 -- 来源：[[CTP Topic 49 Container Lifecycle Hardening Standards]] -- 相关概念：[[Container-Lifecycle-Hardening]] \ No newline at end of file diff --git a/wiki/concepts/Container-Lifecycle-Hardening.md b/wiki/concepts/Container-Lifecycle-Hardening.md deleted file mode 100644 index c13a8757..00000000 --- a/wiki/concepts/Container-Lifecycle-Hardening.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: "Container Lifecycle Hardening" -type: concept -tags: [Container, Security, Hardening, Kubernetes] -last_updated: 2026-04-19 ---- - -## 定义 -容器生命周期加固是指在容器构建、部署和运行各个阶段实施安全最佳实践的系统化方法。Micro Focus 产品安全组制定的容器生命周期加固标准聚焦于构建阶段的安全实践。 - -## 核心组件 - -### 1. 构建阶段标准（11 项） -- 使用 Micro Focus 基础镜像 -- 采用 init 系统（如 teeny） -- 确保镜像不含敏感信息 -- 使用只读文件系统 -- 使用 emptyDir 卷处理临时文件 -- 镜像扫描检测漏洞 -- 单容器单应用 -- 禁用 Kubernetes API 访问 -- 使用私有服务账户 -- 避免主机网络模式 -- 避免主机端口 - -### 2. 关键概念 -- [[Read-Only-Root-Filesystem]]：只读根文件系统配置 -- [[Container-Image-Scanning]]：镜像漏洞扫描 -- [[Init-System]]：容器初始化进程 -- [[Kubernetes-Service-Account]]：K8s 服务账户 - -## 相关资源 -- 来源：[[CTP Topic 49 Container Lifecycle Hardening Standards]] -- 相关：[[CTP Topic 21 Supply Chain Security in Micro Focus]] \ No newline at end of file diff --git a/wiki/concepts/Content-Cascade.md b/wiki/concepts/Content-Cascade.md deleted file mode 100644 index 2f82f6ae..00000000 --- a/wiki/concepts/Content-Cascade.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: "Content Cascade" -type: concept -tags: [marketing, content, strategy] ---- - -## Definition -内容瀑布流策略，主内容在 LinkedIn 首发后适配到 Twitter 等其他平台，实现一次创作多次分发。 - -## Cascade Mechanism -- Primary Content: LinkedIn 首发生成完整深度内容 -- Platform Adaptation: 转化为各平台原生格式 -- Real-Time Amplification: 跨平台推广时效性内容 -- Engagement Loops: 推动跨平台关注和社区重叠 - -## Implementation -- LinkedIn: 长篇文章、公司页面更新、新闻通讯 -- Twitter: 适配洞察、实时评论、标签策略 -- Attribution: 追踪跨平台用户旅程 - -## Related Concepts -- [[Cross-Platform Strategy]] -- [[Thought Leadership]] - -## Source -- [[Social Media Strategist]] \ No newline at end of file diff --git a/wiki/concepts/Context-Passing.md b/wiki/concepts/Context-Passing.md deleted file mode 100644 index 3d39c48f..00000000 --- a/wiki/concepts/Context-Passing.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: "Context Passing" -type: concept -tags: [multi-agent, workflow, communication] -last_updated: 2026-04-21 ---- - -## Definition -上下文传递（Context Passing）是一种多智能体通信模式，在智能体之间传递完整的上下文信息，而非摘要或压缩版本。 - -## Core Principle -**"Copy-paste agent outputs between steps — don't summarize, use the full output"** - -## Problem It Solves -- 摘要会丢失关键细节 -- 压缩可能遗漏重要上下文 -- 智能体不具备共享记忆 - -## Best Practices -1. **完整复制**：将上一智能体的输出完整粘贴到下一智能体的输入 -2. **不要摘要**：即使很长也要完整传递 -3. **不要解释**：让接收智能体自己解析和处理完整信息 -4. **包含所有内容**：原始输出、元数据、证据、决策理由等 - -## Example -在 Multi-Agent Workflow: Startup MVP 中： -``` -Sprint Prioritizer 输出 → [完整粘贴] → Backend Architect 输入 -UX Researcher 输出 → [完整粘贴] → Backend Architect 输入 -Backend Architect 输出 → [完整粘贴] → Frontend Developer 输入 -``` - -## Trade-offs -- **优点**：最大化信息保留，便于接收智能体做出完整判断 -- **缺点**：消耗更多上下文窗口，可能需要更长的处理时间 - -## Related Concepts -- [[Sequential Handoffs]]：顺序交接模式 -- [[Parallel Work]]：并行工作模式 -- [[Quality Gates]]：质量门控 -- [[Multi-Agent Team]]：多智能体团队 diff --git a/wiki/concepts/Contextual-Semiotics.md b/wiki/concepts/Contextual-Semiotics.md deleted file mode 100644 index 8dd46658..00000000 --- a/wiki/concepts/Contextual-Semiotics.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: "Contextual Semiotics" -type: concept -tags: [design, localization, communication] -date: 2026-04-20 ---- - -## Definition -Contextual semiotics is the practice of interpreting and choosing colors, icons, metaphors, and imagery according to the culture and domain in which they will be seen. - -## Key Considerations -- Color symbolism varies by region and industry -- Icons can imply different actions or values across cultures -- Metaphors may not survive translation literally -- Visual references should be checked against local meaning - -## Connections -- [[Cultural Intelligence Strategist]] — applies contextual semiotics in audits -- [[Cultural Intelligence]] — broader framework for context-aware design -- [[Inclusive Visuals Specialist]] — visual generation depends on correct semiotics diff --git a/wiki/concepts/Continuous-Compliance.md b/wiki/concepts/Continuous-Compliance.md deleted file mode 100644 index 8b7656d6..00000000 --- a/wiki/concepts/Continuous-Compliance.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "Continuous Compliance" -type: concept -tags: [compliance, automation, security] ---- - -## 定义 -在正式审计周期之间维持合规状态的持续过程，而非一次性认证事件。 - -## 核心理念 -合规不是一次性项目，而是持续运营状态。 - -## 关键活动 -- **自动化证据收集管道**：设置持续证据收集流程，减少审计准备时间 -- **季度控制测试**：在年度审计之间定期测试控制有效性 -- **监管变化追踪**：跟踪影响合规计划的监管变化 -- **月度合规态势报告**：向领导层报告合规状态 - -## 价值主张 -- 减少年度审计准备压力 -- 提前发现控制失效 -- 持续改进而非临时应对 - -## 实施要点 -- 从第一天就自动化证据收集 -- 使用共同控制框架满足多种认证 -- 技术控制优先于管理控制 - -## 相关实体 -- [[Compliance Auditor]] diff --git a/wiki/concepts/Controls-Implementation.md b/wiki/concepts/Controls-Implementation.md deleted file mode 100644 index 1b70d1f2..00000000 --- a/wiki/concepts/Controls-Implementation.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: "Controls Implementation" -type: concept -tags: [compliance, security, controls] ---- - -## 定义 -设计并实施满足合规要求同时适应现有工程工作流的控制措施。 - -## 核心目标 -- 控制必须满足合规要求 -- 控制必须融入现有工程工作流 -- 控制必须可测试和可验证 - -## 实施原则 -- **自动化优先**：自动化证据收集从第一天开始——手动流程无法扩展 -- **技术控制优于管理控制**：代码比培训更可靠 -- **共同控制框架**：使用共同控制框架满足多种认证 - -## 关键活动 -- 设计满足合规要求的控制 -- 构建自动化证据收集流程 -- 创建工程师会遵循的政策（简短、具体、集成到现有工具） -- 建立控制失败监控和告警 - -## 相关框架 -- [[SOC-2]] -- [[ISO-27001]] -- [[HIPAA]] -- [[PCI-DSS]] - -## 相关实体 -- [[Compliance Auditor]] diff --git a/wiki/concepts/Conversion-Tracking.md b/wiki/concepts/Conversion-Tracking.md deleted file mode 100644 index 1851f0d0..00000000 --- a/wiki/concepts/Conversion-Tracking.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "Conversion Tracking" -type: concept -tags: [Tracking, Measurement, Advertising, Analytics] ---- - -## Definition -转化追踪是衡量广告投入产出比的核心机制，通过在用户完成目标行为时触发追踪代码，记录广告点击到最终转化之间的因果关系，为出价优化提供数据支撑。 - -## Core Components -- **Conversion Action**：广告平台中定义的具体转化目标（如购买、注册、表单提交） -- **Conversion Value**：转化产生的价值（金额或自定义权重） -- **Conversion Window**：归因时间窗口（点击后/展示后多少天内归因） -- **Attribution Model**：归因模型（最终点击、首次点击、数据驱动等） - -## Platforms -- **Google Ads**：转化操作、增强型转化、离线转化导入 -- **Meta**：Pixel、Conversions API (CAPI) -- **LinkedIn**：Insight Tag -- **TikTok**：Pixel - -## Key Metrics -- **Conversion Rate**：转化率，转化数/点击数 -- **Cost per Conversion**：每次转化成本 -- **Conversion Value ROAS**：转化价值回报率 - -## Best Practices -- 追踪所有关键转化事件（购买、注册、Lead） -- 设置微转化喂给算法学习 -- 交叉验证平台数据与 GA4 数据 -- 实施增强型转化提升匹配率 - -## Related Concepts -- [[Server-Side Tagging]]：服务端标记 -- [[GA4]]：Google Analytics 4 -- [[Attribution]]：归因模型 - -## Related Entities -- [[Paid Media Tracking & Measurement Specialist]]：转化追踪实施专家 -- [[Paid Media PPC Campaign Strategist]]：优化转化出价的智能体 \ No newline at end of file diff --git a/wiki/concepts/Cost-Optimization.md b/wiki/concepts/Cost-Optimization.md deleted file mode 100644 index 13176849..00000000 --- a/wiki/concepts/Cost-Optimization.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "Cost Optimization" -type: concept -tags: [cloud, cost-management, FinOps] -sources: [How-Agentic-AI-can-help-for-Cloud-DevOps] -last_updated: 2026-04-16 ---- - -## Summary -Cost Optimization（成本优化）是通过策略和技术最大化云资源价值、减少不必要开销的实践。 - -## Definition -在保持性能和可靠性的前提下，通过资源 rightsizing、自动扩缩、实例类型选择等方式降低云支出。 - -## Key Techniques -- **AI-based Rightsizing**：AI 分析使用趋势，推荐合适大小的实例 -- **Spot Instance Optimization**：智能切换 Spot/Preemptible 实例 -- **Reserved Instance Planning**：优化预留实例购买策略 -- **Multi-Cloud Cost Governance**：跨云成本分析与优化 -- **存储优化**：识别和清理未使用存储 - -## Connections -- [[Agentic AI]] ← implements ← [[Cost Optimization]]：Agentic AI 实现智能成本优化 -- [[Pay-as-you-go]] ← optimizes ← [[Cost Optimization]]：成本优化提升按需付费效益 -- [[CAPEX to OPEX]] ← enables ← [[Cost Optimization]]：成本优化支持财务模式转型 diff --git a/wiki/concepts/Coze-Workflow.md b/wiki/concepts/Coze-Workflow.md deleted file mode 100644 index 9e2ab99d..00000000 --- a/wiki/concepts/Coze-Workflow.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "Coze Workflow" -type: concept -tags: [ai, 智能体, 工作流] ---- - -## Description -Coze 平台的工作流模式（Workflow），用于编排复杂的 AI 业务流程。与 Bot（对话型智能体）模式不同，Workflow 支持更复杂的企业级业务逻辑编排，可通过可视化界面串联多个节点，实现自动化业务流程。 - -## Key Features -- **可视化编排**：通过拖拽节点构建业务流程 -- **多节点类型**：支持大模型、插件、代码、条件分支等多种节点 -- **变量传递**：节点间可传递变量，实现数据流转 -- **错误处理**：支持异常捕获和重试机制 -- **版本管理**：支持工作流版本回滚 - -## Use Cases -- 复杂业务审批流程 -- 数据处理与分析流水线 -- 多系统集成自动化 -- 企业级 AI 应用开发 - -## Related -- [[Coze（扣子）]] — 提供 Workflow 的平台 -- [[Bot]] — Coze 的另一种开发模式 \ No newline at end of file diff --git a/wiki/concepts/Credential-Isolation.md b/wiki/concepts/Credential-Isolation.md deleted file mode 100644 index 0519ade5..00000000 --- a/wiki/concepts/Credential-Isolation.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: "Credential Isolation" -type: concept -tags: [security, api, isolation] -date: 2026-04-17 ---- - -## Definition -凭证隔离模式，将敏感 API 密钥存储在独立系统中，Agent 仅知道调用接口而无法访问凭证本身。 - -## Problem -- AI Agent 环境存储 API 密钥存在泄露风险 -- 一次错误的代码提交可能导致密钥暴露 -- 多个集成意味着多个凭证管理的复杂度 - -## Solution -1. 使用 n8n 的凭证存储功能保存 API 密钥 -2. Agent 仅知道 webhook URL -3. 凭证与 Agent 环境物理隔离 -4. 可视化审计每次 API 调用 - -## Benefits -- 零凭证暴露风险 -- 审计追踪每个请求 -- 可锁定工作流防止修改 -- 确定性任务不消耗 LLM token \ No newline at end of file diff --git a/wiki/concepts/Cron-Jobs.md b/wiki/concepts/Cron-Jobs.md deleted file mode 100644 index 6e7efabf..00000000 --- a/wiki/concepts/Cron-Jobs.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: "Cron Jobs" -type: concept -tags: [automation, scheduling, linux] -sources: [self-healing-home-server-infrastructure-management] -last_updated: 2026-04-17 ---- - -## Summary -Cron Jobs（定时任务）是 Linux 系统中基于时间的任务调度机制，允许用户在特定时间间隔或时间点自动执行命令或脚本。在 AI Agent 场景中，定时作业是提供持续价值的关键机制。 - -## Definition -基于 crontab 的时间调度系统，通过配置文件定义任务执行的时间规则。 - -## Key Characteristics -- 基于时间调度（每分钟、每小时、每天等） -- 后台运行，无需人工干预 -- 可用于自动化监控、备份、清理等任务 - -## Use Cases in AI Agent -- 健康检查：定时检测服务状态 -- 数据处理：定时处理新数据 -- 日志分析：定时分析日志发现异常 -- 邮件分类：定时扫描邮箱 -- 每日简报：定时生成并发送报告 - -## Connections -- [[Self-Healing Systems]] ← uses ← [[Cron Jobs]]：自愈系统使用 cron 作业进行定时检查 -- [[Agentic AI]] ← executes ← [[Cron Jobs]]：AI Agent 执行定时任务实现自动化 \ No newline at end of file diff --git a/wiki/concepts/Cross-Account-Event-Forwarding.md b/wiki/concepts/Cross-Account-Event-Forwarding.md deleted file mode 100644 index a01bfe5c..00000000 --- a/wiki/concepts/Cross-Account-Event-Forwarding.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: Cross-Account Event Forwarding -type: concept -tags: [aws, eventbridge, multi-account, event-driven] -date: 2026-04-19 ---- - -## 定义 - -跨账号事件转发（Cross-Account Event Forwarding）是指通过 Amazon EventBridge 将一个 AWS 账号中的事件路由到另一个 AWS 账号的机制。该机制允许组织在多账号架构中实现集中式事件管理。 - -## 核心机制 - -- **自定义事件总线**：在管理账号创建自定义事件总线，配置跨账号权限策略 -- **PutEvents API**：源账号通过 PutEvents API 将事件发送到目标账号的事件总线 -- **事件规则**：目标账号通过事件规则过滤和处理接收的事件 - -## 组件 - -- **Event Bus**：事件总线，事件的入口点 -- **Event Rule**：事件规则，用于过滤和路由事件 -- **Permission Policy**：事件总线的跨账号权限策略 - -## 应用场景 - -- **集中日志收集**：将多个账号的 CloudFormation 事件转发到管理账号 -- **集中告警**：跨账号统一告警通知 -- **安全事件集中**：安全相关事件集中到 SOC 账号 - -## 与集中式日志的关系 - -跨账号事件转发是实现集中式日志的关键技术基础。通过 EventBridge 将分散在各账号的事件汇聚到中央存储位置（如 CloudWatch Logs 或 OpenSearch），实现统一监控和查询。 - -## Connections -- [[EventBridge]] ← implements ← [[Cross-Account Event Forwarding]] -- [[Centralized Logging]] ← depends_on ← [[Cross-Account Event Forwarding]] -- [[Multi-Account Strategy]] ← enables ← [[Cross-Account Event Forwarding]] \ No newline at end of file diff --git a/wiki/concepts/Cross-Border-Logistics.md b/wiki/concepts/Cross-Border-Logistics.md deleted file mode 100644 index e557bd4c..00000000 --- a/wiki/concepts/Cross-Border-Logistics.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: Cross-Border Logistics -type: concept -tags: [logistics, supply-chain, cross-border, ecommerce] -aliases: [跨境物流, International Logistics, Overseas Warehousing] ---- - -## Definition -跨境物流全链路，涵盖头程运输、海外仓储、尾程配送三大环节。 - -## Three Segments - -### First-Mile Logistics（头程） -- FCL（Full Container Load）：整柜海运 -- LCL（Less-than-Container Load）：拼箱海运 -- Air Freight / Air Express：空运/空快递 -- China-Europe Railway Express：中欧班列 -- 报关清关程序 - -### International Warehousing（海外仓储） -- FBA（Fulfillment by Amazon）：亚马逊自营仓 -- Third-party Overseas Warehouse：第三方海外仓 -- Dropshipping：代发模式 -- Return Relabeling：退件重新标签 - -### Last-Mile Delivery（尾程） -- 各国最后一公里配送特点 -- 配送成功率提升 -- 签收异常处理 - -## Logistics Cost Modeling -端到端成本计算：头程 + 仓储费 + 尾程配送，纳入产品定价模型。 - -## Connections -- [[Supply Chain Strategist]] ← supports ← [[Cross-Border Logistics]] -- [[Marketing Cross-Border E-Commerce Specialist]] ← plans ← [[Cross-Border Logistics]] \ No newline at end of file diff --git a/wiki/concepts/Cross-Functional-Leadership.md b/wiki/concepts/Cross-Functional-Leadership.md deleted file mode 100644 index 178faad7..00000000 --- a/wiki/concepts/Cross-Functional-Leadership.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: "Cross-Functional Leadership" -type: concept -tags: [leadership, project-management] -sources: [project-management-studio-operations, project-management-studio-producer] -last_updated: 2026-04-20 ---- - -## Definition -Cross-Functional Leadership is the ability to coordinate teams, stakeholders, and disciplines across organizational boundaries to achieve a shared operational or strategic outcome. - -## Core Principles -- Align goals across functions -- Communicate clearly with stakeholders -- Resolve conflicts early -- Keep execution connected to business outcomes - -## Related Entities -- [[Studio Operations]] -- [[Studio Producer]] -- [[The Agency]] diff --git a/wiki/concepts/Cross-Platform-Strategy.md b/wiki/concepts/Cross-Platform-Strategy.md deleted file mode 100644 index c7cdc81b..00000000 --- a/wiki/concepts/Cross-Platform-Strategy.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "Cross-Platform Strategy" -type: concept -tags: [marketing, social-media, strategy] ---- - -## Definition -跨平台统一消息传递和内容适配策略，通过在 LinkedIn、Twitter 和专业社交网络之间协调一致的品牌声音，实现最大化的受众覆盖和参与度。 - -## Core Components -- **Unified Messaging**: 核心主题适配每个平台优势 -- **Content Cascade**: 主内容在 LinkedIn 首发后适配到其他平台 -- **Engagement Loops**: 推动跨平台关注和社区重叠 -- **Attribution**: 追踪跨平台用户旅程以测量转化路径 - -## Platform-Specific Tactics -- LinkedIn: 公司页面、个人品牌、文章、新闻通讯 -- Twitter: 实时放大、标签策略、协同声音 -- Cross-Platform: 统一主题、平台适配、受众重叠 - -## Related Concepts -- [[Thought Leadership]] -- [[B2B Social Selling]] -- [[Employee Advocacy]] - -## Source -- [[Social Media Strategist]] \ No newline at end of file diff --git a/wiki/concepts/Cross-account-Modules.md b/wiki/concepts/Cross-account-Modules.md deleted file mode 100644 index d5cf9c7c..00000000 --- a/wiki/concepts/Cross-account-Modules.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "Cross-account Modules" -type: concept -tags: [terraform, multi-account, security] -last_updated: 2026-04-20 ---- - -## Definition -- Cross-account Modules 指在一个 Terraform 模块中通过配置多个 Provider，实现在多个 AWS 账号中同时创建或管理资源的功能 - -## Why Needed -- 复杂云架构经常需要在一个模块内跨多个账号创建资源（例如在 InfoBlocks 账号配置 DNS，同时在 Workload 账号部署应用） - -## Security Concern -- 直接赋予账号间互访权限存在巨大的安全风险，如某一账号被攻破可能波及全局（Blast Radius 问题） - -## Solution -- 基于 Shared Account 的中心化部署方案，通过 Assume Role 方式访问目标账号，避免直接授予互访权限 - -## Implementation Components -- cross-account.json：标记文件，告知 Jenkins 该模块需要调用跨账号部署逻辑 -- ECS Deploy Runner：运行在 ECS 上的 Docker 容器，负责执行 Terraform plan 和 apply -- TF state bucket accessor：专门定义的 IAM 角色，仅允许部署工具访问状态文件 -- Cross-account ECS deploy runner role：部署在目标账号中的角色，允许 Shared Account 的执行器切换角色获取权限 - -## Connections -- [[Terraform]] — 基础工具 -- [[Terragrunt]] — 配置管理 -- [[Shared Account]] — 信任源 -- [[ECS Deploy Runner]] — 执行单元 \ No newline at end of file diff --git a/wiki/concepts/Cultural-Humility.md b/wiki/concepts/Cultural-Humility.md deleted file mode 100644 index 34bfc593..00000000 --- a/wiki/concepts/Cultural-Humility.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: "Cultural Humility" -type: concept -tags: [design, research, ethics] -date: 2026-04-20 ---- - -## Definition -Cultural humility is the practice of assuming your current knowledge is incomplete and researching the relevant audience before making design or content decisions. - -## Key Practices -- Ask who the design might exclude -- Research the target culture before generating output -- Prefer evidence over assumptions -- Revise based on feedback from the affected audience - -## Connections -- [[Cultural Intelligence Strategist]] — operationalizes cultural humility in audits -- [[Cultural Intelligence]] — humility is a prerequisite for it diff --git a/wiki/concepts/Cultural-Intelligence.md b/wiki/concepts/Cultural-Intelligence.md deleted file mode 100644 index 7458c494..00000000 --- a/wiki/concepts/Cultural-Intelligence.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: "Cultural Intelligence" -type: concept -tags: [design, localization, accessibility, ai] -date: 2026-04-20 ---- - -## Definition -Cultural intelligence is the capability to design products, prompts, and workflows that work respectfully and effectively across cultures by accounting for language, naming, symbols, calendars, norms, and representation. - -## Key Aspects -- Global-first assumptions instead of Western-only defaults -- Cultural context research before output generation -- Structural inclusion rather than tokenistic representation -- Accessibility and localization as part of the core design - -## Connections -- [[Cultural Intelligence Strategist]] — agent persona that operationalizes this concept -- [[Prompt Engineering]] — prompt design must respect cultural context -- [[Design System]] — global UI patterns need culturally flexible components -- [[Inclusive Visuals Specialist]] — visual generation requires cultural accuracy diff --git a/wiki/concepts/Customer-Lifetime-Value.md b/wiki/concepts/Customer-Lifetime-Value.md deleted file mode 100644 index 34e1d488..00000000 --- a/wiki/concepts/Customer-Lifetime-Value.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: "Customer Lifetime Value" -type: concept -tags: [] -last_updated: 2026-04-21 ---- - -## Definition -客户生命周期价值，衡量客户在整个关系周期内为企业贡献的总收入。 - -## Calculation Method -CLV = Average Order Value × Purchase Frequency × Customer Lifespan - -## Application -- 客户分层与优先级排序 -- 客户获取成本（CAC）决策依据 -- 个性化营销策略制定 -- 客户流失预警基准 - -## Related Concepts -- [[RFM Analysis]] -- [[Predictive Modeling]] - -## Source -- [[support-analytics-reporter]] - diff --git a/wiki/concepts/Customer-Success.md b/wiki/concepts/Customer-Success.md deleted file mode 100644 index 8d06d99d..00000000 --- a/wiki/concepts/Customer-Success.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -id: customer-success -title: "Customer Success" -type: concept -tags: [customer-service, retention, lifecycle] -sources: [support-support-responder.md] -last_updated: 2026-04-21 ---- - -## Definition -客户成功（Customer Success），从被动式客户支持向主动式客户成功干预转变的管理方法论，目标是最大化客户生命周期价值并预防客户流失。 - -## Core Mission -- Onboarding Optimization：新客户快速上手和功能采用 -- Feature Adoption Guidance：引导客户发现和使用核心功能 -- Proactive Outreach：基于数据的主动干预（高风险客户识别） -- Feedback Collection：产品改进和客户洞察生成 - -## Success Metrics -| Metric | Target | -|--------|--------| -| CSAT Score | ≥ 4.5/5 | -| First Contact Resolution | ≥ 80% | -| Customer Retention | ≥ 95% | -| NPS Score | ≥ 50 | - -## Proactive Outreach Triggers -- 30 天内提交 ≥ 3 次工单的高频用户 -- 7 天内 CSAT ≤ 3 的低满意度客户 -- 超过 48 小时未解决的工单 - -## Connections -- [[Support Responder]] — 实现客户成功的核心执行者 -- [[Support Analytics]] — 提供数据驱动的干预依据 -- [[Multi-Channel Support Framework]] — 客户触达的渠道 \ No newline at end of file diff --git a/wiki/concepts/Cyber-Suite.md b/wiki/concepts/Cyber-Suite.md deleted file mode 100644 index 6675ddae..00000000 --- a/wiki/concepts/Cyber-Suite.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: Cyber Suite Standards -type: concept -tags: - - Security - - CTP - - Standards ---- - -## Description - -Cyber Suite（网络安全套件标准）是由 PSAC（Product Security Approval Committee）团队发布的网络安全标准文档，定义了 CTP 项目中产品必须遵循的加密算法和安全配置。 - -## Updated Standards - -更新后的 Cyber Suite 标准包括： - -### Considered Standard（标准套件） -- 符合 FIPS 标准 -- Java、Golang、Node.js、OpenCel for CNC++ 兼容 - -### Optional（可选套件） -- 为向后兼容提供 -- 但包含 CBC（Cipher Block Chaining）模式，被认为安全性较弱 - -### Cipher Selection - -产品可从不同类别选择加密套件： -- 密钥交换（Key Exchange） -- 认证（Authentication） -- 加密（Encryption） -- 哈希（Hash） - -### Review Requirement - -使用非标准和可选套件之外加密算法的产品需经过 PSAC 团队审查。 - -## References - -- [[CTP Topic 36 SendGrid as an email service]] \ No newline at end of file diff --git a/wiki/concepts/DKIM.md b/wiki/concepts/DKIM.md deleted file mode 100644 index 1bc7bbfc..00000000 --- a/wiki/concepts/DKIM.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: "DKIM" -type: concept -tags: - - email - - security - - authentication ---- - -## Aliases -- DKIM -- DomainKeys Identified Mail - -## Description -一种电子邮件验证标准，通过在邮件头部添加数字签名来验证发件人域名并确保邮件内容未被篡改。DKIM 是 SPF 和 DMARC 三大邮件验证标准之一。 - -## How It Works -1. 域名管理员在 DNS 中发布 DKIM 选择器记录（TXT 记录） -2. 邮件服务器使用私钥对邮件内容进行加密签名 -3. 收件方服务器通过 DNS 获取公钥验证签名 -4. 签名验证通过表示邮件未被篡改且确实来自声称的域名 - -## Related Concepts -- [[SPF]]：发件人验证标准 -- [[DMARC]]：基于 SPF 和 DKIM 的邮件验证策略 - -## Sources -- [[ctp-topic-12-using-ses-smtp-service-terraform-module]] \ No newline at end of file diff --git a/wiki/concepts/DNS-Anycast.md b/wiki/concepts/DNS-Anycast.md deleted file mode 100644 index dae925ba..00000000 --- a/wiki/concepts/DNS-Anycast.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: "DNS Anycast" -type: concept -tags: - - DNS - - Networking - - High Availability ---- - -## Definition -DNS Anycast 是一种网络寻址和路由方法，使多个 DNS 服务器共享同一个 IP 地址，将请求路由至地理位置最近的节点，提供极高的冗余性和低延迟。 - -## Characteristics -- **低延迟**：请求自动路由到最近的节点 -- **高可用性**：单个节点故障不影响服务，流量自动切换到其他节点 -- **全球分布**：支持全球范围内部署 - -## Comparison: Infoblox vs AWS - -| 特性 | Infoblox (On-prem) | AWS EC2 | -|------|-------------------|---------| -| Anycast 支持 | ✅ 原生支持 | ❌ 不支持 | -| 故障转移 | 自动 | 手动维护 IP 列表 | -| 延迟优化 | 自动就近解析 | 需手动配置 | - -## Security Features -- 防 DNS 隧道攻击 -- 防数据外泄 -- 防缓存污染 - -## Use Cases -- 企业内网 DNS 高可用 -- DNS 负载均衡 -- 全球化服务的就近解析 - -## Connections -- [[Infoblox]] ← uses ← [[DNS-Anycast]] -- [[DNS-Anycast]] ← optimizes ← [[Hybrid-DNS-Resolution]] \ No newline at end of file diff --git a/wiki/concepts/DORA-指标.md b/wiki/concepts/DORA-指标.md deleted file mode 100644 index ab6b465f..00000000 --- a/wiki/concepts/DORA-指标.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "DORA 指标" -type: concept -tags: [devops, metrics, performance-measurement] -sources: [cloud-devop-maturity-guideline] -last_updated: 2026-04-16 ---- - -## Definition -DORA（DevOps Research & Assessment）指标是用于衡量组织 DevOps 性能和交付能力的关键度量标准。 - -## Four Key Metrics -1. **部署频率（Deployment Frequency）**：代码部署到生产的频率 -2. **变更前置时间（Lead Time for Changes）**：从代码提交到生产部署的时间 -3. **变更失败率（Change Failure Rate）**：部署导致生产环境失败的比例 -4. **平均恢复时间（MTTR）**：Mean Time to Recovery，服务从故障中恢复的平均时间 - -## Significance -- DORA 指标是评估 DevOps 成熟度的核心量化工具 -- 高绩效组织通常：部署频率高、前置时间短、变更失败率低、MTTR 短 - -## Connections -- [[DevOps 成熟度模型]] ← 评估框架 ← [[DORA 指标]] -- [[CI/CD 流水线]] ← 影响 ← [[DORA 指标]] diff --git a/wiki/concepts/DRY-原则.md b/wiki/concepts/DRY-原则.md deleted file mode 100644 index 224a6975..00000000 --- a/wiki/concepts/DRY-原则.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: "DRY 原则" -type: concept -tags: [] ---- - -## Definition -DRY（Don't Repeat Yourself）原则，意为"不要重复自己"。它是软件工程的核心原则之一，旨在减少代码中的重复。 - -## Key Points -- 避免重复代码，提炼公共逻辑 -- 单一信息源（Single Source of Truth） -- 模块化、函数化，提高复用价值 -- 便于维护和修改 - -## Source -- [[kai-fa-jing-yan-yu-xiang-mu-gui-fan-zheng-li-wen-dang]] - -## Related Concepts -- [[单一职责]] -- [[模块化]] -- [[代码可读性]] diff --git a/wiki/concepts/Dashboard-as-Code.md b/wiki/concepts/Dashboard-as-Code.md deleted file mode 100644 index 10aa3387..00000000 --- a/wiki/concepts/Dashboard-as-Code.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: "Dashboard-as-Code" -type: concept -tags: [Grafana, IaC, monitoring, automation] -sources: [ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana] -last_updated: 2026-04-19 ---- - -## Summary -通过代码管理 Grafana 仪表板的实践，使用 Terraform 模块实现自动化 provisioning。 - -## Definition -用代码（通常是 Terraform HCL）定义和管理 Grafana 组织、用户、文件夹、IAM 角色和仪表板的实践。 - -## Key Attributes -- **类型**：基础设施即代码（IaC） -- **工具**：Terraform -- **用途**：自动化监控资源部署 - -## Connections -- [[Grafana]] ← 管理工具 ← [[Dashboard-as-Code]] -- [[Terraform]] ← 使用模块 ← [[Dashboard-as-Code]] \ No newline at end of file diff --git a/wiki/concepts/Data-Driven-Decision-Making.md b/wiki/concepts/Data-Driven-Decision-Making.md deleted file mode 100644 index f57c0daf..00000000 --- a/wiki/concepts/Data-Driven-Decision-Making.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "Data-Driven Decision Making" -type: concept -tags: [] -last_updated: 2026-04-21 ---- - -## Definition -基于数据而非直觉或经验进行业务决策的方法论，强调用证据和量化分析指导战略选择。 - -## Core Principles -- 数据质量优先：验证数据准确性再分析 -- 统计显著性：结论需经假设检验确认 -- 可复现性：分析流程需版本控制和文档化 -- 行动导向：连接分析结果与业务行动 -- 持续迭代：基于反馈循环优化决策 - -## Implementation -1. 建立数据治理标准 -2. 定义关键业务指标（KPI） -3. 构建可复现的分析工作流 -4. 建立反馈机制评估决策效果 - -## Related Concepts -- [[Statistical Significance Testing]] -- [[KPI Tracking]] - -## Source -- [[support-analytics-reporter]] - diff --git a/wiki/concepts/Data-Governance.md b/wiki/concepts/Data-Governance.md deleted file mode 100644 index 148d6647..00000000 --- a/wiki/concepts/Data-Governance.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: Data Governance -type: concept -tags: [Cloud, Data-Management, Compliance] -sources: [The-Myths-and-Misconceptions-About-Cloud-Computing-LinkedIn.md] -last_updated: 2025-03-02 ---- - -## Definition -数据治理是指在云环境中管理数据的安全性、完整性、可用性和合规性的框架和实践。 - -## Core Components -- 权限管理（Access Control）：基于角色的数据访问控制 -- 数据加密（Encryption）：静态和动态数据加密 -- 访问日志监控（Access Logs）：追踪数据访问行为 -- 合规管理（Compliance Management）：满足法规要求 -- 数据存储位置控制（Data Residency）：控制数据地理存储位置 - -## Key Claims -- 云服务提供强大的数据治理工具，允许组织管理权限、加密数据和监控访问日志 -- 许多云服务提供混合云和多云选项，使企业能够维持对数据存储位置和方式的控制 - -## Connections -- [[Cloud-Security]] ← depends_on ← [[Data-Governance]]：数据治理是云安全的核心组成部分 -- [[GDPR]] ← requires ← [[Data-Governance]]：GDPR 要求数据治理合规性 -- [[Hybrid-Cloud]] ← enables ← [[Data-Governance]]：混合云支持数据主权要求 diff --git a/wiki/concepts/Data-Sovereignty.md b/wiki/concepts/Data-Sovereignty.md deleted file mode 100644 index 5af9ab21..00000000 --- a/wiki/concepts/Data-Sovereignty.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "Data Sovereignty" -type: concept -tags: [Cloud, Compliance, Regulation] -sources: [How-Can-a-Multi-Cloud-Strategy-Transform-Your-Business-ROI] -last_updated: 2025-03-01 ---- - -## Summary -Data Sovereignty（数据主权）是指数据受其存储所在国家或地区的法律法规约束的原则，强调政府对其境内数据的管辖权。 - -## Definition -数据主权指数据应当受到其物理存储地点所属国家或地区法律法规约束的原则。不同地区对数据存储、访问、传输有不同规定，企业必须遵守当地合规要求。 - -## Key Examples -- **GDPR（欧盟）**：要求数据在欧盟境内处理 -- **HIPAA（美国）**：医疗数据存储合规要求 -- **数据本地化法律**：某些国家要求数据必须存储在境内 - -## How Multi-Cloud Supports It -多云策略允许企业选择在不同地区选择符合当地法规的云服务商，将数据存储在合规的数据中心，从而满足数据主权要求。 - -## Connections -- [[Data Sovereignty]] ← addressed_by ← [[Multi-Cloud]] -- [[Data Sovereignty]] → relates_to → [[Cloud Compliance]] diff --git a/wiki/concepts/Deal-Health-Scoring.md b/wiki/concepts/Deal-Health-Scoring.md deleted file mode 100644 index 551c3488..00000000 --- a/wiki/concepts/Deal-Health-Scoring.md +++ /dev/null @@ -1,60 +0,0 @@ ---- -title: "Deal Health Scoring" -type: concept -tags: [sales, revenue-operations, metrics] -description: 交易健康评分，综合多信号类别评估交易质量 ---- - -Deal Health Scoring（交易健康评分）综合多个信号类别评估交易质量。 - -## 评估维度 - -### 1. 资格深度（Qualification Depth） - -使用 MEDDPICC 框架评估交易资格： - -| 维度 | 问题 | 评分 | -|------|------|------| -| Metrics | 买方是否量化了解决问题的价值？ | 0-2 | -| Economic Buyer | 签支票的人是否已确定并参与？ | 0-2 | -| Decision Criteria | 是否知道评估标准及其权重？ | 0-2 | -| Decision Process | 时间表、审批链和采购流程是否已绘制？ | 0-2 | -| Paper Process | 法律、安全和采购要求是否已确定？ | 0-2 | -| Implicated Pain | 痛苦是否与组织被考核的业务成果相关？ | 0-2 | -| Champion | 内部支持者是否有权力和动机推动交易？ | 0-2 | -| Competition | 是否知道还有谁在评估，位置如何？ | 0-2 | - -**规则**：少于 5/8 MEDDPICC 字段填充的交易是资格不足。晚期阶段的资格不足交易是预测失误的主要来源。 - -### 2. 互动强度（Engagement Intensity） - -交易中的联系人是否活跃参与： - -| 信号 | 说明 | -|------|------| -| 会议频率和最近一次 | 晚期阶段交易 14+ 天无活动是红旗 | -| 利益相关者广度 | 5 万美元以上的单线交易是高风险 | -| 内容互动 | 提案浏览、文档打开、跟进响应时间 | -| 互动模式 | 买方发起的活动是最强正面信号 | - -### 3. 进展速度（Progression Velocity） - -交易相对于基准在阶段间移动的速度。停滞的交易是垂死的交易。在同一阶段停留超过中位阶段时长 1.5 倍的交易需要明确干预或从管道移除。 - -## 综合评分 - -**交易健康综合评分 = 资格深度 (0-16) + 互动强度 (0-10) + 进展速度 (0-10) = 0-36** - -## 决策阈值 - -| 评分范围 | 决策 | -|----------|------| -| ≥28 | 推进 | -| 18-27 | 干预 | -| 10-17 | 培养 | -| <10 | 不合格 | - -## Related -- [[MEDDPICC]] -- [[Pipeline Velocity]] -- [[Pipeline Coverage]] \ No newline at end of file diff --git a/wiki/concepts/Deal-Scoring.md b/wiki/concepts/Deal-Scoring.md deleted file mode 100644 index 963f23a7..00000000 --- a/wiki/concepts/Deal-Scoring.md +++ /dev/null @@ -1,52 +0,0 @@ ---- -title: "Deal Scoring" -type: concept -tags: [sales, pipeline, metrics] -last_updated: 2026-04-20 ---- - -## Summary -- 定义：销售机会加权评分模型，用于将真实 pipeline 与虚构 pipeline 分离 -- 目的：量化交易质量，识别风险，提前预警 - -## Framework - -### 评分要素 -基于 MEDDPICC 八要素，每要素 5 分制，总分 40 分 - -| 要素 | 分值 | 关键问题 | -|------|------|----------| -| Metrics | 5 | 可量化的业务成果是什么？ | -| Economic Buyer | 5 | 是否接触到了有预算决策权的人？ | -| Decision Criteria | 5 | 是否明确并已影响评估标准？ | -| Decision Process | 5 | 是否完整映射了决策流程？ | -| Paper Process | 5 | 是否识别了法务和采购流程？ | -| Identify Pain | 5 | 是否量化了痛点的业务成本？ | -| Champion | 5 | Champion 是否有权力、访问和动机？ | -| Competition | 5 | 是否分析了竞争格局？ | - -### Deal Verdict -- **WINNING (32-40)**：高置信度赢单 -- **BATTLING (24-31)**：可赢但需关闭关键差距 -- **LOSING (0-23)**：需要重新评估或退出 - -## Red Flags -- 单一联系人线程（单一销售线索） -- 无经济决策者接触 -- 无竞争分析 -- 未讨论 Paper Process -- 买方无法量化痛点成本 -- Champion 拒绝困难请求 - -## Success Metrics -- Commit 交易关闭率 85%+ -- 28/40 分以上交易赢单率 35%+ - -## Connections -- [[MEDDPICC]]：评分框架基础 -- [[Deal Strategist]]：使用 Deal Scoring 的 AI Agent -- [[Pipeline Hygiene]]：pipeline 健康度管理 - -## Aliases -- Opportunity Scoring -- Deal Qualification Score \ No newline at end of file diff --git a/wiki/concepts/DealStrategy.md b/wiki/concepts/DealStrategy.md deleted file mode 100644 index fb0d7a1e..00000000 --- a/wiki/concepts/DealStrategy.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: "Deal Strategy" -type: concept -tags: [sales, strategy, coaching] -last_updated: 2026-04-20 ---- - -## Summary -- 定义：系统化准备和管理销售交易的策略框架 -- 包含：Deal Prep（交易准备）和 blameless debrief（无责复盘） - -## Deal Prep -每次重要会议前准备： -1. 目标是什么 -2. 买家需要听到什么 -3. 我们的诉求是什么 -4. 三个最可能的反对意见及处理方案 - -## Blameless Debrief -每次丢单后分析： -- 资格问题（不该在）vs 执行问题（在但没做好）vs 竞争（在且做得好但对手更好） -- 不同诊断对应不同 coaching 干预 - -## Mutual Evaluation Plan -- 与买家共同制定评估步骤、标准、时间线 -- 创建共同责任 -- 减少失联风险 - -## Decision Process -- 识别买家内部实际决策流程（通常不是买家最初描述的那样） -- 识别关键决策者和影响者 - -## Connections -- [[Sales Coaching]]：通过交易策略进行 coaching -- [[Sales Coach]]：实施 Deal Strategy 的 AI Agent -- [[MEDDPICC]]：资格认证框架用于识别决策过程 \ No newline at end of file diff --git a/wiki/concepts/Declarative-Configuration.md b/wiki/concepts/Declarative-Configuration.md deleted file mode 100644 index ba163be3..00000000 --- a/wiki/concepts/Declarative-Configuration.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "Declarative Configuration" -type: concept -tags: [DevOps, GitOps, 配置管理] -sources: [ctp-topic-33-an-introduction-to-gitops.md] -last_updated: 2026-04-19 ---- - -## Definition -Declarative Configuration（声明式配置）是一种配置管理方法，通过描述系统的期望状态（what）而非具体步骤（how）来定义基础设施和应用配置。 - -## Key Characteristics -- 定义期望的结果状态，而非实现步骤 -- 工具负责计算如何达到期望状态 -- 幂等性：多次应用产生相同结果 -- 易于理解和版本控制 - -## Examples -- Kubernetes YAML 配置 -- Terraform HCL 配置 -- Docker Compose 配置 -- Ansible Playbook - -## Related Concepts -- [[Infrastructure as Code (IaC)]] -- [[GitOps]] -- [[Idempotent Operation]]（幂等操作） - -## Related Sources -- [[ctp-topic-33-an-introduction-to-gitops]] — GitOps 入门介绍 \ No newline at end of file diff --git a/wiki/concepts/Default-Bias.md b/wiki/concepts/Default-Bias.md deleted file mode 100644 index c1958f90..00000000 --- a/wiki/concepts/Default-Bias.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: "Default Bias" -type: concept -tags: [behavioral-psychology, persuasion, user-engagement] -sources: [product-behavioral-nudge-engine] -last_updated: 2026-04-20 ---- - -## Definition -利用用户默认倾向（如接受预起草内容）来提升行动完成率的行为心理学原理。 - -## Mechanism -- 预起草回复、方案、内容 -- 用户只需确认或微调，而非从零开始 -- 减少决策摩擦，提升完成率 - -## Example -> "I've drafted a thank-you reply for this 5-star review. Should I send it, or do you want to edit?" - -## Related Concepts -- [[Momentum Nudge]] -- [[Opt-Out Completion]] -- [[Cognitive Load Reduction]] - -## Connections -- [[Behavioral Nudge Engine]] ← leverages ← [[Default Bias]] diff --git a/wiki/concepts/Defense-in-Depth.md b/wiki/concepts/Defense-in-Depth.md deleted file mode 100644 index 52712903..00000000 --- a/wiki/concepts/Defense-in-Depth.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "Defense in Depth" -type: concept -tags: [security, architecture, risk-mitigation] -sources: [self-healing-home-server-infrastructure-management] -last_updated: 2026-04-17 ---- - -## Summary -Defense in Depth（纵深防御）是一种多层安全架构策略，通过在多个层面部署安全控制来保护系统，即使某一层被突破，其他层仍能提供保护。在 AI Agent 安全设置中尤为重要。 - -## Definition -通过在网络、主机、应用和数据多个层面部署互补的安全控制，实现全面防护的安全架构。 - -## Key Layers -1. **网络层**：网络分段、防火墙、入侵检测 -2. **主机层**：访问控制、系统加固、监控 -3. **应用层**：输入验证、安全扫描、审计日志 -4. **数据层**：加密、访问控制、备份 - -## AI Agent Security Application -- 专用 1Password vault 限制 AI 访问范围 -- 网络分段隔离敏感服务 -- 每日安全审计检查特权容器、硬编码 secrets、过度宽松权限 -- 分支保护：PR 必须人工审查，Agent 无法覆盖 - -## Connections -- [[TruffleHog]] ← implements ← [[Defense in Depth]]：TruffleHog 扫描实现应用层安全 -- [[Gitea]] ← enables ← [[Defense in Depth]]：本地 Git 作为防御层 -- [[Zero Trust Architecture]] ← related_to ← [[Defense in Depth]]：纵深防御是零信任的基础 \ No newline at end of file diff --git a/wiki/concepts/Demand-Management.md b/wiki/concepts/Demand-Management.md deleted file mode 100644 index 62cf82f0..00000000 --- a/wiki/concepts/Demand-Management.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: "Demand Management" -type: concept -tags: [ITSM, Cloud, FinOps] ---- - -## Definition -需求管理是一种平衡用户请求与可用容量的业务流程，确保组织能够有效地管理和分配资源。 - -## Context -在云资源管理的背景下，需求管理用于平衡对超大规模云服务商（如 AWS、Azure、GCP）的资源请求与组织可用的计算、存储和网络容量。Oli 工作流通过三阶段审批流程实现需求管理：可行性验证、技术可行性验证和预算可用性验证。 - -## Key Points -- 请求方负责推动其工作流获得批准 -- 审批流程包括：发起人、请求者经理、M5、实验室服务总监、基础设施 M5、云服务基础设施、云服务、最终审批（Shannon 或 MUI） -- 机器应执行机器能做的事，实现自动化处理 -- 目标是让业务部门 80% 的时间能够自主选择所需服务 - -## Related Concepts -- [[ITIL Framework]] -- [[Service Catalog]] -- [[Workflow Process]] - -## Related Entities -- [[FinOps Team]] -- [[FPNA Team]] \ No newline at end of file diff --git a/wiki/concepts/Demo-Engineering.md b/wiki/concepts/Demo-Engineering.md deleted file mode 100644 index 7249d072..00000000 --- a/wiki/concepts/Demo-Engineering.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: "Demo Engineering" -type: concept -tags: [sales, pre-sales, demonstration] ---- - -## Definition -以影响为导向的演示设计方法论，在展示产品功能前先量化买方的问题，确保演示叙事以业务成果而非产品功能为中心。 - -## Core Principles -- **Lead With Impact, Not Features**：先展示问题解决方案，再解释实现方式 -- **Quantify the Problem First**：用具体数据复述买方痛点 -- **Show the Outcome First**：先展示结果（仪表盘、报告、工作流），再进入技术细节 -- **Close with Proof**：以客户参考或基准数据结束 - -## Demo Structure -1. 量化问题（复述发现阶段的痛点数据） -2. 展示成果（先展示最终状态） -3. 逆向讲解（解释配置和架构） -4. 关闭证据（提供类似案例的量化成果） - -## Tailored Demos -每次演示必须针对特定买方定制： -- 映射买方前三大痛点到具体产品能力 -- 识别观众类型（技术评估者需架构深度，业务赞助者需成果和时间线） -- 准备两条路径：计划叙事和灵活深度演示 - -## "Aha Moment" Test -每个演示应产生至少一个买方说"这正是我们需要的"的时刻。未产生此时刻的演示视为失败。 - -## Connections -- [[Sales Engineer]] — 执行演示工程的主体 -- [[Technical Discovery]] — 演示设计的输入来源 -- [[POC-Scoping]] — 演示成功的能力可能进入 POC 范围 \ No newline at end of file diff --git a/wiki/concepts/Dengbao.md b/wiki/concepts/Dengbao.md deleted file mode 100644 index 4190faae..00000000 --- a/wiki/concepts/Dengbao.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: "Dengbao" -type: concept -tags: [security, compliance, government-it] -last_updated: 2026-04-20 ---- - -## Definition -Dengbao（网络安全等级保护）是中国信息系统安全的分级保护制度，政府与关键信息系统通常需要满足相应等级的建设、测评与整改要求。 - -## Core Points -- 常见政府系统至少需要满足等保三级要求 -- 重点系统可能需要更高等级控制 -- 涵盖边界防护、身份认证、日志审计、数据保护等内容 -- 通常在系统上线前完成测评与整改闭环 - -## Related Concepts -- [[Compliance Enforcement]] -- [[Government Procurement]] -- [[Digital Government]] - -## Related Entities -- [[Government Digital Presales Consultant]] diff --git a/wiki/concepts/Design-System.md b/wiki/concepts/Design-System.md deleted file mode 100644 index fb4d594c..00000000 --- a/wiki/concepts/Design-System.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: "Design System" -type: concept -tags: [UI Design, The Agency, Component Library] ---- - -## 定义 -一套完整的设计标准文档，包含设计令牌系统、组件库架构、响应式框架和可访问性标准，用于在产品生态系统中实现视觉一致性和用户体验统一。 - -## 核心组成 -- **Design Token**：设计令牌系统，包含颜色、字体、间距、阴影、过渡等视觉变量 -- **Component Library**：组件库，包含按钮、表单、导航、反馈等基础组件 -- **Responsive Framework**：响应式框架，通过移动优先方法实现跨设备适配 -- **Accessibility Standards**：可访问性标准，包含 WCAG AA 合规要求 - -## 设计原则 -- 设计系统优先方法论：在创建单个界面之前建立组件基础 -- 可访问性优先：默认包含 WCAG AA 最低标准 -- 响应式优先：移动优先方法实现跨设备体验 -- 开发者交接导向：提供精确的测量数据和资产文件 - -## 典型应用 -- UI Designer 智能体使用设计系统创建完整的组件库架构 -- 开发者根据设计系统实现像素级界面 -- 设计师与开发者通过设计系统进行高效协作 - -## 资源 -- [[UI Designer]]：设计系统的创造者和维护者 \ No newline at end of file diff --git a/wiki/concepts/Designing-for-Agentic-AI.md b/wiki/concepts/Designing-for-Agentic-AI.md deleted file mode 100644 index bea75fb2..00000000 --- a/wiki/concepts/Designing-for-Agentic-AI.md +++ /dev/null @@ -1,49 +0,0 @@ ---- -title: "Designing for Agentic AI" -type: concept -tags: [agentic-ai, product-design, ux-design, ai-experience] -sources: [designing-for-agentic-ai] -last_updated: 2026-04-18 ---- - -## Summary -为 Agentic AI（智能体 AI）设计产品体验的最佳实践框架，包含五大核心原则。 - -## Definition -Agentic AI 产品设计原则是设计具备自主决策能力的 AI 系统时所遵循的设计最佳实践，从传统的响应式界面转向提供实时反馈的主动式体验。 - -## Core Principles - -### 1. 透明度（Transparency） -- 可视化 AI 完成任务的进展 -- 提供 AI 推理过程的摘要 -- 用户能理解 AI 如何做出决策 - -### 2. 控制力（Control） -- 提供明确的停止 AI 行为的方式 -- 提供撤销 AI 已执行操作的方式 -- 允许用户设置 AI 行为偏好 - -### 3. 个性化（Personalization） -- 利用用户过去行为预判未来需求 -- 提供相关建议 -- 允许用户反馈 AI 表现 - -### 4. 对话（Conversation） -- 使用自然语言对话界面 -- 提供 AI 如何理解输入的反馈 -- 直观、自然的交互方式 - -### 5. 预判（Anticipation） -- 预判用户需求并主动提供帮助 -- 提供控制 AI 自主级别的选项 -- 提供 AI 预期行为的反馈 - -## Design Metaphor Shift -传统界面：响应用户输入（点击、滑动、编辑） -Agentic AI 界面：实时反馈 + 透明度 = 用户理解与干预 - -## Connections -- [[Agentic AI]] ← uses ← Designing for Agentic AI：Agentic AI 产品需遵循设计原则 -- [[Generative AI]] ← 区别于 ← [[Agentic AI]]：GenAI 创作内容，Agentic AI 执行行动 -- Designing for Agentic AI ← extends ← Product Design：继承传统产品设计原则并扩展 \ No newline at end of file diff --git a/wiki/concepts/DevOps-成熟度模型.md b/wiki/concepts/DevOps-成熟度模型.md deleted file mode 100644 index d7c27312..00000000 --- a/wiki/concepts/DevOps-成熟度模型.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: "DevOps 成熟度模型" -type: concept -tags: [DevOps, Maturity Model, Assessment] -sources: [DevOps-Maturity-Model-From-Traditional-IT-to-Advanced-DevOps, cloud-devop-maturity-guideline] -last_updated: 2026-04-16 ---- - -## Summary -DevOps 成熟度模型是一种用于评估组织 DevOps 实践水平的分级框架，通常包含五个阶段：从初始/应急阶段到完全成熟阶段。 - -## Definition -DevOps 成熟度模型是一个结构化框架，用于指导组织采用和实施 DevOps 原则。该模型帮助组织评估当前的 DevOps 实践水平，识别改进领域，并规划向更高成熟度等级迈进的步骤。 - -## Key Aspects -### 五个成熟度阶段 -1. **初始/应急阶段（Phase 1）**：传统瀑布式开发，团队孤立工作，手动流程，响应式监控 -2. **局部 DevOps 阶段（Phase 2）**：小团队试点 DevOps 实践，引入版本控制和基础自动化 -3. **自动化与定义阶段（Phase 3）**：标准化流程，广泛自动化，安全集成到开发流程 -4. **高度优化阶段（Phase 4）**：持续集成流水线，不可变基础设施，持续安全监控 -5. **完全成熟阶段（Phase 5）**：持续部署，多个每日部署，自主全栈团队 - -### 评估关键领域 -- **文化与战略**：团队协作、透明度、以客户为中心的产品导向思维 -- **自动化**：持续集成/持续部署（CI/CD）、基础设施即代码（IaC） -- **结构与流程**：标准化流程、小块工作、透明进度 -- **协作与共享**：跨功能团队协作、技能整合 -- **技术**：工具选择、现代监控、容器化 - -### 业务收益 -- 更快的市场响应能力 -- 更好的扩展性 -- 增强的运营绩效 -- 更快的交付时间 -- 改进的质量 - -## Connections -- [[DevOps 成熟度模型]] ← extends ← [[DevOps]] -- [[DevOps 成熟度模型]] ← includes ← [[CI/CD 流水线]] -- [[DevOps 成熟度模型]] ← includes ← [[Infrastructure as Code (IaC)]] -- [[DevOps 成熟度模型]] ← includes ← [[DevSecOps]] -- [[DevOps 成熟度模型]] ← includes ← [[敏捷实践]] -- [[DevOps 成熟度模型]] ← evaluated_by ← [[DevOps]] - -## Aliases -- DevOps Maturity Model diff --git a/wiki/concepts/DevOps-文化.md b/wiki/concepts/DevOps-文化.md deleted file mode 100644 index 4d7e68c9..00000000 --- a/wiki/concepts/DevOps-文化.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: "DevOps 文化" -type: concept -tags: [DevOps, 文化, 协作, 敏捷] -sources: [DevOps-Culture-and-Transformation.md] -last_updated: 2025-03-02 ---- - -## Definition -DevOps 文化是一种优先考虑协作、持续学习和客户导向的文化与运营理念，旨在打破开发（Dev）与运维（Ops）之间的组织壁垒，实现整个软件生命周期的共同所有权。 - -## Core Principles（核心原则） -- **协作优先于孤立**：通过跨职能团队消除信息孤岛 -- **自动化赋能**：用工具和自动化加速反馈循环 -- **持续改进 (Kaizen)**：通过迭代学习和无责复盘不断优化 -- **客户导向**：以真实用户问题解决为核心目标 - -## Key Practices（关键实践） -- 跨职能团队建设 -- CI/CD 流水线实施 -- 基础设施即代码 (IaC) -- 监控与可观测性 -- 混沌工程 -- 无责复盘 (Blameless Post-mortems) - -## Related Concepts -- [[CI/CD 流水线]] -- [[Infrastructure as Code (IaC)]] -- [[敏捷实践]] -- [[DevSecOps]] -- [[持续改进]] diff --git a/wiki/concepts/DevOps.md b/wiki/concepts/DevOps.md deleted file mode 100644 index f6220b8f..00000000 --- a/wiki/concepts/DevOps.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: "DevOps" -type: concept -tags: [DevOps, Methodology] -sources: [Cloud-Maturity-Model-A-Detailed-Guide-For-Cloud-Adoption, DevOps-Culture-and-Transformation.md, DevOps-Maturity-Model-From-Traditional-IT-to-Advanced-DevOps, How-Agentic-AI-can-help-for-Cloud-DevOps] -last_updated: 2025-02-28 ---- - -## Summary -DevOps（开发运维一体化）是一种结合软件开发与 IT 运营的方法论，旨在实现持续软件交付。 - -## Definition -DevOps 通过打破开发和运营团队之间的壁垒，实现更快、更可靠的软件部署和更新。 - -## Key Aspects -- 结合开发和运营团队 -- 实现无缝、持续的软件交付 -- 自动化部署流程 -- 缩短上市时间 - -## Connections -- [[DevOps]] ← part_of ← [[Cloud-Maturity-Model]] -- [[DevOps]] ← is_extended_by ← [[DevOps 成熟度模型]] diff --git a/wiki/concepts/DevSecOps.md b/wiki/concepts/DevSecOps.md deleted file mode 100644 index 035d02d8..00000000 --- a/wiki/concepts/DevSecOps.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: "DevSecOps" -type: concept -tags: [devops, security, automation] -sources: [cloud-devop-maturity-guideline, How-Agentic-AI-can-help-for-Cloud-DevOps, what-is-devsecops-best-practices-benefits-and-tools] -last_updated: 2026-04-20 ---- - -## Definition -DevSecOps 是将安全实践集成到 DevOps 流程中的方法论，强调通过自动化、持续合规和主动漏洞管理实现"安全左移"。DevSecOps 将安全职责从单独的安全团队转移到整个开发团队，使安全成为每个人的责任。 - -## Core Principles -- **安全左移（Shift Left）**：在开发生命周期早期嵌入安全检查 -- **自动化安全**：将安全扫描集成到 CI/CD 流水线 -- **持续合规**：自动化合规性检查和报告 -- **主动漏洞管理**：持续扫描和修复漏洞 -- **安全右移（Shift Right）**：发布后持续安全监控 - -## Key Practices -- 自动化 SAST（静态应用安全测试） -- 自动化 DAST（动态应用安全测试） -- 容器镜像安全扫描 -- secrets 管理 -- 安全编码 -- 风险管理 - -## Key Tools -- SAST（静态应用安全测试） -- SCA（软件成分分析） -- IAST（交互式应用安全测试） -- DAST（动态应用安全测试） - -## Connections -- [[DevOps]] ← extends ← [[DevSecOps]] -- [[CI/CD 流水线]] ← embeds ← [[DevSecOps]] -- [[SDLC]] ← integrates_with ← [[DevSecOps]] -- [[Policy-as-Code]] ← implements ← [[DevSecOps]] -- [[Shift Left]] ← is_a ← [[DevSecOps]] -- [[Shift Right]] ← requires ← [[DevSecOps]] -- [[Secure Coding]] ← enables ← [[DevSecOps]] -- [[Risk Management]] ← includes ← [[DevSecOps]] -- [[Access Control]] ← requires ← [[DevSecOps]] -- [[Immutable Infrastructure]] ← enhances ← [[DevSecOps]] -- [[监控可观测性]] ← depends_on ← [[DevSecOps]] \ No newline at end of file diff --git a/wiki/concepts/Diff文件.md b/wiki/concepts/Diff文件.md deleted file mode 100644 index d880d2e1..00000000 --- a/wiki/concepts/Diff文件.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "Diff文件" -type: concept -tags: [cursor, diff, code-review] -date: 2026-04-17 ---- - -## Definition -Diff 文件是显示代码改动对比的视图，帮助开发者快速审查 AI 修改的内容。 - -## Context -- Cursor 代码审查功能 - -## Usage -1. 代码生成后进入"待审查"状态 -2. 使用 Diff 功能查看具体改动 -3. 支持文件逐个审查或整体接收 -4. 点击"撤销"按钮可撤销改动 - -## Important Note -代码改动一旦生成即写入文件，未点击"撤销"按钮前持续保留，需确保先测试代码再确认保存。 - -## Related Entities -- [[Cursor]] \ No newline at end of file diff --git a/wiki/concepts/Digital-Government.md b/wiki/concepts/Digital-Government.md deleted file mode 100644 index 6c0f1852..00000000 --- a/wiki/concepts/Digital-Government.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: "Digital Government" -type: concept -tags: [government, public-sector, transformation] -last_updated: 2026-04-20 ---- - -## Definition -Digital Government 指政府业务、政务服务、数据治理和内部协同的数字化重构，通过统一平台、流程再造和数据共享提升治理效率与服务体验。 - -## Core Dimensions -- 政务服务在线化与一网通办 -- 数据共享交换与治理平台建设 -- 业务流程再造与跨部门协同 -- 安全、合规与可审计能力建设 - -## Related Concepts -- [[Smart City]] -- [[Government Procurement]] -- [[Technical Discovery]] -- [[Solution Architecture (SA)]] -- [[Proof of Concept (POC)]] -- [[Dengbao]] -- [[Miping]] -- [[Xinchuang]] - -## Related Entities -- [[Government Digital Presales Consultant]] -- [[The Agency]] diff --git a/wiki/concepts/Disaster-Recovery.md b/wiki/concepts/Disaster-Recovery.md deleted file mode 100644 index d959dd58..00000000 --- a/wiki/concepts/Disaster-Recovery.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: "Disaster Recovery" -type: concept -tags: [infrastructure, resilience, backup] -last_updated: 2026-04-21 ---- - -## Definition -Disaster Recovery（灾难恢复）是一套在灾难性事件后恢复 IT 系统和数据的策略与流程，确保业务连续性。 - -## Core Metrics -- **RTO（Recovery Time Objective）**：系统允许的最大停机时间 -- **RPO（Recovery Point Objective）**：可接受的最大数据丢失量 - -## Key Components -- **备份策略**：定期创建加密备份，存储于 S3 -- **恢复流程**：经过测试的恢复程序文档 -- **自动化恢复**：通过脚本实现自动故障切换 - -## Implementation -The Agency 项目中的 [[Support Infrastructure Maintainer]] 实现： -- 自动化备份脚本（GPG 加密 + S3 上传） -- 30 天本地保留 + S3 生命周期管理 -- Backup verification 和 Slack 通知 - -## Related Concepts -- [[Feature Flag（特性开关）]]：控制代码路径而不需要重新部署，实现秒级回滚 -- [[ITSM（IT 服务管理）]]：从工单系统演进为战略推动者，实现运营卓越和风险缓解 \ No newline at end of file diff --git a/wiki/concepts/Discovery-Process.md b/wiki/concepts/Discovery-Process.md deleted file mode 100644 index 3ca1f3ea..00000000 --- a/wiki/concepts/Discovery-Process.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: "Discovery Process" -type: concept -tags: [product-management, discovery, user-research] -sources: [product-manager.md] -last_updated: 2026-04-20 ---- - -## Definition -发现阶段是产品开发周期的第一阶段，通过系统化用户研究、行为数据分析和 Support 信号挖掘来定义要解决的问题。 - -## Activities -1. **Structured Problem Interviews**：最少 5-10 次结构化问题访谈 -2. **Behavioral Analytics Mining**：挖掘摩擦模式、drop-off 点和意外使用 -3. **Support Tickets Audit**：审计 Support 票据和 NPS 评语发现重复主题 -4. **User Journey Mapping**：映射当前端到端用户旅程，找出挣扎、放弃或绕过产品的节点 -5. **Synthesis**：将发现合成清晰、证据-backed 的问题陈述 - -## Output -- 清晰的问题陈述（Problem Statement） -- 用户痛点的优先级列表 -- 支持每个问题的证据（访谈引用、数据指标、Support 信号） - -## Key Principle -- 分享原始信号，不只是结论——设计、工程和领导层都应看到原始数据 -- 在验证问题前不讨论解决方案 -- Discovery 质量决定后续所有工作的方向 - -## Minimum Evidence Threshold -每个 >2 周工作量的 initiative 必须至少有： -- 5 次用户访谈，或 -- 等效的行为证据 - -## Connection -- [[Discovery Process]] ← conducted_by ← [[Product Manager Agent]] -- [[Discovery Process]] ← outputs ← [[Product Requirements Document (PRD)]] -- [[Opportunity Assessment]] ← follows ← [[Discovery Process]] diff --git a/wiki/concepts/Discrimination-Metrics.md b/wiki/concepts/Discrimination-Metrics.md deleted file mode 100644 index 1aba7f08..00000000 --- a/wiki/concepts/Discrimination-Metrics.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "Discrimination Metrics" -type: concept -tags: [ml-ops, evaluation, classification] -sources: [specialized-model-qa] -last_updated: 2026-04-20 ---- - -## Definition -歧视度量指标用于衡量模型区分正负样本的能力。 - -## Common Metrics -- AUC -- Gini coefficient -- KS statistic -- F1 / precision / recall（按任务需要） - -## Use in Model QA -- 判断模型是否具备可接受的区分能力 -- 监控不同数据切分上的性能一致性 -- 与校准测试一起评估整体质量 - -## Related Concepts -- [[Calibration Testing]] -- [[Model Audit]] \ No newline at end of file diff --git a/wiki/concepts/Django-Admin.md b/wiki/concepts/Django-Admin.md deleted file mode 100644 index 4d03da49..00000000 --- a/wiki/concepts/Django-Admin.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "Django Admin" -type: concept -tags: [django, web, admin] ---- - -## Definition -Django Admin 是 Django 框架内置的管理后台模块，基于模型自动生成管理界面，支持 CRUD 操作、搜索、过滤等功能。 - -## Core Features -- 自动生成管理界面 -- 支持自定义模型注册 -- 搜索和过滤功能 -- 内联关联模型 -- 富文本编辑器集成 - -## Use Cases -- 内容管理系统后台 -- 数据管理工具 -- 内部管理系统 - -## Related Concepts -- [[Django]]：Django Admin 是 Django 框架的一部分 -- [[TinyMCE]]：Django Admin 常用的富文本编辑器 \ No newline at end of file diff --git a/wiki/concepts/Django-REST-Framework.md b/wiki/concepts/Django-REST-Framework.md deleted file mode 100644 index 3ee6d226..00000000 --- a/wiki/concepts/Django-REST-Framework.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "Django REST Framework" -type: concept -tags: [django, api, rest] ---- - -## Definition -Django REST Framework（DRF）是一个强大且灵活的工具包，用于构建 RESTful API，基于 Django 框架。 - -## Core Features -- RESTful API 构建 -- 序列化器（Serializer） -- ViewSet 和 Router -- 认证和权限系统 -- 自动 API 文档生成 - -## Use Cases -- 移动应用后端 API -- 单页应用（SPA）API -- 第三方集成 API -- n8n 自动化调用接口 - -## Related Concepts -- [[Django]]：Django REST Framework 基于 Django 框架 -- [[n8n]]：可通过 API 调用实现工作流自动化 \ No newline at end of file diff --git a/wiki/concepts/Django.md b/wiki/concepts/Django.md deleted file mode 100644 index 7a6b4b18..00000000 --- a/wiki/concepts/Django.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "Django" -type: concept -tags: [python, web, framework] ---- - -## Definition -Django 是一个高级 Python Web 框架，鼓励快速开发和简洁实用的设计原则。由 Python 编写，强调代码复用和模块化。 - -## Core Features -- ORM（对象关系映射）系统 -- 自动管理后台（Django Admin） -- 表单处理 -- 用户认证系统 -- RSS 聚合框架 - -## Use Cases -- Web 应用开发 -- RESTful API 构建 -- 内容管理系统 -- 数据分析平台 - -## Aliases -- Django Web Framework -- Django Framework - -## Related Concepts -- [[Django-Admin]] -- [[Django-REST-Framework]] -- [[Python]] \ No newline at end of file diff --git a/wiki/concepts/Docker-Compose.md b/wiki/concepts/Docker-Compose.md deleted file mode 100644 index c747d993..00000000 --- a/wiki/concepts/Docker-Compose.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: "Docker-Compose" -type: concept -tags: [docker, container, orchestration] ---- - -## Definition -Docker Compose（Docker Compose V2）是 Docker 官方提供的多容器 Docker 应用定义和运行工具，通过 `docker-compose.yml` 文件声明式配置多容器应用。 - -## Core Components -- **Services**：定义每个容器配置 -- **Volumes**：持久化数据卷 -- **Networks**：容器网络配置 -- **Profiles**：条件性启动服务 - -## Key Features -- 单一命令启动整个应用：`docker compose up` -- 服务依赖管理 -- 环境变量配置 -- 端口映射 -- 卷挂载 - -## Syntax Example -```yaml -services: - web: - image: nginx - ports: - - "80:80" - volumes: - - ./html:/usr/share/nginx/html -``` - -## Use Cases -- 本地开发环境搭建 -- 微服务应用部署 -- CI/CD 测试环境 -- Home Lab 应用（如 Navidrome、Pi-hole 等） - ---- - -## Related -- [[Navidrome]] — 使用 Docker-Compose 部署的服务 -- [[Docker]] — 容器运行时 \ No newline at end of file diff --git a/wiki/concepts/Docker-Daemon-代理.md b/wiki/concepts/Docker-Daemon-代理.md deleted file mode 100644 index 333fd732..00000000 --- a/wiki/concepts/Docker-Daemon-代理.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: "Docker Daemon 代理" -type: concept -tags: [docker, proxy] -last_updated: 2026-04-17 ---- - -## Definition -Docker Daemon 代理是指为 Docker 守护进程（dockerd）配置 HTTP/HTTPS 代理，使 `docker pull`、`docker push` 等操作能够通过代理服务器访问外部网络。 - -## Problem -Docker 守护进程由 systemd 启动，不读取普通用户的 shell 环境变量（如 HTTP_PROXY、HTTPS_PROXY），因此即使系统级配置了代理，Docker 操作仍可能失败。 - -## Solution -通过 systemd drop-in 配置文件为 Docker Daemon 设置环境变量： - -1. 创建配置目录：`sudo mkdir -p /etc/systemd/system/docker.service.d` -2. 创建代理配置文件：`sudo nano /etc/systemd/system/docker.service.d/http-proxy.conf` -3. 添加内容： - ``` - [Service] - Environment="HTTP_PROXY=http://127.0.0.1:10808/" - Environment="HTTPS_PROXY=http://127.0.0.1:10808/" - Environment="NO_PROXY=localhost,127.0.0.1" - ``` -4. 重载并重启：`sudo systemctl daemon-reload && sudo systemctl restart docker` - -## Verification -```bash -docker info | grep -i proxy -``` - -## Related Concepts -- [[SOCKS5代理]]：SOCKS5 代理协议 -- [[透明代理]]：另一种强制流量走代理的机制 -- [[科学上网]]：通过代理服务器绕过网络限制访问被封锁网站的技术 diff --git a/wiki/concepts/Docker-Image.md b/wiki/concepts/Docker-Image.md deleted file mode 100644 index e54237cc..00000000 --- a/wiki/concepts/Docker-Image.md +++ /dev/null @@ -1,139 +0,0 @@ ---- -title: Docker Image -type: concept -tags: [docker, container, virtualization] -last_updated: 2026-04-21 ---- - -# Docker Image - -## Definition - -Docker Image（镜像）是一个轻量级、可执行的独立软件包，包含运行某个软件所需的所有内容：代码、运行时、系统工具、系统库和设置。镜像是 Docker 容器的基础模板。 - -## Key Characteristics - -### 不可变性（Immutable） - -- 镜像一旦创建就不能修改 -- 对容器的修改只存在于容器层 -- 新修改通过创建新镜像实现 - -### 分层结构（Layered） - -- 由多个只读层组成 -- 层可以复用，多个镜像共享基础层 -- 节省存储空间和传输带宽 - -### 可堆叠性（Stackable） - -- 基于已有镜像构建新镜像 -- 使用 Dockerfile 描述构建过程 -- 每条指令创建新层 - -## Image 结构 - -``` -Dockerfile - ↓ -Image = [Layer 3: Application Code] - [Layer 2: Dependencies] - [Layer 1: Base OS] - [Layer 0: BootFS] -``` - -## Common Operations - -### 查看镜像 - -```bash -docker images -docker image ls -``` - -### 拉取镜像 - -```bash -docker pull nginx:latest -docker pull ubuntu:22.04 -``` - -### 删除镜像 - -```bash -docker rmi nginx:latest -docker image prune -a # 删除所有未使用镜像 -``` - -### 标签管理 - -```bash -docker tag nginx:latest myregistry/nginx:v1.0 -``` - -## Image vs Container - -| 特性 | Image | Container | -|------|-------|-----------| -| 状态 | 只读模板 | 可读写实例 | -| 生命周期 | 持久 | 临时 | -| 数量 | 可复用 | 可多实例 | -| 修改 | 不可变 | 写入容器层 | - -## Image Transfer - -Docker 镜像可以在不同主机之间传输，常见方法： - -### docker save/load（推荐） - -```bash -# 导出 -docker save -o image.tar nginx:latest - -# 导入 -docker load < image.tar -``` - -### docker export/import - -```bash -# 导出容器 -docker export -o container.tar container_id - -# 导入为镜像 -docker import container.tar new_image:latest -``` - -### Registry（云端） - -```bash -# 推送 -docker push myregistry/image:tag - -# 拉取 -docker pull myregistry/image:tag -``` - -## Related Concepts - -- [[Docker-Save]]：镜像导出方法 -- [[Docker-Load]]：镜像导入方法 -- [[Docker-Container]]：镜像的运行实例 -- [[Dockerfile]]：镜像构建文件 - -## Relationships - -- [[Docker-Image]] ← 构建 ← [[Dockerfile]] -- [[Docker-Image]] ← 实例化 ← [[Docker-Container]] -- [[Docker-Image]] ← transferred_via ← [[Docker-Save]] -- [[Docker-Image]] ← transferred_via ← [[Docker-Load]] - -## Related Entities - -- [[entities/Docker.md]] - -## Notes - -- 镜像大小取决于基础系统和应用依赖 -- 多架构镜像可通过 manifest list 支持不同平台 -- 定期清理未使用镜像可释放存储空间 diff --git a/wiki/concepts/Docker-Load.md b/wiki/concepts/Docker-Load.md deleted file mode 100644 index 9e5e861d..00000000 --- a/wiki/concepts/Docker-Load.md +++ /dev/null @@ -1,96 +0,0 @@ ---- -title: Docker Load -type: concept -tags: [docker, container, image-transfer] -last_updated: 2026-04-21 ---- - -# Docker Load - -## Definition - -`docker load` 是 Docker CLI 命令，用于从 tar 归档文件加载镜像到本地 Docker 镜像存储。与 `docker save` 配合使用，实现镜像的离线迁移。 - -## Syntax - -```bash -docker load [OPTIONS] -``` - -### Options - -| Option | Description | -|--------|-------------| -| `-i, --input` | 指定输入的 tar 文件（默认从 stdin 读取） | -| `-q, --quiet` | 静默模式，减少输出 | - -## Usage Examples - -### 基本用法 - -```bash -# 从文件加载 -docker load < nginx.tar - -# 指定文件 -docker load -i images.tar - -# 静默模式 -docker load -i images.tar -q -``` - -### 典型工作流：从开发机接收镜像到 NAS - -```bash -# 在开发机上 -docker save -o xiaoya.tar xiaoyaliu/alist:latest - -# 将 xiaoya.tar 复制到 NAS -scp xiaoya.tar nas:/volume1/docker/images/ - -# 在 NAS 上加载 -docker load < xiaoya.tar - -# 验证 -docker images | grep xiaoya -``` - -### 使用 SSH 管道直接传输 - -```bash -# 在目标机器上执行（镜像从远程机器流式传输） -ssh user@source-host 'docker save nginx:latest' | docker load -``` - -## Related Concepts - -- [[Docker-Save]]：对应的导出命令 -- [[Docker-Image]]：被导入的目标 -- [[Docker-TAR-Archive]]：输入的归档文件格式 - -## Relationships - -- [[Docker-Image]] ← 导入为 ← [[Docker-Load]] -- [[Docker-Load]] ← 依赖 ← [[Docker-Save]] - -## Key Points - -1. **完整还原**：从 tar 文件完整恢复镜像，包括所有层和元数据 -2. **自动识别**：自动识别 tar 文件中的镜像名称和标签 -3. **可重复导入**：同一镜像可多次导入（会创建重复条目，需配合 `docker rmi`） -4. **ID 匹配**：如果镜像 ID 已存在，会分配新的 ID - -## Comparison with Alternatives - -| 特性 | docker load | docker import | -|------|-------------|---------------| -| 数据源 | docker save 输出 | docker export 输出 | -| 内容 | 完整镜像（含层） | 容器文件系统快照 | -| 元数据 | 完整保留 | 不保留 | -| 适用场景 | 镜像迁移 | 容器基础创建 | - -## Notes - -- 导入后的镜像默认标签可能为 `:`，需要手动 tag -- 使用 `docker tag` 命令为导入的镜像设置标签 -- 大镜像加载可能需要较长时间，显示进度条 diff --git a/wiki/concepts/Docker-Network.md b/wiki/concepts/Docker-Network.md deleted file mode 100644 index bb425a5c..00000000 --- a/wiki/concepts/Docker-Network.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: "Docker Network" -type: concept -tags: [docker, network, isolation] -last_updated: 2026-04-17 ---- - -## Definition -Docker Network（Docker 网络）是 Docker 容器网络隔离和通信机制。 - -## Network Types -- **bridge**：默认网络，容器间通信 -- **host**：使用主机网络 -- **overlay**：跨主机网络（Swarm） -- **none**：无网络 - -## Commands -```bash -# 查看网络 -docker network ls - -# 创建网络 -docker network create - -# 删除网络 -docker network rm -``` - -## Connections -- [[Portainer]] ← uses ← [[Docker Network]] -- [[Docker]] ← manages ← [[Docker Network]] \ No newline at end of file diff --git a/wiki/concepts/Docker-Save.md b/wiki/concepts/Docker-Save.md deleted file mode 100644 index f48f6ca7..00000000 --- a/wiki/concepts/Docker-Save.md +++ /dev/null @@ -1,76 +0,0 @@ ---- -title: Docker Save -type: concept -tags: [docker, container, image-transfer] -last_updated: 2026-04-21 ---- - -# Docker Save - -## Definition - -`docker save` 是 Docker CLI 命令，用于将一个或多个镜像导出为 tar 归档文件（`.tar`），实现镜像的离线存储和传输。 - -## Syntax - -```bash -docker save [OPTIONS] IMAGE [IMAGE...] -``` - -### Options - -| Option | Description | -|--------|-------------| -| `-o, --output` | 指定输出文件名（默认输出到 stdout） | - -## Usage Examples - -### 基本用法 - -```bash -# 导出单个镜像 -docker save -o nginx.tar nginx:latest - -# 导出多个镜像 -docker save -o images.tar nginx:latest redis:alpine postgres:15 - -# 使用管道传输 -docker save nginx:latest | ssh user@remote-host 'docker load' -``` - -### 典型工作流：将镜像从开发机传输到 NAS - -```bash -# 在开发机上 -docker save -o xiaoya.tar xiaoyaliu/alist:latest - -# 将 xiaoya.tar 复制到 NAS（通过 SMB/SCP） -scp xiaoya.tar nas:/volume1/docker/images/ - -# 在 NAS 上 -docker load < xiaoya.tar -``` - -## Related Concepts - -- [[Docker-Load]]：对应的导入命令 -- [[Docker-Image]]：被导出的对象 -- [[Docker-TAR-Archive]]：生成的归档文件格式 - -## Relationships - -- [[Docker-Image]] ← 导出为 ← [[Docker-Save]] -- [[Docker-Save]] → 输出 → [[Docker-TAR-Archive]] - -## Key Points - -1. **保留镜像层**：完整保留镜像的分层结构 -2. **保留元数据**：包括 CMD、ENTRYPOINT、ENV、LABEL 等 -3. **可移植性**：生成的 tar 文件可在任何 Docker 环境中导入 -4. **适用场景**：离线环境迁移、备份、镜像分发 - -## Notes - -- 文件大小可能较大（包含所有镜像层） -- 多次 save 同一镜像会重复包含所有层 -- 可配合 `docker load` 实现完整的镜像迁移闭环 diff --git a/wiki/concepts/Docker-TAR-Archive.md b/wiki/concepts/Docker-TAR-Archive.md deleted file mode 100644 index ddc1b821..00000000 --- a/wiki/concepts/Docker-TAR-Archive.md +++ /dev/null @@ -1,37 +0,0 @@ -# Docker TAR Archive - -## Definition - -Docker TAR Archive (`.tar`) 是 Docker 镜像的离线分发格式，通过 `docker save` 命令将镜像及其所有层打包成单个 TAR 文件。 - -## Source References - -- [[sources/如何传输Docker-images-并且在另一个Docker安装.md]] - -## Related Concepts - -- [[concepts/Docker-Image.md]] — TAR 文件中包含的 Docker 镜像 - -## Usage - -### 打包镜像 - -```bash -docker save -o : -``` - -### 导入镜像 - -```bash -docker load < -``` - -## 适用场景 - -- **离线环境**：无法访问 Docker Hub 的私有网络 -- **跨设备迁移**：在不同 Docker 环境之间传输镜像 -- **备份恢复**：保存镜像的离线副本 - -## 标签 - -#docker #offline #migration diff --git a/wiki/concepts/Docker-Volume.md b/wiki/concepts/Docker-Volume.md deleted file mode 100644 index 67605af5..00000000 --- a/wiki/concepts/Docker-Volume.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "Docker Volume" -type: concept -tags: [docker, volume, storage, persistence] -last_updated: 2026-04-17 ---- - -## Definition -Docker Volume（数据卷）是 Docker 容器持久化数据的机制，允许容器在重启后保留数据。 - -## Use Cases -- 数据库数据持久化 -- 应用配置存储 -- 日志存储 - -## Commands -```bash -# 查看卷 -docker volume ls - -# 删除卷 -docker volume rm - -# 删除未使用的卷 -docker volume prune -``` - -## Connections -- [[Docker Volume]] ← used_by ← [[Portainer]] -- [[Docker]] ← manages ← [[Docker Volume]] \ No newline at end of file diff --git a/wiki/concepts/Docker-容器化.md b/wiki/concepts/Docker-容器化.md deleted file mode 100644 index b5bc3ccf..00000000 --- a/wiki/concepts/Docker-容器化.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -id: Docker-容器化 -title: "Docker 容器化" -type: concept -tags: - - Docker - - Containerization - - Cloud-Migration - - DevOps -last_updated: 2026-04-18 ---- - -## Aliases -- Containerization -- Containerize - -## Summary -- **定义**：使用 Docker 容器技术将应用程序及其依赖打包为标准化单元的过程 -- **目的**：实现应用的可移植性、一致性和隔离性 -- **云迁移价值**：将遗留应用容器化是云就绪的关键步骤 - -## Key Details -- **核心优势**： - - 跨环境一致性（开发、测试、生产） - - 资源隔离和高效利用 - - 快速部署和弹性伸缩 - - 简化迁移流程（lift-and-shift） -- **适用场景**： - - 微服务架构 - - 云迁移（lift-and-shift） - - 持续集成/持续部署（CI/CD） - - 开发环境标准化 -- **限制**： - - 容器内数据持久化需要额外机制（Volume） - - 有状态应用的容器化复杂度较高 - - 不适合数据库等有状态服务直接运行 - -## Octane Hub 案例 -- Octane Hub 使用 Docker 容器运行各种 Web 应用（QuickSee、Release Manager、Patch Manager） -- 容器化使其能够从本地数据中心无缝迁移到 AWS -- 数据库未直接容器化，使用 EBS 而非 EFS 存储 - -## Connections -- [[Dockerfile]] ← defines ← [[Docker-容器化]] -- [[Docker-Image]] ← builds ← [[Docker-容器化]] -- [[Octane-Hub]] ← uses ← [[Docker-容器化]] -- [[Cloud-Migration]] ← enabled_by ← [[Docker-容器化]] \ No newline at end of file diff --git a/wiki/concepts/Docker-网桥.md b/wiki/concepts/Docker-网桥.md deleted file mode 100644 index 25f29cc4..00000000 --- a/wiki/concepts/Docker-网桥.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: Docker-网桥 -type: concept -tags: [docker, network, bridge] -last_updated: 2026-04-17 ---- - -## Definition -Docker-网桥（Docker Bridge）是 Docker 默认创建的虚拟网桥设备（docker0），用于容器与宿主机之间的网络通信。容器可以通过网桥 IP（Gateway）访问宿主机上的服务。 - -## 获取网桥 IP - -```bash -docker network inspect -``` - -查看输出的 "Gateway" 字段，即为网桥 IP 地址。 - -## Use Cases -- 容器访问宿主机上运行的代理服务 -- 容器与宿主机应用之间的网络通信 - -## Related Concepts -- [[Docker-Network]] -- [[SOCKS5代理]] - -## Related Entities -- [[n8n]] \ No newline at end of file diff --git a/wiki/concepts/Dockerfile.md b/wiki/concepts/Dockerfile.md deleted file mode 100644 index b78c1b73..00000000 --- a/wiki/concepts/Dockerfile.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: Dockerfile -type: concept -tags: [docker, build, image] -last_updated: 2026-04-17 ---- - -## Definition -Dockerfile 是用于构建 Docker 镜像的声明式配置文件，包含基础镜像选择、文件复制、命令执行等步骤。 - -## 基本语法 - -```dockerfile -FROM -USER root -RUN -USER -``` - -## Common Instructions -- FROM：指定基础镜像 -- RUN：执行命令 -- COPY：复制文件 -- WORKDIR：设置工作目录 -- USER：切换用户 -- ENV：设置环境变量 -- EXPOSE：声明端口 -- CMD：容器启动命令 - -## Example - -```dockerfile -FROM n8nio/n8n:latest -USER root -RUN apk update && apk add --no-cache curl wget -USER node -``` - -## Related Concepts -- [[Docker]] -- [[Docker-Image]] -- [[Docker-Compose]] - -## Related Entities -- [[n8n]] \ No newline at end of file diff --git a/wiki/concepts/Document-Generation.md b/wiki/concepts/Document-Generation.md deleted file mode 100644 index ee649b41..00000000 --- a/wiki/concepts/Document-Generation.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "Document Generation" -type: concept -tags: [office-suite, automation, documents] -last_updated: 2026-04-20 ---- - -## Definition -Document Generation 是指通过代码、模板和数据驱动流程自动创建 PDF、PPTX、XLSX、DOCX 等专业文档的工作流，而不是依赖手工排版。 - -## Core Principles -- 选择正确的输出格式和工具链 -- 使用样式、主题和模板保持一致性 -- 将数据与版式分离，提升复用性 -- 兼顾品牌一致性、可访问性和可维护性 -- 在生成前明确受众、目的与交付要求 - -## Common Tooling -- PDF：reportlab、weasyprint、fpdf2、puppeteer -- PPTX：python-pptx、pptxgenjs -- XLSX：openpyxl、xlsxwriter、exceljs -- DOCX：python-docx、docx - -## Related Concepts -- [[Claude Skills]] -- [[Prompt Engineering]] - -## Related Entities -- [[Document Generator]] -- [[The Agency]] diff --git a/wiki/concepts/Domain-Join.md b/wiki/concepts/Domain-Join.md deleted file mode 100644 index 9cc41ae9..00000000 --- a/wiki/concepts/Domain-Join.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "Domain Join" -type: concept -tags: - - aws - - active-directory - - automation -sources: [ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs] -last_updated: 2026-04-18 ---- - -## Definition -通过 SRE-provided AMIs 实现自动化将 Windows/Linux 实例加入 Active Directory 域的技术。 - -## Windows Implementation -在 Terraform user_data 中调用 PowerShell 脚本： -- 自动域加入 -- 自动命名 -- 管理员权限分配 -- 旧对象清理 - -## Linux Implementation -- 支持安全动态 DNS 更新 -- 自动注册 DNS A 记录 - -## Related Concepts -- [[Gruntwork-Landing-Zone]] -- [[swinford-net]] -- [[intsas-local]] -- [[SRE-provided-AMIs]] \ No newline at end of file diff --git a/wiki/concepts/Drive-API.md b/wiki/concepts/Drive-API.md deleted file mode 100644 index 5abc5d31..00000000 --- a/wiki/concepts/Drive-API.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: "Drive API" -type: concept -tags: [google-workspace, api, cloud-storage] ---- - -## Definition -Drive API 是 Google 提供的编程接口，允许第三方应用程序通过 OAuth 2.0 认证访问 Google Drive 云端硬盘服务，实现文件搜索、下载、上传和管理等功能。 - -## Key Operations -| 操作 | 描述 | -|------|------| -| files.list | 列出文件 | -| files.get | 获取文件元数据 | -| files.create | 上传文件 | -| files.update | 更新文件 | -| files.delete | 删除文件 | -| drive.search | 搜索文件 | - -## Prerequisites for Access -1. **Google Cloud Console** 中启用 Drive 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]]：使用 Drive API 的命令行工具 diff --git a/wiki/concepts/Dynamic-Configuration-Management.md b/wiki/concepts/Dynamic-Configuration-Management.md deleted file mode 100644 index 9e4150bd..00000000 --- a/wiki/concepts/Dynamic-Configuration-Management.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: "Dynamic Configuration Management" -type: concept -tags: [configuration, automation, runtime] -sources: [How-Agentic-AI-can-help-for-Cloud-DevOps] -last_updated: 2026-04-16 ---- - -## Summary -Dynamic Configuration Management（动态配置管理）是指在运行时根据性能、成本和业务需求自动调整应用配置的管理方式。 - -## Definition -基于实时监控数据和预设策略，在不重启应用的情况下动态调整配置参数，实现性能和成本的最优化。 - -## Key Mechanisms -- **Parameter Store**：AWS 参数存储服务 -- **Secrets Manager**：AWS 密钥管理服务 -- **ConfigMaps**：Kubernetes 配置映射 -- **实时性能反馈**：根据性能指标自动调优 - -## Connections -- [[Agentic AI]] ← implements ← [[Dynamic Configuration Management]]：Agentic AI 实现动态配置调整 -- [[Auto-scaling]] ← coordinates ← [[Dynamic Configuration Management]]：动态配置与扩缩容协同工作 diff --git a/wiki/concepts/EBS-GP3.md b/wiki/concepts/EBS-GP3.md deleted file mode 100644 index 5c85fd07..00000000 --- a/wiki/concepts/EBS-GP3.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "EBS GP3" -type: concept -tags: [AWS, EBS, Storage, Cost-Optimization] -sources: [] -last_updated: 2026-04-19 ---- - -## Definition -EBS GP3（General Purpose SSD 第3代）是 AWS EBS 的一种卷类型，推荐作为通用型 SSD 的默认选择，成本比 GP2 低 20%，且可独立扩展 IOPS 和吞吐量。 - -## Key Features -- **成本节省**：比 GP2 便宜约 20% -- **独立扩展**：IOPS 和吞吐量可独立于卷大小进行扩展 -- **高 IOPS**：最大 16,000 IOPS（最高配置） -- **高吞吐量**：最大 1,000 MB/s（最高配置） - -## Specifications -| 属性 | GP3 默认 | GP3 最大 | -|------|---------|---------| -| 卷大小 | 1 GiB - 16 TiB | 1 GiB - 16 TiB | -| IOPS | 3,000 | 16,000 | -| 吞吐量 | 125 MB/s | 1,000 MB/s | - -## Use Cases -- 数据库工作负载 -- 虚拟化桌面 -- 应用服务器 -- 开发测试环境 -- 企业应用 - -## Migration from GP2 -- 自动化工具应更新为默认创建 GP3 卷 -- GP2 迁移到 GP3 可立即节省成本 -- 无需停机即可完成迁移 - -## Connections -- [[EBS-GP2]] ← improves ← [[EBS-GP3]] -- [[EBS-Snapshot-Archive]] ← uses ← [[EBS]] -- [[AWS]] ← provides ← [[EBS-GP3]] \ No newline at end of file diff --git a/wiki/concepts/EBS-Snapshot-Archive.md b/wiki/concepts/EBS-Snapshot-Archive.md deleted file mode 100644 index 8a03b34c..00000000 --- a/wiki/concepts/EBS-Snapshot-Archive.md +++ /dev/null @@ -1,53 +0,0 @@ ---- -title: "EBS Snapshot Archive" -type: concept -tags: [AWS, EBS, Snapshot, Storage, Cost-Optimization] -sources: [] -last_updated: 2026-04-19 ---- - -## Definition -EBS Snapshot Archive（EBS 快照归档层）是 AWS EBS 快照的长期存储层，成本比标准快照层低 75%，适合很少需要访问的快照，但恢复时间更长且需保留 90 天。 - -## Key Features -- **成本节省**：比标准快照层低约 75% -- **长期保留**：最短保留期限 90 天 -- **恢复时间**：需要 24-72 小时恢复可用 -- **自动化管理**：通过 Data Lifecycle Manager (DLM) 或 AWS Backup 管理 - -## Pricing Comparison -| 存储类型 | 价格（每 GB/月） | -|---------|----------------| -| 标准快照 | $0.05 | -| 归档快照 | $0.0125 | - -## Use Cases -- 长期合规性快照备份 -- 灾难恢复基础镜像 -- 软件发布版本镜像 -- 历史数据存档 - -## Implementation -通过 DLM 创建生命周期策略： -```json -{ - "LifecyclePolicy": { - "TargetTags": ["Backup"], - "PolicyRules": [ - { - "RuleName": "Archive", - "CopyTags": true, - "TransitionToArchive": { - "DaysAfterCreation": 90 - }, - "RetainUntilExpiration": false - } - ] - } -} -``` - -## Connections -- [[EBS-GP3]] ← uses ← [[EBS]] -- [[Lifecycle-Policy]] → implements → [[EBS-Snapshot-Archive]] -- [[AWS]] ← provides ← [[EBS-Snapshot-Archive]] \ No newline at end of file diff --git a/wiki/concepts/EC2-Image-Builder.md b/wiki/concepts/EC2-Image-Builder.md deleted file mode 100644 index 91f3f592..00000000 --- a/wiki/concepts/EC2-Image-Builder.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -title: "EC2 Image Builder" -type: concept -tags: [AWS, Cloud, Infrastructure] ---- - -## Definition -EC2 Image Builder 是 AWS 的镜像构建服务，用于创建和维护自定义 Amazon Machine Images (AMIs)。 - -## Features -- 自动化镜像构建管道 -- 跨区域复制和共享 -- 内置验证和测试 - -## Use Cases -- Standard AMI 构建 -- 企业镜像标准化 -- 安全合规镜像管理 \ No newline at end of file diff --git a/wiki/concepts/EC2-Spot-Instances.md b/wiki/concepts/EC2-Spot-Instances.md deleted file mode 100644 index 5054a0c2..00000000 --- a/wiki/concepts/EC2-Spot-Instances.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: "EC2 Spot Instances" -type: concept -tags: - - AWS - - EC2 - - Cost-Optimization - - Spot -sources: [] -last_updated: 2026-04-19 ---- - -## Definition -EC2 Spot Instances 是 AWS 提供的一种利用闲置计算容量的实例类型，相比按需定价最高可节省 90% 成本。 - -## Key Characteristics -- 利用 AWS 数据中心的闲置容量 -- 相比按需实例最高可享 90% 折扣 -- 当 AWS 需要回收容量时可能会被中断 -- 提供中断前通知机制 -- 支持与 Auto Scaling、EKS、ECS 集成 - -## Use Cases -- Web 服务（具备容错能力） -- 容器化工作负载 -- 高性能计算批处理 -- 大数据分析 -- CI/CD 流水线 - -## Key Considerations -- **容错能力**：应用需能处理实例中断 -- **灵活性**：支持跨多个实例类型和可用区 -- **无状态**：适合无状态工作负载 -- **中断风险**：AWS 提前 2 分钟通知回收 - -## Best Practices -- 跨实例类型和可用区分散部署 -- 配置自动响应中断的机制 -- 结合 Graviton 使用进一步优化成本 - -## Connections -- [[AWS]] ← provides ← [[EC2-Spot-Instances]] -- [[Cost-Optimization]] ← achieved_by ← [[EC2-Spot-Instances]] -- [[Spot-Interruption]] ← risk_of ← [[EC2-Spot-Instances]] -- [[EKS]] ← supports ← [[EC2-Spot-Instances]] -- [[ECS]] ← supports ← [[EC2-Spot-Instances]] \ No newline at end of file diff --git a/wiki/concepts/EFS-Infrequent-Access.md b/wiki/concepts/EFS-Infrequent-Access.md deleted file mode 100644 index 79c55d91..00000000 --- a/wiki/concepts/EFS-Infrequent-Access.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: "EFS Infrequent Access" -type: concept -tags: [AWS, EFS, Storage, Cost-Optimization] -sources: [] -last_updated: 2026-04-19 ---- - -## Definition -EFS Infrequent Access（EFS 不频繁访问层）是 AWS EFS 的一种存储层，适合很少访问的文件，通过生命周期策略自动将冷文件移动到低成本的存储层。 - -## Key Features -- **成本节省**：比标准层低约 85% -- **自动分层**：通过生命周期策略自动转移 -- **即时访问**：访问不频繁访问层数据时自动移回标准层 -- **最小计费对象**：128KB 以下文件不计费 - -## Pricing -| 存储类型 | 价格（每 GB/月） | -|---------|----------------| -| 标准层 | $0.30 | -| 不频繁访问层 | $0.045 | - -## Lifecycle Policy -```json -{ - "LifecyclePolicies": [ - { - "TransitionToIA": "After 30 days of last access" - } - ] -} -``` - -## Considerations -- **最小计费对象大小**：128KB 以下文件计费为 128KB -- **访问成本**：检索数据时有额外的访问费用 -- **适合场景**：日志文件、备份文件、归档数据 - -## Connections -- [[EFS-Standard]] ← extends ← [[EFS]] -- [[Lifecycle-Policy]] → implements → [[EFS-Infrequent-Access]] -- [[AWS]] ← provides ← [[EFS-Infrequent-Access]] \ No newline at end of file diff --git a/wiki/concepts/EFS-vs-EBS.md b/wiki/concepts/EFS-vs-EBS.md deleted file mode 100644 index 5e5d4034..00000000 --- a/wiki/concepts/EFS-vs-EBS.md +++ /dev/null @@ -1,60 +0,0 @@ ---- -id: EFS-vs-EBS -title: "EFS vs EBS" -type: concept -tags: - - AWS - - Storage - - Cloud-Migration -last_updated: 2026-04-18 ---- - -## Aliases -- EFS -- EBS -- Elastic File System -- Elastic Block Store - -## Summary -- **EFS（Elastic File System）**：AWS 托管的网络文件系统（NFS），支持多实例共享访问 -- **EBS（Elastic Block Store）**：AWS 托管的块存储，附加到单个 EC2 实例 -- **云迁移价值**：正确选型存储对性能和成本至关重要 - -## Key Details - -### EFS 特点 -- **协议**：NFSv4 -- **访问方式**：多可用区网络访问 -- **性能模式**：通用和最大 IO 两种模式 -- **计费**：按存储量和吞吐量计费 -- **适用场景**： - - 文件共享 - - Web 服务内容 - - 备份存储 - - 容器共享存储 -- **限制**： - - 延迟较高，不适合数据库 - - 不支持本地 HDD 性能模式（处理延迟敏感工作负载时性能差） - -### EBS 特点 -- **协议**：块设备 -- **类型**：gp3/gp2、io1/io2、st1、sc1 -- **访问方式**：单实例附加 -- **性能指标**：IOPS 和吞吐量独立配置 -- **适用场景**： - - 操作系统启动盘 - - 数据库存储 - - 应用程序数据 - - 需要低延迟的 工作负载 -- **限制**： - - 仅限于单个可用区 - -## Octane Hub 案例 -- 最初考虑使用 EFS 存储，后因性能问题放弃 -- 改用 EBS 用于实时数据库，EFS 用于备份 -- 验证了 EFS 不适合数据库场景 - -## Connections -- [[AWS]] ← provides ← [[EFS-vs-EBS]] -- [[S3]] ← alternative_to ← [[EFS-vs-EBS]] -- [[Database-Migration]] ← requires ← [[EFS-vs-EBS]] \ No newline at end of file diff --git a/wiki/concepts/EKS-可靠性.md b/wiki/concepts/EKS-可靠性.md deleted file mode 100644 index 13f3caf1..00000000 --- a/wiki/concepts/EKS-可靠性.md +++ /dev/null @@ -1,60 +0,0 @@ ---- -title: "EKS 可靠性" -type: concept -tags: [AWS, EKS, Kubernetes, Reliability] ---- - -## Description -EKS 可靠性是指在 Amazon EKS 集群中实现高可用性和弹性的实践，确保系统在故障发生时仍提供可预测行为。EKS 可靠性涵盖三个层面：应用可靠性、控制平面可靠性、数据平面可靠性。 - -## Three Layers of EKS Reliability - -### 1. 应用可靠性（Application Reliability） -- 避免单点 Pod，使用 [[Pod 反亲和性]] 或 [[拓扑分布约束]] -- [[HPA]]（Horizontal Pod Autoscaler）根据 CPU/内存自动扩展 -- [[VPA]]（Vertical Pod Autoscaler）自动调整资源请求 -- [[探针]]（Liveness、Readiness、Startup）监控 Pod 健康 -- [[Pod 中断预算]] 确保维护期间最低服务水平 -- 部署策略：Rolling、Blue-Green、Canary - -### 2. 控制平面可靠性（Control Plane Reliability） -- 监控控制平面指标（API Server 请求、etcd 状态） -- 安全认证配置 -- 精心配置和测试的 Admission Webhooks -- 集群升级：控制平面和数据平面分阶段升级 -- EKS 平台版本自动透明升级 -- minor 版本 14 个月支持周期后自动升级 - -### 3. 数据平面可靠性（Data Plane Reliability） -- 节点问题检测器（Node Problem Detector） -- 系统资源预留 -- 实施 QoS（Quality of Service）资源配额 -- 资源限制范围（LimitRanges） -- Pod 优先级和抢占 - -## Shared Responsibility Model -根据 AWS 共享责任模型： -- **AWS 负责**：控制平面组件（etcd、API Server、Scheduler、Controller Manager） -- **客户负责**：Worker Node、操作系统、应用配置 -- **Fargate 模式**：AWS 负责节点管理和补丁升级 - -## Related Entities -- [[Surav Paul]]：演讲人 -- [[EKS]] -- [[AWS]] -- [[Fargate]] -- [[Kubernetes]] - -## Related Concepts -- [[Pod 反亲和性]] -- [[拓扑分布约束]] -- [[HPA]] -- [[VPA]] -- [[探针]] -- [[Pod 中断预算]] -- [[共享责任模型]] - -## Connections -- [[EKS 可靠性]] ← 包含 [[Pod 反亲和性]]、[[拓扑分布约束]]、[[HPA]]、[[VPA]]、[[探针]]、[[Pod 中断预算]] -- [[EKS]] ← 提供 [[EKS 可靠性]] -- [[Surav Paul]] ← 阐述 [[EKS 可靠性]] \ No newline at end of file diff --git a/wiki/concepts/ELF.md b/wiki/concepts/ELF.md deleted file mode 100644 index 607953eb..00000000 --- a/wiki/concepts/ELF.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: "ELF" -type: concept -tags: [linux, 可执行文件, 格式] -date: 2026-04-16 ---- - -## Definition -ELF（Executable and Linkable Format，可执行和链接格式）是 Linux 和 Unix 系统的标准可执行文件格式。 - -## Full Name -Executable and Linkable Format - -## Key Characteristics -- 跨平台：Linux、FreeBSD、Solaris 等多种系统使用 -- 支持多种文件类型：可执行文件（.exe）、共享对象（.so）、核心转储文件（core） -- 包含元数据：程序入口、段表、符号表等 - -## Usage -检测可执行文件架构： -```bash -file /bin/bash -# 输出示例：ELF 64-bit LSB executable, x86-64 -# 或：ELF 64-bit LSB executable, ARM aarch64 -``` - -## Related Concepts -- [[x86_64]]：64 位 x86 架构可执行文件 -- [[ARM64]]：64 位 ARM 架构可执行文件 \ No newline at end of file diff --git a/wiki/concepts/ELK-Stack.md b/wiki/concepts/ELK-Stack.md deleted file mode 100644 index 9707cf52..00000000 --- a/wiki/concepts/ELK-Stack.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "ELK Stack" -type: concept -tags: [Log-Analytics, Open-Source, Elasticsearch, Logstash, Kibana] -date: 2026-04-14 ---- - -## Definition -ELK Stack 是开源日志分析技术栈，由 Elasticsearch、Logstash 和 Kibana 三个组件组成，用于日志采集、存储、搜索和可视化。 - -## Components -- **Elasticsearch**：分布式搜索引擎和存储引擎，用于存储和搜索日志数据 -- **Logstash**：日志处理管道，负责日志的聚合、转换和 enrichment -- **Kibana**：Web 前端，用于日志数据的可视化、分析和查询 - -## Usage -ELK Stack 是云环境日志分析的标准开源方案，通过 BEATS 采集日志，Logstash 处理，Elasticsearch 存储，Kibana 可视化。 - -## Connections -- [[ELK Stack]] ← uses ← [[BEATS]] -- [[ELK Stack]] ← uses ← [[Logstash]] -- [[ELK Stack]] ← uses ← [[Elasticsearch]] -- [[ELK Stack]] ← uses ← [[Kibana]] -- [[OpenSearch]] ← extends ← [[ELK Stack]] -- [[Log Analytics]] ← implements ← [[ELK Stack]] \ No newline at end of file diff --git a/wiki/concepts/EOQ.md b/wiki/concepts/EOQ.md deleted file mode 100644 index 7029af65..00000000 --- a/wiki/concepts/EOQ.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: "EOQ（经济订货量）" -type: concept -tags: [supply-chain, inventory-management] ---- - -## Definition -EOQ（Economic Order Quantity，经济订货量）是通过公式计算的最优订货量，平衡订货成本和库存持有成本。 - -## Formula - -``` -EOQ = √(2DS/H) - -其中： -D = 年需求量（Annual demand quantity） -S = 每次订货成本（Cost per order） -H = 单位持有成本（Holding cost rate × unit price） -``` - -## Example -- 年需求量 D = 10,000 件 -- 订货成本 S = ¥500/次 -- 单价 ¥100，持有成本率 20% -- H = ¥100 × 20% = ¥20 - -``` -EOQ = √(2 × 10000 × 500 / 20) = √500,000 = 707 件 -``` - -## Related Concepts -- **ROP（Reorder Point，再订货点）**：ROP = 日均需求 × 交期天数 + 安全库存 -- **安全库存（Safety Stock）**：SS = Z × σdLT，防止缺货的缓冲库存 - -## Connections -- [[Supply Chain Strategist]] ← uses ← [[EOQ（经济订货量）]] -- [[库存管理策略]] — EOQ 是库存管理策略的核心计算工具 - diff --git a/wiki/concepts/ESN-Margin.md b/wiki/concepts/ESN-Margin.md deleted file mode 100644 index aa492d12..00000000 --- a/wiki/concepts/ESN-Margin.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: "ESN Margin" -type: concept -tags: [business-model, france, esn] -date: 2026-04-20 ---- - -## Summary -ESN 在 TJM brut（向客户收取）和支付给顾问费率之间的加价差额，是法国 ESN 商业模式的核心。 - -## Definition -``` -Client pays: 1,000 EUR/day (sell rate) - │ - ESN Margin - 25-40% - │ -ESN pays consultant: 600-750 EUR/day (buy rate / TJM brut) -``` - -## Margin Ranges by Tier -| Tier | Margin | Freelancer Impact | -|------|--------|-------------------| -| Tier 1 | 35-50% | Low leverage, standardized | -| Tier 2 | 25-40% | Medium leverage, negotiable | -| Tier 3 | 15-25% | High leverage, volume play | - -## Key Insight -"同一 Salesforce 架构师通过一个渠道报价 450/day，通过另一个渠道报价 850/day" — 差异来源就是 margin 结构和议价能力。 - -## Connections -- [[ESN Tier Classification]] ← tier_specific -- [[French Consulting Market Navigator]] ← margin_analysis diff --git a/wiki/concepts/Early-Live-Support.md b/wiki/concepts/Early-Live-Support.md deleted file mode 100644 index f0698910..00000000 --- a/wiki/concepts/Early-Live-Support.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: "Early Live Support" -type: concept -tags: [SRE, cloud-transition] -sources: [ctp-topic-30-managing-change] -last_updated: 2026-04-19 ---- - -## Summary -Early Live Support（早期上线支持）是 Build 与 BAU 之间的过渡阶段，确保服务平稳上线。 - -## Definition -在云转型项目中，Early Live Support 是构建阶段完成后的上线过渡阶段，需要完成 Go-Live Checklist。 - -## Key Requirements -- 监控覆盖：确保所有关键服务和基础设施都得到充分监控 -- 支持模型：明确各团队与 SRE 团队的交互方式和责任范围 -- 事件响应流程：建立清晰的事件响应和升级流程 -- SLO/SLI 定义：定义明确的服务等级目标和指标 - -## Go-Live Checklist Items -- [ ] 监控覆盖完整 -- [ ] 支持模型已定义 -- [ ] 事件响应流程已建立 -- [ ] SLO/SLI 已定义 -- [ ] On-call Schedule 已配置 - -## Related Concepts -- [[SRE]]：早期上线支持的主要执行者 -- [[Change Management]]：与变更管理流程相关 - -## Related Entities -- [[Brendan Starnig]]：CTP Topic 30 讲师 - -## Connections -- [[ctp-topic-30-managing-change]] ← is_the_source_for \ No newline at end of file diff --git a/wiki/concepts/Easter-Egg.md b/wiki/concepts/Easter-Egg.md deleted file mode 100644 index 56e55e6f..00000000 --- a/wiki/concepts/Easter-Egg.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: "Easter Egg" -type: concept -tags: [] ---- - -## Definition -彩蛋（Easter Egg）是隐藏的趣味元素，通过特定操作触发，为用户提供探索惊喜和社交分享素材。 - -## Trigger Mechanisms -- **Konami 代码**：↑↑↓↓←→←→BA 键盘序列触发彩虹模式 -- **点击序列**：5 次快速点击特定区域触发漂浮 Emoji -- **悬停区域**：鼠标悬停特定元素触发渐变背景效果 - -## Design Principles -- 彩蛋不应影响核心功能或性能 -- 提供退出机制（如 10 秒后自动关闭） -- 避免过度使用，每个产品 2-3 个为宜 -- 考虑无障碍需求，不依赖纯视觉反馈 - -## Related Concepts -- [[Whimsy Taxonomy]] -- [[Micro-Interaction]] - -## Sources -- [[design-whimsy-injector]] \ No newline at end of file diff --git a/wiki/concepts/Editorial-Notes.md b/wiki/concepts/Editorial-Notes.md deleted file mode 100644 index 8a03d698..00000000 --- a/wiki/concepts/Editorial-Notes.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "Editorial Notes" -type: concept -tags: [writing, editing, review] -sources: [sources/workflow-book-chapter.md] -last_updated: 2026-04-21 ---- - -## 定义 -编辑注释是对章节草稿中假设和证据缺口的明确标注，帮助作者识别需要补充的内容区域。 - -## 核心内容 -- 假设声明：标记未经证实的声明 -- 证据缺口：指出需要引用或数据支持的位置 -- 品类定位评估：检查内容是否强化目标定位 -- 声音一致性检查：确认是否保持作者风格 - -## 作用 -- 为作者提供明确的修订方向 -- 区分 AI 生成内容和作者贡献 -- 保持内容可信度 - -## Aliases -- 编辑注释 -- 编辑笔记 diff --git a/wiki/concepts/Employee-Advocacy.md b/wiki/concepts/Employee-Advocacy.md deleted file mode 100644 index b160dbed..00000000 --- a/wiki/concepts/Employee-Advocacy.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "Employee Advocacy" -type: concept -tags: [marketing, brand, employee] ---- - -## Definition -员工品牌倡导计划设计与大使激活机制，通过授权员工在个人社交网络中分享品牌内容来放大品牌影响力。 - -## Program Components -- **Ambassador Activation**: 激活员工成为品牌代言人 -- **Content Sharing**: 为员工提供可分享的品牌内容 -- **Participation Tracking**: 监控员工参与率和覆盖面 - -## Success Metrics -- 30%+ 员工参与率目标 -- 品牌提及量增加 -- 社交广告投资回报率 3x+ - -## Related Concepts -- [[Cross-Platform Strategy]] -- [[Thought Leadership]] - -## Source -- [[Social Media Strategist]] \ No newline at end of file diff --git a/wiki/concepts/Employer-Brand.md b/wiki/concepts/Employer-Brand.md deleted file mode 100644 index 8419b814..00000000 --- a/wiki/concepts/Employer-Brand.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: "Employer Brand" -type: concept -tags: [hr, recruiting, branding] -sources: [recruitment-specialist] -last_updated: 2026-04-20 ---- - -## Definition -Employer Brand 是候选人与员工对企业工作环境、成长机会、文化与声誉的整体认知。 - -## Core Principles -- 用内容展示真实的工作场景 -- 监控招聘口碑与评价平台反馈 -- 将雇主品牌作为长期招聘资产经营 -- 结合奖项、案例与员工故事增强可信度 - -## Related Entities -- [[Recruitment Specialist]] -- [[The Agency]] diff --git a/wiki/concepts/Enterprise-Architecture-EA.md b/wiki/concepts/Enterprise-Architecture-EA.md deleted file mode 100644 index 42b72c3b..00000000 --- a/wiki/concepts/Enterprise-Architecture-EA.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -id: enterprise-architecture-ea -title: "Enterprise Architecture (EA)" -type: concept -tags: - - Technical-Architecture - - Cloud-Architecture ---- - -## Definition -企业架构（Enterprise Architecture，EA）是架构体系的高层，负责将业务目标转化为技术原则和标准，确保技术投资与商业战略一致。 - -## Position in Architecture Hierarchy -- **企业架构（Enterprise Architecture, EA）**：高层，负责将业务目标转化为技术原则和标准 -- **方案架构（Solution Architecture, SA）**：中间层，负责特定项目或服务的优化实施 -- **技术架构（Technical Architecture, TA）**：底层，负责具体基础设施的设计和实施治理 - -## Responsibilities -- 对接业务战略 -- 制定技术原则和标准 -- 确保技术投资与商业战略一致 - -## Related Concepts -- [[Technical-Architecture-TA]] -- [[Solution-Architecture-SA]] - ---- - -*最后更新: 2026-04-19* \ No newline at end of file diff --git a/wiki/concepts/Enterprise-Architecture.md b/wiki/concepts/Enterprise-Architecture.md deleted file mode 100644 index 7a354718..00000000 --- a/wiki/concepts/Enterprise-Architecture.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: "Enterprise Architecture" -type: concept -tags: [Cloud, Enterprise, Architecture, Governance] -aliases: [EA] -last_updated: 2026-04-18 ---- - -## Definition -企业架构（Enterprise Architecture，EA）帮助组织阐明云架构，向应用团队传达可用资源和要求，确保技术决策与企业目标一致。 - -## Key Attributes -- **Purpose**：提供技术战略视图和治理框架 -- **Scope**：涵盖业务架构、数据架构、应用架构、技术架构 -- **Output**：企业级标准、指南和路线图 - -## Core Functions -1. 阐明云架构（Articulate cloud architecture） -2. 传达可用资源（Communicate available resources） -3. 定义要求（Define requirements） -4. 指导技术决策（Guide technical decisions） - -## Cloud EA Focus Areas -- 业务架构概念（Business architecture concepts） -- 数据连接（Data connections） -- 应用信息（Application information） -- 技术路线图（Technology roadmaps） - -## Relationships -- [[Enterprise Architecture]] → defines → [[Cloud Guardrails]] -- [[Enterprise Architecture]] → guides → [[Landing Zone]] -- [[Enterprise Architecture]] → informs → [[Multi-Account Strategy]] - -## See Also -- [[Landing Zone]] -- [[Cloud Guardrails]] -- [[Multi-Account Strategy]] -- [[Zero Trust Architecture]] \ No newline at end of file diff --git a/wiki/concepts/Error-Budget.md b/wiki/concepts/Error-Budget.md deleted file mode 100644 index c378e962..00000000 --- a/wiki/concepts/Error-Budget.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -id: error-budget -title: "Error Budget（错误预算）" -type: concept -tags: [sre, reliability, availability] -last_updated: 2026-04-19 ---- - -## Definition -Error Budget（错误预算）是系统在不影响客户的前提下可以不可靠的最大时间量。它弥合了开发与运维之间的鸿沟，将失败正常化为开发过程的一部分。 - -## Calculation -``` -Error Budget = 1 - 可用性 SLO -``` - -例如： -- 99.9% SLO → 0.1% Error Budget -- 99.99% SLO → 0.01% Error Budget - -完美可用性是 100%，Error Budget 落在 SLO 和 100% 之间。 - -## Usage -- **在预算内**：开发者可以承担更多风险，快速交付功能 -- **超出预算**：开发者必须做出更保守的选择，优先保证稳定性 - -## Measurement -- [[SLI（服务等级指标）]]：可靠性的可量化度量指标 -- [[SLO（服务等级目标）]]：服务应该达到的性能/可靠性目标 -- [[SLA（服务等级协议）]]：客户级别的正式协议 - -## Importance -1. **监控能力**：快速显示 Error Budget 是否未充分利用或已超出 -2. **小幅度变更**：小迭代变更和充分测试的部署是管理 Error Budget 的关键 -3. **混沌工程**：通过故意引发故障测试系统韧性，确保满足 NFR - -## Relationship -- [[SRE]] ← uses ← Error Budget -- Error Budget ← derives ← [[SLO（服务等级目标）]] -- [[SLO（服务等级目标）]] ← measures ← [[SLI（服务等级指标）]] - -## References -- [[CTP Topic 41 NFR's and Error Budgets]] — Error Budget 概念详解 -- [[Brendan Standing]] — Micro Focus SRE 负责人 -- [[NFR（非功能需求）]] — Error Budget 服务的目标 \ No newline at end of file diff --git a/wiki/concepts/Event-Driven-Architecture.md b/wiki/concepts/Event-Driven-Architecture.md deleted file mode 100644 index 3e861d61..00000000 --- a/wiki/concepts/Event-Driven-Architecture.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: "Event-Driven Architecture" -type: concept -tags: [Architecture, Event-Driven, Async, Serverless] -sources: [] -last_updated: 2026-04-19 ---- - -## Summary -事件驱动架构是一种以事件为核心驱动系统行为的架构模式，实现服务间松耦合。 - -## Definition -Event-Driven Architecture（EDA）是一种软件架构范式，组件之间通过事件（状态变化或动作）进行通信和解耦。 - -## Core Characteristics -- **异步通信**：事件生产者与消费者基于事件解耦 -- **事件驱动**：行为由事件触发，而非直接调用 -- **松耦合**：事件生产者不关心消费者实现 -- **可扩展性**：易于扩展新事件消费者 - -## Use Cases -- 实时数据处理 -- 微服务异步通信 -- 物联网数据采集 -- 实时工作流触发 - -## Related Services -- [[EventBridge]]：AWS 事件总线 -- [[Amazon SQS]]：消息队列 -- [[Amazon SNS]]：发布/订阅通知 -- [[Lambda]]：事件目标 - -## Related Patterns -- [[Message Queue]]：消息队列模式 -- [[Pub/Sub]]：发布/订阅模式 \ No newline at end of file diff --git a/wiki/concepts/Event-Sourcing.md b/wiki/concepts/Event-Sourcing.md deleted file mode 100644 index 529ad0b2..00000000 --- a/wiki/concepts/Event-Sourcing.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: "Event Sourcing" -type: concept -tags: [architecture, event-driven, state-management] ---- - -## Summary -Event Sourcing（事件溯源）是一种软件架构模式，通过存储所有状态变更事件而非仅存储当前状态来重建系统历史。 - -## Definition -事件溯源将应用状态的所有变更存储为一系列不可变的事件对象。通过重放这些事件，可以重建任意时间点的系统状态。 - -## Key Principles -- **事件即事实**：状态变更以事件形式持久化，而非覆盖最终状态 -- **完整审计日志**：天然具备完整的审计追踪能力 -- **时间旅行调试**：可以重放事件序列重现历史状态 -- **解耦读写**：写操作存储事件，读操作通过事件投影计算状态 - -## Relationship to Project State Management -Project State Management 系统将 Event Sourcing 模式应用于项目管理： -- 每个项目事件（progress、blocker、decision、pivot）作为不可变事件存储 -- 项目当前状态通过事件投影计算 -- 决策上下文通过查询事件历史恢复 - -## External Links -- [Event Sourcing Pattern - Martin Fowler](https://martinfowler.com/eaaDev/EventSourcing.html) diff --git a/wiki/concepts/Evidence-Collection.md b/wiki/concepts/Evidence-Collection.md deleted file mode 100644 index 00133e25..00000000 --- a/wiki/concepts/Evidence-Collection.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "Evidence Collection" -type: concept -tags: [compliance, audit, automation] ---- - -## 定义 -系统化收集证明控制有效运作的证据的过程。 - -## 核心原则 -- **自动化收集**：手动证据是脆弱的证据——自动化收集从第一天开始 -- **证据证明有效性**：证据必须证明控制在审计期间有效运作，而不仅是今天存在 - -## 证据收集矩阵 -| 控制 ID | 控制描述 | 证据类型 | 来源 | 收集方法 | 频率 | -|---------|----------|----------|------|----------|------| -| CC6.1 | 逻辑访问控制 | 访问审查日志 | Okta | API 导出 | 季度 | -| CC6.2 | 用户配置 | 入职工单 | Jira | JQL 查询 | 事件触发 | -| CC7.1 | 系统监控 | 告警配置 | Datadog | 仪表板导出 | 月度 | - -## 证据组织 -按控制目标组织证据包，而非按内部团队结构。 - -## 关键要求 -- 证据必须可重复获取 -- 证据必须有时间戳 -- 证据必须涵盖完整审计期 - -## 相关实体 -- [[Compliance Auditor]] diff --git a/wiki/concepts/Executive-Summary.md b/wiki/concepts/Executive-Summary.md deleted file mode 100644 index 43154afb..00000000 --- a/wiki/concepts/Executive-Summary.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: "Executive Summary" -type: concept -tags: [Proposal, Sales, Strategy, consulting, decision-making, c-suite] -sources: [] -last_updated: 2026-04-21 ---- - -## Definition -执行摘要，一种针对 C-suite 决策者的结构化简报格式，要求在 325-475 字内传达复杂业务信息的核心要点。提案中的执行摘要是最关键的部分，许多评估者尤其是高级利益相关者只阅读此部分。 - -## Format Requirements -- **长度**：325-475 words（≤ 500 max） -- **量化**：每个关键发现必须包含 ≥ 1 个量化或比较数据点 -- **结构**：5 部分（SITUATION OVERVIEW / KEY FINDINGS / BUSINESS IMPACT / RECOMMENDATIONS / NEXT STEPS） -- **可操作性**：建议必须包含 Owner + Timeline + Expected Result - -## Format for C-suite Decision Making -1. **Mirror the buyer's situation**（2-3 句） -2. **Introduce the central tension**—不行动的成本或错失的机会 -3. **Present your thesis**—你的方法如何解决这个矛盾 -4. **Offer proof**—具体证据点 -5. **Close with the transformed state**—具体结果 - -## Frameworks Used -- [[McKinsey SCQA Framework]] -- [[BCG Pyramid Principle]] -- [[Bain Action-Oriented Model]] - -## Related Entities -- [[Executive Summary Generator]] \ No newline at end of file diff --git a/wiki/concepts/FBA.md b/wiki/concepts/FBA.md deleted file mode 100644 index 618172e5..00000000 --- a/wiki/concepts/FBA.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: FBA (Fulfillment by Amazon) -type: concept -tags: [logistics, amazon, ecommerce, cross-border] -aliases: [Fulfillment by Amazon, FBM, Merchant-Fulfilled] ---- - -## Definition -亚马逊自营物流服务，卖家将商品发送至亚马逊仓库，亚马逊负责存储、拣货、包装、配送、客服和退换货。 - -## Key Features -- Prime 标识：享受亚马逊 Prime 会员两天达服务 -- Buy Box 优势：FBA 卖家更容易获得 Buy Box -- 客户服务：亚马逊处理客户咨询和退换货 -- 库存管理：亚马逊跟踪库存并自动补货提醒 - -## Cost Components -- 仓储费：月度仓储费 + 长期仓储费 -- 履约费：基于商品尺寸和重量 -- 头程费：卖家将商品运至亚马逊仓库 -- 退换货处理费 - -## Comparison with FBM -- FBA：更快配送、更易获得 Buy Box、更高转化率，但成本更高 -- FBM：成本更低、控制更灵活，但配送慢、获取 Buy Box 难 - -## Connections -- [[Marketing Cross-Border E-Commerce Specialist]] ← uses ← [[FBA (Fulfillment by Amazon)]] -- [[Amazon]] ← provides ← [[FBA (Fulfillment by Amazon)]] \ No newline at end of file diff --git a/wiki/concepts/FIA-Framework.md b/wiki/concepts/FIA-Framework.md deleted file mode 100644 index 3b44930c..00000000 --- a/wiki/concepts/FIA-Framework.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: "FIA Framework" -type: concept -tags: [sales, competitive, positioning] ---- - -## Definition -竞争技术定位框架，包含三个核心要素：事实（Fact）、影响（Impact）、行动（Act）。用于构建基于事实的竞争battlecard，而非情绪化或攻击性的回应。 - -## Framework Components - -### Fact（事实） -- 客观真实的关于竞争对手产品或方案的陈述 -- 无夸大、无歪曲 -- 失去可信度意味着技术评估的终结 - -### Impact（影响） -- 该事实对买方的业务意义 -- 无业务影响的事实只是 trivia -- 示例："竞争对手 X 需要专用的 ETL 层进行数据摄取"是事实 -- "这意味着你的团队需要维护另一个集成点，增加 2-3 周的实施时间和持续的维护开销"是影响 - -### Act（行动） -- 具体要说或做的内容 -- 具体的 talk track、问题或演示时刻 - -## Repositioning Over Attacking -- 从不贬低竞争对手 -- 承认竞争对手优势的同时清晰表达差异化 -- 模式："他们在 [优势领域] 很好。我们的客户通常需要 [不同需求]，因为 [业务原因]，这就是我们方案的不同之处" - -## Landmine Questions -在技术发现阶段提出自然暴露竞争对手弱点的合法问题： -- "你们如何处理 [我们架构独特的场景]？" -- "当 [我们产品原生处理而竞争对手不处理的边缘情况] 会怎样？" -- "你们评估过 [映射到我们差异化点的需求] 如何随着团队增长而扩展吗？" - -## Connections -- [[Sales Engineer]] — 使用 FIA 框架的主体 -- [[Sales Discovery Coach]] — 提供发现方法论支持 -- [[Deal Strategist]] — 协作竞争定位 \ No newline at end of file diff --git a/wiki/concepts/FRP.md b/wiki/concepts/FRP.md deleted file mode 100644 index f55f966e..00000000 --- a/wiki/concepts/FRP.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: FRP -type: concept -tags: [frp, 内网穿透, 穿透] -date: 2025-04-16 ---- - -## Aliases -- Fast Reverse Proxy -- frp - -## Definition -FRP（Fast Reverse Proxy）是一款高性能的反向代理工具，用于内网穿透。它允许用户将内网服务通过公网服务器暴露给外部访问。 - -## Key Characteristics -- 开源（GitHub：fatedier/frp） -- 支持多种协议（TCP、UDP、HTTP、HTTPS） -- 配置简单 -- 支持多种认证方式（token、oidc） -- 客户端/服务端架构 - -## Use Cases -- 将内网 HTTP 服务暴露到公网 -- 远程访问内网 SSH -- 端口映射 -- 负载均衡 - -## Architecture -- **frps**：FRP 服务端，运行在有公网 IP 的 VPS 上 -- **frpc**：FRP 客户端，运行在内网机器上 -- 客户端连接服务端，建立长连接 -- 服务端接收外部请求，转发给客户端 - -## Versions -- 0.65.0（当前版本） -- 0.65.0 for x86_64（linux_amd64） -- 0.65.0 for ARM64（darwin_arm64） - -## Connections -- [[FRP]] ← implements ← [[内网穿透]] -- [[FRPServer]] ← runs_on ← [[VPS2]] -- [[FRP客户端]] ← runs_on ← [[Mac Mini]] \ No newline at end of file diff --git a/wiki/concepts/FSx-for-NetApp-ONTAP.md b/wiki/concepts/FSx-for-NetApp-ONTAP.md deleted file mode 100644 index 09163e1a..00000000 --- a/wiki/concepts/FSx-for-NetApp-ONTAP.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: "FSx for NetApp ONTAP" -type: concept -tags: [AWS, FSx, NetApp, Storage, Cost-Optimization] -sources: [] -last_updated: 2026-04-19 ---- - -## Definition -FSx for NetApp ONTAP 是 AWS 提供的托管 NetApp ONTAP 文件系统服务，支持自动分层功能，可在 SSD 和 HDD 容量池之间自动移动数据以优化成本。 - -## Key Features -- **自动分层**：在 SSD 和 HDD 容量池之间自动移动数据 -- **数据去重**：内置重复数据删除功能 -- **压缩**：支持数据压缩减少存储空间 -- **NetApp 兼容性**：与 ONTAP 原生协议兼容 -- **成本优化**：相比 EBS 可节省高达 60% 成本 - -## Architecture -- **SSD 存储池**：高性能层，存储活跃数据 -- **HDD 容量池**：低成本层，存储冷数据 -- **自动迁移**：根据策略自动在层级之间移动数据 - -## Use Cases -- 企业文件共享 -- 数据库存储 -- 媒体处理 -- 软件开发环境 -- 数据归档 - -## Pricing -- SSD 存储：$0.08/GB/月 -- HDD 容量池：$0.02/GB/月 -- 数据传输：标准 AWS 数据Transfer rates - -## Migration Example -ADM 公司通过多次迁移最终选择 FSx for NetApp ONTAP： -1. 初始迁移到 OpenZFS：成本高 -2. 自托管 NetApp on EC2：高数据传输成本 -3. 迁移到 FSx for NetApp ONTAP：**成本降低 60%** - -## Connections -- [[AWS-FSx]] ← extends ← [[FSx-for-NetApp-ONTAP]] -- [[NetApp]] ← provides ← [[FSx-for-NetApp-ONTAP]] -- [[AD]] ← migrated_to ← [[FSx-for-NetApp-ONTAP]] \ No newline at end of file diff --git a/wiki/concepts/Fairness-Audit.md b/wiki/concepts/Fairness-Audit.md deleted file mode 100644 index 628349d4..00000000 --- a/wiki/concepts/Fairness-Audit.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "Fairness Audit" -type: concept -tags: [responsible-ai, fairness, ml-ops] -sources: [specialized-model-qa] -last_updated: 2026-04-20 ---- - -## Definition -公平性审计用于评估模型是否对受保护群体产生系统性偏差。 - -## Common Checks -- Demographic parity -- Equalized odds -- Performance by subgroup -- Error-rate disparities - -## Use in Model QA -- 识别不公平影响 -- 评估不同群体的风险差异 -- 作为治理与修复建议的依据 - -## Related Concepts -- [[Model Audit]] -- [[SHAP Analysis]] \ No newline at end of file diff --git a/wiki/concepts/Fallback-机制.md b/wiki/concepts/Fallback-机制.md deleted file mode 100644 index 2b316b00..00000000 --- a/wiki/concepts/Fallback-机制.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "Fallback 机制" -type: concept -tags: [ai-agent, model, routing] -last_updated: 2026-04-18 ---- - -## Definition -当默认模型不可用或出现问题时，AI Agent 系统自动切换到备选模型的机制。 - -## Trigger Conditions -1. **显式的 API 服务不可用**：503/502/429/Connection Timeout -2. **隐性的 Token 长度溢出预判**：估计 Token 接近模型上限 -3. **配置文件的"优先级"覆盖**：Agent/Channel 特定配置覆盖全局配置 -4. **节点选择算法**：负载均衡/随机分发可能选中备选模型 - -## Problem -Fallback 机制可能切到一个比原模型更小的模型（如 16K vs 200K），导致立即 overflow。 - -## Related -- [[上下文压缩]] — OpenClaw 的 compaction 机制 -- [[模型配置层级]] — Global Config、Agent Specific Config、环境变量的分层 -- [[MiniMax-M2.7]] — 作者的默认模型，200K context -- [[DeepSeek-Reasoner]] — 只有 16K context 的模型 \ No newline at end of file diff --git a/wiki/concepts/Fan-out-Pattern.md b/wiki/concepts/Fan-out-Pattern.md deleted file mode 100644 index 935e8dda..00000000 --- a/wiki/concepts/Fan-out-Pattern.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "Fan-out Pattern" -type: concept -tags: - - Messaging - - EDA - - Architecture -date: 2026-04-19 ---- - -## Definition -Fan-out Pattern（扇出模式）是一种消息传递模式，一个事件可以同时分发给多个消费者。当一个事件需要触发多个独立的处理流程时，扇出模式可以高效实现一对多的通知机制。 - -## Implementation -- **SNS Topic**：发布/订阅模式，一个消息发布到主题，多个订阅者接收 -- **EventBridge Rule**：基于规则将事件路由到多个目标 - -## Use Cases -- 单个订单创建事件触发：库存更新、通知发送、数据分析、财务处理等多个独立流程 -- 用户注册事件触发：欢迎邮件、积分奖励、偏好初始化等多个独立业务逻辑 - -## Relationship -- [[Event-Driven Architecture]] ← uses ← [[Fan-out Pattern]] -- [[Fan-out Pattern]] ← implemented_by ← [[Amazon SNS]] -- [[Fan-out Pattern]] ← implemented_by ← [[EventBridge]] \ No newline at end of file diff --git a/wiki/concepts/Fargate.md b/wiki/concepts/Fargate.md deleted file mode 100644 index 8e4b0e19..00000000 --- a/wiki/concepts/Fargate.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: "Fargate" -type: concept -tags: [AWS, Serverless, Container] ---- - -## Description -Fargate 是 AWS 提供的无服务器容器运行环境，让用户无需管理底层服务器即可运行容器。在 Fargate 模式下，AWS 负责管理节点、操作系统和补丁升级。 - -## Features -- 无需预置或管理服务器 -- 按实际使用的计算资源付费 -- AWS 自动处理节点管理和安全补丁 -- 与 EKS 和 ECS 集成 - -## Use Case -在 EKS 中使用 Fargate 运行无状态工作负载，让 AWS 管理底层基础设施，专注于应用逻辑。 - -## Related Entities -- [[AWS]] -- [[EKS]] -- [[ECS]] - -## Related Concepts -- [[EKS 可靠性]] -- [[Serverless-Computing]] - -## Connections -- [[Fargate]] ← 提供 [[EKS 可靠性]] \ No newline at end of file diff --git a/wiki/concepts/Feature-Flag.md b/wiki/concepts/Feature-Flag.md deleted file mode 100644 index d2a91f49..00000000 --- a/wiki/concepts/Feature-Flag.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: "Feature Flag" -type: concept -tags: [持续交付, 特性管理, 发布工程] -sources: ["https://launchdarkly.com/blog/rto-vs-rpo/"] -last_updated: 2025-07-26 ---- - -## Definition -Feature Flag（特性开关）是一种将代码部署与功能发布分离的技术，允许在不重新部署的情况下通过配置切换代码执行路径。 - -## Key Concepts -- Deploy != Release：部署代码但不立即向用户开放 -- Kill Switch：紧急关闭机制，用于快速禁用问题功能 -- 渐进式 Rollout：分阶段向用户群发布（1% → 5% → 25% → 100%） - -## Benefits for RTO/RPO -- RTO：从小时级降至秒级（只需关闭开关） -- RPO：Rollback 时不丢失数据，只需切换代码路径 - -## Code Example -```javascript -if (featureFlag.enabled('new-checkout-flow')) { - return newCheckoutProcess(); -} else { - return oldCheckoutProcess(); -} -``` - -## Connections -- [[Kill Switch]] ← 紧急机制 → [[Feature Flag]] -- [[渐进式发布]] ← 发布策略 → [[Feature Flag]] -- [[RTO (Recovery Time Objective)]] ← 降低工具 → [[Feature Flag]] -- [[RPO (Recovery Point Objective)]] ← 保护工具 → [[Feature Flag]] -- [[LaunchDarkly]] ← 平台 → [[Feature Flag]] diff --git a/wiki/concepts/FeatureList.md b/wiki/concepts/FeatureList.md deleted file mode 100644 index 97f31be9..00000000 --- a/wiki/concepts/FeatureList.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: "FeatureList" -type: concept -tags: [] -last_updated: 2025-12-18 ---- - -## Definition -按层级展开的功能点需求表，用于需求构思阶段的结构化表达。是产品经理与 AI 协作时的"思考工具"。 - -## Structure -FeatureList 通常包含以下维度： -- （1）功能模块的分层、分类是否合理 -- （2）细分模块的功能点是否全面、划分是否合理 -- （3）每个功能点的优先级评估是否合理 - -## Usage -在本文中，产品经理先"想"（用自然语言描述需求框架），然后让 Gemini 补全具体的层级结构和功能点。 - -## Aliases -- 功能列表 -- 功能点清单 \ No newline at end of file diff --git a/wiki/concepts/Federated-User.md b/wiki/concepts/Federated-User.md deleted file mode 100644 index e7410655..00000000 --- a/wiki/concepts/Federated-User.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "Federated User" -type: concept -tags: - - aws - - security - - identity -sources: [ctp-topic-1-gruntwork-landing-zone-architecture] -last_updated: 2026-04-18 ---- - -## Summary -通过 AD 组映射到 IAM 角色的联邦身份访问机制，替代传统 IAM 用户实现安全账户管理。 - -## Definition -Federated User（联邦用户）是基于身份提供商（IdP）的访问方式，用户通过企业 Active Directory（AD）进行身份验证，然后通过 SAML 或 OIDC 映射到 AWS IAM 角色获取访问权限。 - -## Advantages -- **集中管理**：用户凭据由企业 AD 集中管理，无需在 AWS 中单独创建 IAM 用户 -- **自动生命周期**：员工离职后自动失去 AWS 访问权限 -- **最小权限原则**：通过 AD 组精确控制用户获得的 IAM 角色和权限 -- **审计合规**：所有访问通过企业身份系统记录和审计 - -## Connections -- [[IAM]] ← accepts ← [[Federated-User]] -- [[Active-Directory]] ← authenticates ← [[Federated-User]] -- [[Gruntwork-Landing-Zone]] ← uses ← [[Federated-User]] \ No newline at end of file diff --git a/wiki/concepts/Feedback-Loop.md b/wiki/concepts/Feedback-Loop.md deleted file mode 100644 index 7583e8c2..00000000 --- a/wiki/concepts/Feedback-Loop.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "Feedback Loop" -type: concept -tags: [workflow, revision, iteration] -sources: [sources/workflow-book-chapter.md] -last_updated: 2026-04-21 ---- - -## 定义 -反馈循环是 Book Co-Author Agent 提供的结构化修订请求机制，通过明确的编辑注释和下一步问题驱动草稿迭代改进。 - -## 组成要素 -- Editorial Notes：假设和证据缺口标注 -- Next Step：具体可执行的修订请求 -- 开放问题：暴露需要作者决策的编辑问题 - -## 目的 -- 将模糊的"需要改进"转化为具体行动项 -- 维持修订过程的可追溯性 -- 确保作者声音和品类定位不被稀释 - -## 与版本化草稿的关系 -反馈循环支撑版本化草稿的演进： -- 每一版本的反馈循环定义下一版本的改进方向 -- 版本编号与反馈循环轮次对应 -- 作者通过反馈循环保持对内容的控制权 - -## Aliases -- 反馈循环 -- 修订循环 diff --git a/wiki/concepts/FinOps.md b/wiki/concepts/FinOps.md deleted file mode 100644 index 58fb3e24..00000000 --- a/wiki/concepts/FinOps.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "FinOps" -type: concept -tags: [cloud, finops, cost-management, financial-operations] -sources: [Cloud-Operating-Model-Key-Strategies-and-Best-Practices] -last_updated: 2026-04-16 ---- - -## Summary -FinOps（云财务运营）是整合财务管理与云资源优化的实践，旨在实现云支出的可见性、控制和持续优化。 - -## Definition -FinOps 弥合了传统财务与云工程团队之间的差距，通过实时监控、智能分析和自动化优化确保云支出合理。 - -## Key Practices -- **成本可见性**：跨云、跨团队的成本分配和追踪 -- **实时监控**：使用 AWS Cost Explorer、Azure Cost Management、GCP Billing Reports -- **自动化优化**：预留实例、Spot 实例、自动扩缩容 -- **预算告警**：设置阈值，超过时自动通知 -- **持续优化**：定期审查资源使用情况，淘汰闲置资源 - -## Metrics -- **Cloud Cost Efficiency**：云成本效率 = 业务价值 / 云支出 -- **Unit Cost**：单位成本 = 总支出 / 产出单位 -- **Savings Rate**：储蓄率 =（优化前支出 - 优化后支出）/ 优化前支出 - -## Connections -- [[Cloud Operating Model]] ← includes ← [[FinOps]] -- [[Cost Optimization]] ← implements ← [[FinOps]]：成本优化是 FinOps 的核心 -- [[Pay-as-you-go]] ← enabled_by ← [[FinOps]]：FinOps 优化按需付费模式 -- [[AIOps]] ← optimizes ← [[FinOps]]：AI 驱动的 FinOps 可预测成本趋势 -- [[Multi-Cloud]] ← requires ← [[FinOps]]：多云环境尤其需要 FinOps \ No newline at end of file diff --git a/wiki/concepts/Fixed-Point.md b/wiki/concepts/Fixed-Point.md deleted file mode 100644 index 33b1cc1f..00000000 --- a/wiki/concepts/Fixed-Point.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "Fixed Point" -type: concept -tags: [] ---- - -## Definition -不动点，记作 G*，满足 Φ(G*) = G*，即自映射 Φ 的不动点。在递归自优化系统中表示稳定的生成能力。 - -## Context -当生成器 G 是不动点时，它在自身的"生成-优化-更新"循环下保持不变。其输出已经编码了自我改进所需的标准。系统目标就是收敛到这个稳定状态。 - -## Mathematical Expression -``` -G* = lim(n→∞) Φ^n(G_0) -``` - -当 Φ 满足适当的连续性或收缩性条件时，可以通过迭代应用获得不动点。 - -## Related Concepts -- [[Self-Map]] -- [[Generator Space]] -- [[Y Combinator]] -- [[Recursive Self-Optimizing Generative Systems]] \ No newline at end of file diff --git a/wiki/concepts/Flash-Loan-Attack.md b/wiki/concepts/Flash-Loan-Attack.md deleted file mode 100644 index c5d2e256..00000000 --- a/wiki/concepts/Flash-Loan-Attack.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: "Flash Loan Attack" -type: concept -tags: [smart-contract, vulnerability, defi, security] -sources: [blockchain-security-auditor] -last_updated: 2026-04-20 ---- - -## Definition -闪电贷攻击（Flash Loan Attack）是 DeFi 特有的攻击向量，利用闪电贷在单笔交易内借用大量资产、操纵市场状态并获取利润的攻击方式。 - -## Characteristics -- **无抵押**：利用区块内临时资金 -- **原子性**：所有操作在单笔交易内完成 -- **大规模**：可借用数百万甚至数亿资产 -- **瞬时性**：交易结束后状态回滚（除非成功） - -## Common Targets -- 借贷协议的抵押品 valuation -- AMM 流动性池价格 -- 跨协议收益聚合器 -- 治理系统（Flash Loan Voting） - -## Attack Patterns -1. **预言机操纵**：借用资产操纵价格后套利 -2. **重入攻击**：借用资产触发重入漏洞 -3. **治理攻击**：借用代币操纵投票 - -## Notable Examples -- Euler Finance ($197M, 2023)：donate-to-reserves 操纵 -- Balancer ($2M, 2021)：嵌套 Flash Loan -- Cream Finance ($130M, 2021)：Flash Loan + 重入 - -## Connections -- [[DeFi Attack Vector]] ← is_type_of ← [[Flash Loan Attack]] -- [[Oracle Manipulation]] ← often_combines_with ← [[Flash Loan Attack]] -- [[Reentrancy]] ← can_combine_with ← [[Flash Loan Attack]] - diff --git a/wiki/concepts/Force-Directed-Layout.md b/wiki/concepts/Force-Directed-Layout.md deleted file mode 100644 index 92098ad7..00000000 --- a/wiki/concepts/Force-Directed-Layout.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "Force-Directed Layout" -type: concept -tags: [graph-layout, algorithm, visualization, gpu] -date: 2026-04-20 ---- - -## Definition -Force-Directed Layout 是一种图布局算法，通过模拟物理力（斥力和引力）来自动排列图节点位置，常用于知识图谱和网络可视化。 - -## Core Attributes -- 节点斥力模拟 -- 边引力模拟 -- 阻尼系数 -- GPU 加速计算 -- 迭代收敛 -- 三维布局支持 - -## Related Concepts -- [[Spatial Computing]]：空间可视化 -- [[Graph Visualization]]：图可视化 - -## Application -知识图谱布局、网络关系可视化、社交网络图、组织结构图 \ No newline at end of file diff --git a/wiki/concepts/ForecastAccuracy.md b/wiki/concepts/ForecastAccuracy.md deleted file mode 100644 index aaf32c0d..00000000 --- a/wiki/concepts/ForecastAccuracy.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: "Forecast Accuracy" -type: concept -tags: [sales, forecast, accuracy] -last_updated: 2026-04-20 ---- - -## Summary -- 定义：销售预测与实际结果的符合程度 -- 目标：预测准确性应在承诺级别的 10% 以内 - -## Commit Criteria -- 基于可验证证据而非乐观主义 -- 问题不是"感觉如何"，而是"需要什么条件才能成交，能否展示这些条件已满足的证据" -- 每个阶段应有明确的证据要求 - -## Categories -- **Upside**：通过努力可能成交 -- **Commit**：基于证据将会成交 -- **Closed**：已签约 - -## Rep Patterns -- 持续过度预测 → coaching 资格严谨性 -- 持续低于预测 → coaching 交易控制和信心 - -## Connections -- [[Sales Coaching]]：通过预测准确性进行 coaching -- [[Sales Coach]]：实施预测准确性管理的 AI Agent -- [[Pipeline Review]]：pipeline review 支持预测 \ No newline at end of file diff --git a/wiki/concepts/Formal-Verification.md b/wiki/concepts/Formal-Verification.md deleted file mode 100644 index 1bf7c9a7..00000000 --- a/wiki/concepts/Formal-Verification.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: "Formal Verification" -type: concept -tags: [smart-contract, security, verification] -sources: [blockchain-security-auditor] -last_updated: 2026-04-20 ---- - -## Definition -形式化验证（Formal Verification）是使用数学方法证明智能合约正确性的技术，通过对代码进行形式化建模并验证其满足指定属性。 - -## Methods -- **Symbolic Execution**：符号执行，遍历代码路径 -- **Model Checking**：模型检验，验证有限状态机 -- **Theorem Proving**：定理证明，数学推导证明 - -## Tools -- **Certora**：以太坊智能合约形式化验证 -- **Halmos**：符号执行工具 -- **KEVM**：EVM 形式化规范 -- **Mythril**：符号执行分析 - -## Use Cases -- 验证协议不变量（如 total shares × price = total assets） -- 证明访问控制逻辑正确性 -- 验证数学公式实现正确性 -- 穷举攻击路径 - -## Limitations -- 状态空间爆炸问题 -- 需要形式化规范（specification） -- 工具和专家稀缺 -- 无法证明元编程安全性 - -## Connections -- [[Static Analysis]] ← complements ← [[Formal Verification]] -- [[Smart Contract Security]] ← enables ← [[Formal Verification]] - diff --git a/wiki/concepts/Foundation-AMI.md b/wiki/concepts/Foundation-AMI.md deleted file mode 100644 index 6329881f..00000000 --- a/wiki/concepts/Foundation-AMI.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: "Foundation AMI" -type: concept -tags: [AWS, AMI, Security] ---- - -## Definition -Foundation AMI（基础亚马逊机器镜像）是基于市场主流操作系统（CentOS, Ubuntu, Windows 等）进行深度加固的镜像，集成了 CIS 安全基准、防病毒软件、日志管理及单点登录功能。 - -## Components -- OS 加固（OS Hardening） -- CIS Benchmarks 安全配置 -- 防病毒软件（McAfee EPO） -- 日志管理（Syslog-ng） -- 单点登录（AD 集成） -- SSM Agent 预装 -- SiteScope 监控预选件 - -## Usage -"即插即用"型镜像，确保所有实例从启动之日起符合组织的安全合规标准。 - -## Related Concepts -- [[Standard AMI]] — 更广泛的标准化镜像概念 -- [[OS Hardening]] — 操作系统加固技术 -- [[CIS Benchmarks]] — 安全配置基准 -- [[SSM Agent]] — AWS 系统管理器代理 \ No newline at end of file diff --git a/wiki/concepts/Foundation-Model.md b/wiki/concepts/Foundation-Model.md deleted file mode 100644 index ec61aa31..00000000 --- a/wiki/concepts/Foundation-Model.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: "Foundation Model" -type: concept -tags: [AI, generative-AI, ML] -sources: [public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machine-learning-20240206] -last_updated: 2024-02-06 ---- - -## Summary -基础模型是具有数十亿参数的大规模预训练模型，能够执行多种任务，是生成式 AI 的核心。 - -## Definition -Foundation Model（基础模型）是经过大规模预训练的大语言模型，具备零样本和少样本学习能力，可通过微调适应各种下游任务。 - -## Key Attributes -- **参数规模**：数十亿参数 -- **训练方式**：大规模预训练 -- **特点**：零样本学习、少样本学习、多任务能力 -- **代表模型**：Amazon Titan、GPT-4、Claude、Llama - -## Connections -- [[AI]] ← powers ← [[Foundation Model]] -- [[Generative AI]] ← powered_by ← [[Foundation Model]] -- [[Amazon Bedrock]] ← hosts ← [[Foundation Model]] -- [[Foundation Model]] ← supports ← [[Fine-Tuning]] -- [[Foundation Model]] ← supports ← [[RAG]] \ No newline at end of file diff --git a/wiki/concepts/Full-Funnel-Advertising.md b/wiki/concepts/Full-Funnel-Advertising.md deleted file mode 100644 index 64a06432..00000000 --- a/wiki/concepts/Full-Funnel-Advertising.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "Full-Funnel Advertising" -type: concept -tags: [advertising, paid-media, campaign] -last_updated: 2026-04-20 ---- - -## Definition -全漏斗广告（Full-Funnel Advertising）是覆盖用户从认知到转化完整路径的广告策略架构，包括认知→参与→再营销→留存四个阶段。 - -## Funnel Stages -- **认知阶段（Awareness）**：触达广泛受众，建立品牌认知 -- **参与阶段（Engagement）**：互动行为（视频观看、页面访问、内容互动） -- **再营销阶段（Retargeting）**：针对高意向用户促进转化 -- **留存阶段（Retention）**：已有客户维护，提升生命周期价值 - -## Budget Distribution -- 认知：20-30% -- 参与：20-30% -- 再营销：30-40% -- 留存：10-20% - -## Platform Strategy -- Meta: Advantage+ campaigns → 认知/再营销 -- LinkedIn: Sponsored Content → 认知/参与 -- TikTok: Spark Ads → 参与/再营销 - -## Connections -- [[Full-Funnel Advertising]] ← drives ← [[Paid Media Paid Social Strategist]] -- [[Full-Funnel Advertising]] ← requires ← [[Audience Engineering]] \ No newline at end of file diff --git a/wiki/concepts/GA4-Implementation.md b/wiki/concepts/GA4-Implementation.md deleted file mode 100644 index 0bd0098f..00000000 --- a/wiki/concepts/GA4-Implementation.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -title: "GA4 Implementation" -type: concept -tags: [Analytics, Google, Tracking, Measurement] ---- - -## Definition -GA4（Google Analytics 4）是 Google 的新一代分析平台，基于事件驱动模型提供跨平台、跨设备的学生追踪能力，相比 UA 新增了用户级分析、机器学习预测和隐私优先设计。 - -## Core Features -- **Event-Based Model**：所有交互转换为事件（自动收集事件 + 自定义事件） -- **Enhanced Measurement**：增强型测量，自动追踪滚动、站点搜索、外链点击、视频互动 -- **Custom Dimensions & Metrics**：自定义维度和指标 -- **Cross-Domain Tracking**：跨域追踪 -- **Ecommerce DataLayer**：电商数据层实现（view_item、add_to_cart、begin_checkout、purchase） - -## Key Events -| Event | Description | -|-------|-------------| -| page_view | 页面浏览 | -| view_item | 查看产品 | -| add_to_cart | 添加到购物车 | -| begin_checkout | 开始结账 | -| purchase | 完成购买 | -| sign_up | 注册 | -| generate_lead | 生成 Lead | - -## Data Layer Implementation -```javascript -dataLayer.push({ - event: 'purchase', - ecommerce: { - transaction_id: 'T12345', - value: 99.00, - currency: 'USD', - items: [{ - item_id: 'SKU123', - item_name: 'Product Name', - price: 99.00, - quantity: 1 - }] - } -}); -``` - -## Debug & Verification -- **GA4 DebugView**：实时查看事件发送 -- **GTM Preview**：GTM 预览模式验证触发 -- **Network Inspection**：检查 gtag.js 请求参数 - -## Related Concepts -- [[Conversion Tracking]]：转化追踪 -- [[Server-Side Tagging]]：服务端标记 -- [[Consent Mode]]：同意模式 - -## Related Entities -- [[Paid Media Tracking & Measurement Specialist]]：GA4 实施专家 \ No newline at end of file diff --git a/wiki/concepts/GPT.md b/wiki/concepts/GPT.md deleted file mode 100644 index 4d6d225d..00000000 --- a/wiki/concepts/GPT.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: "GPT" -type: concept -tags: [partition-table, uefi, storage] -date: 2026-04-16 ---- - -## Aliases -- GPT -- GUID Partition Table -- GUID 分区表 - -## Definition -GPT（GUID Partition Table）是一种现代硬盘分区表标准，作为 MBR 的替代方案，支持 2TB 以上大容量硬盘，与 UEFI 引导完美兼容。 - -## Key Properties -- 最大支持容量：理论上无限（实际受操作系统限制） -- 分区数量：理论上最多 128 个主分区 -- 唯一标识：每个分区有唯一的 GUID 标识符 -- 冗余：GPT 头部信息在磁盘末尾有备份 - -## Use Cases -- UEFI 系统安装（如 Ubuntu 24.04 在 HP ZBook） -- 大容量硬盘分区（>2TB） -- 现代工作站和服务器 - -## Connections -- [[GPT]] ← works_with ← [[UEFI]] -- [[GPT]] ← used_by ← [[Bootable USB]] \ No newline at end of file diff --git a/wiki/concepts/Game-Developer-Agent.md b/wiki/concepts/Game-Developer-Agent.md deleted file mode 100644 index 172852fe..00000000 --- a/wiki/concepts/Game-Developer-Agent.md +++ /dev/null @@ -1,17 +0,0 @@ ---- -title: "Game Developer Agent" -type: concept -tags: [AI Agent, Game Development, Automation] ---- - -## Definition -自主管理游戏全生命周期的 AI Agent，负责游戏开发、维护和部署的完整工作流。 - -## Related To -- [[autonomous-game-dev-pipeline]] — 使用此 Agent 的源案例 -- [[Bugs First 策略]] — 工作流核心规则 -- [[Round Robin 策略]] — 任务调度算法 - -## Aliases -- Game Dev Agent -- 游戏开发 Agent \ No newline at end of file diff --git a/wiki/concepts/Gamification.md b/wiki/concepts/Gamification.md deleted file mode 100644 index 13abf3df..00000000 --- a/wiki/concepts/Gamification.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: "Gamification" -type: concept -tags: [engagement, learning-design] -sources: [] -last_updated: 2026-04-20 ---- - -## Definition -将游戏化元素（非游戏情境中的游戏设计技术和理念）应用于学习设计，提升学习者参与度和完成率。 - -## Core Elements -- **积分（Points）**：学习行为奖励 -- **徽章（Badges）**：成就认可 -- **排行榜（Leaderboards）**：同伴竞争 -- **升级机制（Level-ups）**：成长路径可视化 - -## Application -在线学习平台、合规培训（降低抵触感）、技能认证项目、团队学习挑战 - -## Related Concepts -- [[混合学习]]：学习模式 diff --git a/wiki/concepts/Gap-Assessment.md b/wiki/concepts/Gap-Assessment.md deleted file mode 100644 index 08e111b1..00000000 --- a/wiki/concepts/Gap-Assessment.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: "Gap Assessment" -type: concept -tags: [compliance, audit, security] ---- - -## 定义 -识别组织当前控制状态与目标合规框架要求之间差距的系统化评估过程。 - -## 目的 -量化当前状态与目标状态之间的差距，为修复工作提供优先级依据。 - -## 评估维度 -- 控制存在性：控制是否已实施 -- 控制有效性：控制是否按设计运作 -- 证据完整性：是否有足够证据证明控制有效性 - -## 产出 -- Gap Assessment Report（差距评估报告） -- 优先级修复路线图 -- 估计审计就绪时间 - -## 关键原则 -- 每个差距发现必须包含： - - 具体控制参考（如 CC6.1） - - 当前状态 - - 目标状态 - - 修复步骤 - - 估计工作量 - - 优先级 - -## 相关实体 -- [[Compliance Auditor]] diff --git a/wiki/concepts/Gap-Selling.md b/wiki/concepts/Gap-Selling.md deleted file mode 100644 index 680c6ae5..00000000 --- a/wiki/concepts/Gap-Selling.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: "Gap Selling" -type: concept -tags: [sales, methodology, discovery] ---- - -## 定义 -Keenan 提出的销售方法论，强调销售就是买家当前状态与期望未来状态之间的差距。差距越大，买家的紧迫感越强。 - -## 核心框架 - -### Current State Mapping（当前状态映射） -``` -├── Environment（环境）：当前使用的工具、流程、团队结构 -├── Problems（问题）：什么是坏的、慢的、痛苦的或缺失的 -├── Impact（影响）：这些问题的可量化业务成本 -│ ├── Revenue impact（收入影响）：丢单、增长放缓、客户流失 -│ ├── Cost impact（成本影响）：浪费时间、工具冗余、人工工作 -│ ├── Risk impact（风险影响）：合规、安全、竞争暴露 -│ └── People impact（人员影响）：流失、倦怠、目标未达 -└── Root Cause（根本原因）：为什么存在这些问题（关键锚点） -``` - -### Future State（期望未来状态） -- "解决"后的具体、可衡量目标是什么？ -- 哪些指标会改变，变化幅度多大？ -- 什么变得可能而现在不行？ -- 需要解决的 timeline 是什么？ - -### The Gap（差距） -- 当前状态与期望未来状态之间的距离有多大？ -- 停留在当前状态的代价是什么？ -- 达到未来状态的价值是什么？ -- 买家没有你能自己填补这个差距吗？ - -## 关键洞察 -- 表面问题（"我们的工具慢"）不创造紧迫感 -- 根本原因（"我们使用无法扩展的传统架构，本季度要接入 3 个企业客户"）才创造紧迫感 - -## 关联实体 -- [[Keenan]]：方法论创始人 -- [[Sales Discovery Coach]] \ No newline at end of file diff --git a/wiki/concepts/Gate-Process.md b/wiki/concepts/Gate-Process.md deleted file mode 100644 index c9f7d6dd..00000000 --- a/wiki/concepts/Gate-Process.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: "Gate Process" -type: concept -tags: - - CTP - - Governance - - Approval -date: 2026-04-19 ---- - -## Summary -- 定义：网关审批流程，用于治理项目进度的关键决策点 -- 目的：确保项目在进入下一阶段前满足特定条件和标准 - -## Gate 节点 - -| Gate | 名称 | 目的 | -|------|------|------| -| Gate 0 | 评估准入 | 初步评估需求是否满足进入 POC 的基本条件 | -| Gate 1 | 设计权威审批 | 设计权威（Design Authority）审批解决方案设计，确保符合云原生原则 | -| Gate 3 | 迁移准入 | 最终批准启动生产环境迁移 | - -## Related Concepts -- [[Proof-of-Concept-POC]] — POC 阶段涉及 Gate 0、Gate 1 -- [[Solution-Design]] — Gate 1 审批的核心对象 - ---- - -*最后更新: 2026-04-19* \ No newline at end of file diff --git a/wiki/concepts/Generative-AI.md b/wiki/concepts/Generative-AI.md deleted file mode 100644 index 79620ce9..00000000 --- a/wiki/concepts/Generative-AI.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: "Generative AI" -type: concept -tags: [AI, generative-ai, llm] -sources: [designing-for-agentic-ai] -last_updated: 2026-04-18 ---- - -## Summary -生成式 AI（Generative AI）是一类擅长创建新内容（文本、图像、音乐等）的 AI 系统，与 Agentic AI 形成对比。 - -## Definition -Generative AI（生成式 AI）是指能够根据学习到的模式和数据创建新内容的 AI 系统，核心能力是创造而非行动。 - -## Key Capabilities -- **内容生成**：创作文本、图像、音频、视频 -- **语言翻译**：跨语言内容转换 -- **摘要生成**：长文本压缩为要点 -- **代码生成**：根据描述生成程序代码 - -## Example Comparison - -| 场景 | Generative AI | Agentic AI | -|------|--------------|------------| -| 写诗 | 生成一首关于猫的诗 | — | -| 安排会议 | — | 找到双方空闲时间并发送日历邀请 | - -## Distinction from Agentic AI -- **Generative AI**：创意助手，生成新内容 -- **Agentic AI**：行动代理，交互环境并执行任务 - -## Connections -- [[Agentic AI]] ← 区别于 ← Generative AI：核心用途不同 -- [[LLM]] ← powers ← Generative AI：大语言模型是 GenAI 的技术基础 -- [[Foundation Model]] ← powers ← Generative AI：基础模型是生成式 AI 的核心 -- [[Amazon Bedrock]] ← provides ← Generative AI：AWS 提供 Bedrock 服务 \ No newline at end of file diff --git a/wiki/concepts/Generator-Space.md b/wiki/concepts/Generator-Space.md deleted file mode 100644 index 82236f2d..00000000 --- a/wiki/concepts/Generator-Space.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -title: "Generator Space" -type: concept -tags: [] ---- - -## Definition -生成器空间，记作 G ⊆ P^I，其中每个生成器 G: I → P 是从意图空间 I 到提示空间 P 的函数。 - -## Context -在递归自优化生成系统形式化中，生成器空间是整个系统的核心操作对象。系统不在输出空间优化，而是在生成器空间中进行自引用优化。 - -## Related Concepts -- [[Recursive Self-Optimizing Generative Systems]] -- [[Optimization Operator]] -- [[Meta-Generative Operator]] -- [[Self-Map]] -- [[Fixed Point]] \ No newline at end of file diff --git a/wiki/concepts/Generator.md b/wiki/concepts/Generator.md deleted file mode 100644 index b1211d30..00000000 --- a/wiki/concepts/Generator.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -id: generator -title: "Generator" -type: concept -tags: [Agent, Skill, 设计模式] -sources: [Google-5-Agent-Skill-design-patterns-2026-03-19] -last_updated: 2026-04-17 ---- - -## Summary -从模板生成结构化输出的 Agent Skill 设计模式，解决 agent 输出格式不一致的问题。 - -## Definition -Generator 利用"填空"流程，通过模板和样式指南强制一致的输出格式。 - -## Components -- **assets/**：存放输出模板 -- **references/**：存放样式指南 -- **SKILL.md**：扮演项目经理角色 - -## Workflow -1. 加载模板 -2. 读取样式指南 -3. 向用户询问缺失的变量 -4. 填充文档 - -## Use Cases -- 生成统一的 API 文档 -- 标准化 commit 信息 -- 脚手架项目结构 - -## Related Concepts -- [[Agent-Skill-设计模式]] -- [[Inversion]]：可在最开始依赖 Inversion 收集必要变量 \ No newline at end of file diff --git a/wiki/concepts/Genette-叙事学.md b/wiki/concepts/Genette-叙事学.md deleted file mode 100644 index e98a6566..00000000 --- a/wiki/concepts/Genette-叙事学.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: "Genette 叙事学" -type: concept -tags: [narrative-theory, narratology, voice, focalization] ---- - -## 定义 -Gérard Genette 在《叙事话语》中提出的结构主义叙事学理论，关注叙事文本的技术层面。 - -## 核心概念 -- **叙事时间（Narrative Time）**： - - Order（时序）：故事时间与叙事时间的顺序关系（倒叙、预叙等） - - Duration（时距）：叙事速度与故事时间的比率（概要、省略、场景、停顿） - - Frequency（时频）：事件发生次数与叙事次数的关系 -- **叙事语态（Narrative Mood）**： - - Distance（距离）：叙述者与故事的关系 - - Focalization（聚焦）：感知和认知的视角限定 -- **叙事层次（Narrative Levels）**： - - Extradiegetic（超故事层）：叙述者所在层次 - - Diegetic（故事层）：被叙述的世界 - - Metadiegetic（元故事层）：故事中嵌套的故事 - -## 核心区分 -- **Fabula vs Sjuzhet**：故事（按时间顺序的事件）vs 叙事（讲述方式） -- [[Narratologist]] 强调：Most problems live in the telling (sjuzhet), not the tale (fabula) - -## 来源框架 -- [[Narratologist]] 使用此框架分析 voice、focalization 和 temporal structure diff --git a/wiki/concepts/Geographic-Coherence.md b/wiki/concepts/Geographic-Coherence.md deleted file mode 100644 index 83dfad97..00000000 --- a/wiki/concepts/Geographic-Coherence.md +++ /dev/null @@ -1,76 +0,0 @@ ---- -title: "Geographic Coherence" -type: concept -tags: [geography, worldbuilding, validation] -last_updated: 2026-04-20 ---- - -## Definition -地理连贯性（Geographic Coherence）是指虚构世界中的地理特征（气候、地形、水文、生物群系、资源分布）符合物理规律，彼此一致，无矛盾。 - -## Core Principles - -### 1. Rivers Don't Split -- Tributaries merge into rivers（支流汇入主流） -- Rivers don't fork into two separate rivers flowing to different oceans -- Exception: deltas, bifurcations — but these are special cases, not the norm - -### 2. Climate is a System -- Rain shadows exist（雨影效应存在） -- Coastal currents affect temperature（海岸洋流影响温度） -- Latitude determines seasons（纬度决定季节） -- Don't place a tropical forest at 60°N latitude without extraordinary justification - -### 3. Geography is Not Decoration -- Every mountain, river, and desert has consequences for the people who live near it -- If you put a desert there, explain how people get water - -### 4. Avoid Geographic Determinism -- Geography constrains but doesn't dictate -- Similar environments produce different cultures -- Acknowledge agency - -### 5. Scale Matters -- A "small kingdom" and a "vast empire" have fundamentally different geographic requirements -- Communication, supply lines, and governance scale differently - -### 6. Maps are Arguments -- Every map makes choices about what to include and exclude -- Be aware of the politics of cartography - -## Validation Framework - -### Geographic Coherence Report -``` -Region: [Area being analyzed] - -Physical Geography: -- Terrain: [Landforms and their tectonic/erosional origin] -- Climate Zone: [Koppen classification, latitude, elevation effects] -- Hydrology: [River systems, watersheds, water sources] -- Biome: [Vegetation type consistent with climate and soil] -- Natural Hazards: [Earthquakes, volcanoes, floods, droughts] - -Resource Distribution: -- Agricultural potential: [Soil quality, growing season, rainfall] -- Minerals/Metals: [Geologically plausible deposits] -- Timber/Fuel: [Forest coverage consistent with biome] -- Water access: [Rivers, aquifers, rainfall patterns] - -Human Geography: -- Settlement logic: [Why people would live here — water, defense, trade] -- Trade routes: [Following geographic paths of least resistance] -- Strategic value: [Chokepoints, defensible positions, resource control] -- Carrying capacity: [How many people this geography can support] -``` - -## Related Concepts -- [[Koppen Climate Classification]] -- [[Central Place Theory]] -- [[Heartland Theory]] -- [[World-Systems Theory]] -- [[Environmental Determinism]] - -## Implementation -- Used by [[Geographer]] Agent in worldbuilding -- Validates physical consistency in虚构世界构建 \ No newline at end of file diff --git a/wiki/concepts/Gibberish-Text.md b/wiki/concepts/Gibberish-Text.md deleted file mode 100644 index 4ddbce06..00000000 --- a/wiki/concepts/Gibberish-Text.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "Gibberish Text" -type: concept -tags: [AI Generation, Bias, Cultural] -date: 2026-04-20 ---- - -## Definition -AI 在尝试非英语脚本或文化符号时发明令人反感或无意义字符的问题。常见于生成中文、阿拉伯文、印地文等文字时，AI 会产生看似文字但实际无法识别的"符号"。 - -## Why It Happens -- 训练数据中非拉丁文字的representation不足 -- 模型缺乏对特定文字系统的深度理解 -- 文本渲染模块的幻觉 - -## How to Counter -- 显式负向提示任何生成的文本、标志或标牌 -- 使用"no text"、"no symbols"、"no signs"等约束 -- 后处理阶段使用 OCR 检测并替换为真实文字 - -## Related Concepts -- [[InclusiveVisualsSpecialist]] — 对抗此问题的专家角色 -- [[NegativePromptLibrary]] — 提供防止此问题的负向提示库 -- [[CloneFaces]] — 类似的 AI 幻觉问题 \ No newline at end of file diff --git a/wiki/concepts/Git-集成.md b/wiki/concepts/Git-集成.md deleted file mode 100644 index 0aa1cc78..00000000 --- a/wiki/concepts/Git-集成.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "Git 集成" -type: concept -tags: [git, automation, project-management] ---- - -## Summary -Git 集成是指将代码提交自动关联到项目事件和任务的机制。 - -## Definition -通过扫描 Git 提交历史，基于分支名称或提交信息自动将代码变更关联到对应项目，实现代码变更与项目进度的可追溯性。 - -## Key Capabilities -- **自动提交扫描**：定期扫描 Git 提交日志 -- **项目关联**：基于分支名或提交消息关联到项目 -- **变更追踪**：记录代码变更与项目事件的对应关系 -- **可追溯性**：支持从代码变更追溯到业务决策 - -## Implementation -Project State Management 系统通过 GitHub CLI (gh) 实现： -```bash -gh run list --limit 50 --since "24 hours ago" -gh api repos/{owner}/{repo}/commits -``` - -## Relationship to Project State Management -Git 集成是 Project State Management 的核心功能之一，通过代码变更与项目事件的双向关联实现端到端可追溯性。 diff --git a/wiki/concepts/Git.md b/wiki/concepts/Git.md deleted file mode 100644 index 83fa1a2c..00000000 --- a/wiki/concepts/Git.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: "Git" -type: concept -tags: [Git, VCS, 版本控制, DevOps] -sources: [ctp-topic-2-git.md] -last_updated: 2026-04-19 ---- - -## Definition -Git（分布式版本控制系统）是一种开源的分布式版本控制系统，用于跟踪代码变更、支持多人协作开发。每个开发人员都拥有完整的代码仓库副本，支持离线工作、分支合并和历史追溯。 - -## Core Features -- 分布式架构：每个用户拥有完整仓库副本 -- 分支管理：支持轻量级分支和快速合并 -- 完整性保证：使用 SHA-1 哈希确保数据完整性 -- 性能：本地操作极快，网络操作按需拉取 - -## Common Commands -- `git clone`：克隆远程仓库 -- `git add` / `git commit`：暂存和提交更改 -- `git push` / `git pull`：推送和拉取远程更改 -- `git branch` / `git checkout`：分支管理 -- `git merge` / `git rebase`：合并分支 - -## Related Concepts -- [[Infrastructure as Code (IaC)]] -- [[CI/CD 流水线]] -- [[GitOps]] - -## Related Entities -- [[GitHub]] -- [[GitLab]] -- [[Gitea]] - -## Aliases -- Git -- Git 版本控制 -- 分布式版本控制 \ No newline at end of file diff --git a/wiki/concepts/GitHub-Enterprise-to-GitLab-Migration.md b/wiki/concepts/GitHub-Enterprise-to-GitLab-Migration.md deleted file mode 100644 index 88c6417e..00000000 --- a/wiki/concepts/GitHub-Enterprise-to-GitLab-Migration.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: "GitHub-Enterprise to GitLab Migration" -type: concept -tags: - - DevOps - - Migration - - GitHub - - GitLab -date-added: 2026-04-19 ---- - -## Definition -GitHub-Enterprise to GitLab Migration（GitHub Enterprise 到 GitLab 迁移）是 OpenText 将源代码仓库从 GitHub Enterprise 迁移到 GitLab 的企业级迁移项目。 - -## Migration Approaches -- **Mirroring**：将 GitHub 仓库同步到 GitLab，保持持续更新 -- **Shift and Lift**：将代码复制到 GitLab 并同时转换 CI/CD 管道 - -## Migration Tracking -- 通过 PHT（Product Hub platform）跟踪进度 -- 定期向开发经理和构建倡导者更新 -- 规划指南：清点 GitHub 资产、识别管道、了解网络连接 - -## Key Milestones -1. 安装 GitLab 插件 -2. 早期访问 GitLab -3. 映射仓库到 PHT -4. 设置服务账户 -5. 更新管道 - -## Network Connectivity -- GitLab proxy 位于 Brook Park，可通过 SD1 访问 -- 商业实例连接 GitLab 可能需要 GIS 团队批准例外 - -## Related Entities -- [[GitHub-Enterprise]] -- [[GitLab]] -- [[OpenText]] -- [[Build-Hub]] -- [[Project-Thor]] - -## Connections -- [[GitHub-Enterprise]] → replaced_by → [[GitLab]] -- [[Self-Serve-Migration]] ← applies_to ← [[GitHub-Enterprise-to-GitLab-Migration]] -- [[Build-Hub]] ← supports ← [[GitHub-Enterprise-to-GitLab-Migration]] \ No newline at end of file diff --git a/wiki/concepts/GitOps.md b/wiki/concepts/GitOps.md deleted file mode 100644 index 160c043e..00000000 --- a/wiki/concepts/GitOps.md +++ /dev/null @@ -1,53 +0,0 @@ ---- -title: "GitOps" -type: concept -tags: [DevOps, Git, 基础设施, 部署] -sources: [DevOps-Culture-and-Transformation.md, ctp-topic-33-an-introduction-to-gitops.md] -last_updated: 2026-04-19 ---- - -## Definition -GitOps 是一种使用 Git 作为单一真相源（Single Source of Truth）来管理基础设施和部署的文化理念和运维框架，所有配置和部署声明都存储在 Git 仓库中。它是 DevOps 的逻辑演进，将软件开发原则应用于部署流程。 - -## Key Principles（四大原则） -1. **Declarative Configuration**（声明式配置）：系统以声明形式定义，描述期望状态而非具体步骤 -2. **Version Control**（版本控制）：所有配置存储在 Git 中，实现版本管理和审计追踪 -3. **CD Process Separation**（CD 流程分离）：CI 和 CD 解耦以增强安全性 -4. **Incremental Infrastructure**（增量基础设施）：渐进式实施基础设施变更 - -## Core Benefits（核心优势） -- 使用开发者熟悉的工具提升开发生产力 -- 通过轻松的回滚能力最小化失败部署 -- 支持更快的功能发布 -- 通过 Git 特性实现实时审计和改进安全性 - -## Key Components（核心组件） -- **Git**：存储部署基础设施和应用配置，作为唯一真相源 -- **GitOps Controller**：协调 Git 状态与实际系统状态的代理 -- **CD Pipeline**：自动化部署流程 -- **Infrastructure as Code**：通过代码管理基础设施 - -## Implementation Models（实现模型） -- **Pull Model**（拉取模型）：GitOps 推荐模型，监控 Git 和目标系统，自动同步变更 -- **Push Model**（推送模型）：传统 CI/CD 部署模式，通过触发器推送变更 - -## Kubernetes Workflow -1. 开发者提交代码 -2. 创建容器镜像 -3. 将部署配置存储在 Git 中 -4. GitOps Agent 监控变化 -5. 向环境推出镜像 - -## Key Concepts -- [[Declarative Configuration]]（声明式配置） -- [[Infrastructure as Code (IaC)]]（基础设施即代码） -- [[CI/CD 流水线]] -- [[Pull Model]]（拉取模型） -- [[Idempotent Operation]]（幂等操作） - -## Related Entities -- [[Victor Etkin]] — GitOps 概念的演讲者和布道者 - -## Related Sources -- [[ctp-topic-33-an-introduction-to-gitops]] — GitOps 入门介绍 -- [[DevOps-Culture-and-Transformation]] — DevOps 文化转型 \ No newline at end of file diff --git a/wiki/concepts/Global-First-Architecture.md b/wiki/concepts/Global-First-Architecture.md deleted file mode 100644 index bdc8a8da..00000000 --- a/wiki/concepts/Global-First-Architecture.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: "Global-First Architecture" -type: concept -tags: [design, localization, internationalization] -date: 2026-04-20 ---- - -## Definition -Global-first architecture treats internationalization, localization, and cultural flexibility as prerequisites in the system design rather than late-stage additions. - -## Key Principles -- Support diverse naming conventions and scripts -- Make calendars, formats, and defaults locale-aware -- Avoid hard-coded culture-specific metaphors and symbols -- Build accessibility and translation into the core structure - -## Connections -- [[Cultural Intelligence Strategist]] — encourages this architecture -- [[Cultural Intelligence]] — the broader capability this architecture serves -- [[Design System]] — global-first components reduce exclusion diff --git a/wiki/concepts/Global-Standards-Coverage.md b/wiki/concepts/Global-Standards-Coverage.md deleted file mode 100644 index a1dea752..00000000 --- a/wiki/concepts/Global-Standards-Coverage.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "Global Standards Coverage" -type: concept -tags: [engineering, civil, compliance] ---- - -## Definition -跨多个国家/地区工程规范进行统一设计与审查的能力，通常涉及 Eurocode、ACI、AISC、AS/NZS、CSA、GB、IS、AIJ 以及国家附录、地方修订和 AHJ 要求。 - -## Core Elements -- 法域识别：先确认项目所在地与适用法规 -- 规范映射：为结构、基础、荷载、抗震等子系统选择对应标准 -- ULS / SLS 双重校核：同时满足强度与使用性要求 -- 冲突解决：当业主规范与本地规范冲突时，记录并选择可辩护方案 -- 设计依据报告：将所有规范决策、假设和例外项留痕 - -## Related Entities -- [[Civil Engineer]] -- [[The Agency]] - -## Related Concepts -- [[Technical Discovery]] -- [[Solution Architecture]] -- [[Multi-Agent Team]] diff --git a/wiki/concepts/Gmail-API.md b/wiki/concepts/Gmail-API.md deleted file mode 100644 index 2adacc03..00000000 --- a/wiki/concepts/Gmail-API.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: "Gmail API" -type: concept -tags: [google-workspace, api, email] ---- - -## Definition -Gmail API 是 Google 提供的编程接口，允许第三方应用程序通过 OAuth 2.0 认证访问 Gmail 邮件服务，实现搜索、读取、发送、管理邮件等功能。 - -## Key Operations -| 操作 | 描述 | -|------|------| -| messages.list | 列出邮件列表 | -| messages.get | 获取邮件详情 | -| messages.send | 发送邮件 | -| messages.modify | 修改邮件标签 | -| drafts.create | 创建草稿 | -| drafts.send | 发送草稿 | - -## Prerequisites for Access -1. **Google Cloud Console** 中启用 Gmail API -2. 配置 **OAuth 2.0 凭证**（桌面应用类型） -3. 用户完成 OAuth 授权流程 -4. 添加**测试用户**（未验证应用场景） - -## Common Error -- `403 accessNotConfigured`：API 未在 Google Cloud Console 中启用 -- `403 accessDenied`：用户未完成 OAuth 授权 - -## Related Concepts -- [[OAuth]]：认证机制 -- [[Google-Cloud-Console]]：凭证配置 -- [[测试用户]]：绕过未验证应用限制 -- [[API-Enablement]]：启用 API 的操作 - -## Related Entities -- [[Google]]：API 提供方 -- [[gog CLI]]：使用 Gmail API 的命令行工具 diff --git a/wiki/concepts/Go-to-Market-Brief.md b/wiki/concepts/Go-to-Market-Brief.md deleted file mode 100644 index 7a4fd096..00000000 --- a/wiki/concepts/Go-to-Market-Brief.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: "Go-to-Market Brief" -type: concept -tags: [product-management, launch, gtm] -sources: [product-manager.md] -last_updated: 2026-04-20 ---- - -## Definition -GTM Brief 是发布前编写的跨职能协调文档，定义目标受众、价值主张、发布清单、成功标准和回滚预案。 - -## Structure -1. **What We're Launching**：一段话描述产品、解决的问题、为什么现在重要 -2. **Target Audience**：细分市场、大小、为什么他们关心、通过什么渠道触达 -3. **Core Value Proposition**：单行公式 + 按受众分组的 messaging -4. **Launch Checklist**：Engineering、Product、Marketing、Sales/CS 分项清单 -5. **Success Criteria**：按时间框架的指标、目标、负责人 -6. **Rollback & Contingency**：回滚触发条件、负责人、沟通计划 - -## Launch Tiers -| Tier | Description | -|------|-------------| -| 1 (Major) | 重大发布，公司范围可见 | -| 2 (Standard) | 标准发布 | -| 3 (Silent) | 静默发布，无需营销支持 | - -## Success Criteria Timeline -- Launch day：错误率 < 0.5% -- 7 days：功能激活率 ≥ 20% -- 30 days：功能用户 vs 对照组留存 +8pp -- 60 days：相关主题支持票据 −30% -- 90 days：功能用户 NPS +5 points - -## Key Principle -- 确认 Support 和 CS 在 GA 前接受培训——不是发布当天 -- 翻转 flag 前写好回滚 runbook -- GA 后 48 小时内发送发布总结给全公司 - -## Connection -- [[Product Manager Agent]] ← coordinates ← [[Go-to-Market Brief]] -- [[Launch Phase]] ← executes ← [[Go-to-Market Brief]] -- [[Sprint Health Snapshot]] ← monitors ← [[Go-to-Market Brief]] diff --git a/wiki/concepts/Google-Cloud-Adoption-Framework.md b/wiki/concepts/Google-Cloud-Adoption-Framework.md deleted file mode 100644 index 049bbaaf..00000000 --- a/wiki/concepts/Google-Cloud-Adoption-Framework.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: "Google Cloud Adoption Framework" -type: concept -tags: [Cloud, Framework, Google] -sources: [Cloud-Maturity-Model-A-Detailed-Guide-For-Cloud-Adoption] -last_updated: 2025-02-28 ---- - -## Summary -Google Cloud Adoption Framework 是一种帮助组织识别关键活动目标的框架，以有效加速向云端的转型。 - -## Definition -Google Cloud Adoption Framework 协助组织确定关键活动，帮助加速云迁移过程。 - -## Key Focus Areas -- 识别关键活动和目标 -- 加速云转型 -- 最佳实践指导 - -## Connections -- [[Google-Cloud-Adoption-Framework]] ← extends ← [[Cloud-Maturity-Model]] diff --git a/wiki/concepts/Government-Procurement.md b/wiki/concepts/Government-Procurement.md deleted file mode 100644 index ccd266c2..00000000 --- a/wiki/concepts/Government-Procurement.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "Government Procurement" -type: concept -tags: [government, procurement, bidding, compliance] -last_updated: 2026-04-20 ---- - -## Definition -Government Procurement 指政府机构围绕预算、招标、评标、合同签署和验收所进行的标准化采购流程。 - -## Core Dimensions -- 资格条件与响应文件审核 -- 技术标、商务标与评分规则 -- 公开招标、竞争性磋商、询价等采购方式 -- 合同、验收、付款与审计闭环 - -## Related Concepts -- [[Technical Discovery]] -- [[Proof of Concept (POC)]] -- [[Solution Architecture (SA)]] -- [[Dengbao]] -- [[Miping]] -- [[Xinchuang]] - -## Related Entities -- [[Government Digital Presales Consultant]] -- [[The Agency]] diff --git a/wiki/concepts/Governor-Limits.md b/wiki/concepts/Governor-Limits.md deleted file mode 100644 index 021f2a07..00000000 --- a/wiki/concepts/Governor-Limits.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: "Governor Limits" -type: concept -tags: [salesforce, performance, limits] -sources: [specialized-salesforce-architect.md] -last_updated: 2026-04-20 ---- - -# Governor Limits - -Salesforce 平台的资源限制约束，是不可妥协的强制性限制。 - -## 核心限制 - -| 限制类型 | 同步限制 | 异步限制 | -|---------|---------|---------| -| SOQL 查询 | 100 | 200 | -| DML 语句 | 150 | 150 | -| CPU 时间 | 10,000ms | 60,000ms | -| 堆大小 | 6MB | 12MB | -| Callouts | 100 | 100 | -| Future 调用 | 50 | 50 | - -## 设计原则 -- 每个设计必须精确计算 Governor Limit 剩余量 -- 绝不假设"以后再优化" -- 批量处理是强制要求 - -## 相关概念 -- [[Bulkification]] — 批量处理机制 -- [[Trigger-Framework]] — 触发器框架 - -## 来源 -[[Salesforce-Architect]] 智能体的强制性规则 diff --git a/wiki/concepts/Grafana.md b/wiki/concepts/Grafana.md deleted file mode 100644 index 4583b177..00000000 --- a/wiki/concepts/Grafana.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: "Grafana" -type: concept -tags: [visualization, monitoring, dashboard, devops] -sources: [家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox] -last_updated: 2026-04-16 ---- - -## Definition -Grafana 是开源的可视化平台，支持多数据源（Prometheus、Elasticsearch、Loki、InfluxDB 等）的仪表盘创建和告警通知。 - -## Key Features -- **多数据源支持**：Prometheus、Elasticsearch、Loki、InfluxDB、MySQL 等 -- **仪表盘模板**：社区共享大量预置仪表盘 -- **告警规则**：支持阈值、条件告警和多通道通知 -- **变量和模板**：支持动态仪表盘 -- **用户和权限**：支持团队和角色管理 - -## Common Dashboard IDs -- Node Exporter Full: `1860` -- cAdvisor Container Metrics: `14282` -- Blackbox Exporter Probe: `7587` - -## Use Cases -- 基础设施监控仪表盘 -- 应用性能监控 -- 日志聚合可视化 -- 业务指标展示 - -## Connections -- [[Grafana]] ← data_source ← [[Prometheus]] -- [[Grafana]] ← data_source ← [[Loki]] -- [[Grafana]] ← core_tool ← [[监控可观测性]] \ No newline at end of file diff --git a/wiki/concepts/Graph-View.md b/wiki/concepts/Graph-View.md deleted file mode 100644 index aa41b4c2..00000000 --- a/wiki/concepts/Graph-View.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: "Graph View" -type: concept -tags: [] ---- - -## 定义 -Obsidian 的知识网络可视化功能（左侧边栏图谱图标，或 `Ctrl+G`），将所有 Wiki 页面以节点展示，双链关系自动连线。 - -## Karpathy 推荐的两个用法 - -### 健康检查 -没有任何页面链接指向它 → 说明是"孤岛页面"，需要让 AI 补上交叉引用。 - -### 发现盲区 -某个概念被很多页面提到但自己还没有独立页面 → 图谱里显示为灰色幽灵节点，提醒应该为它建一个专页。 - -## 核心价值 -- 发现孤立页面 -- 识别知识盲区 -- 建立知识网络 - -## 关联 -- [[Obsidian]] -- [[QMD]] -- [[双链（Backlinks）]] \ No newline at end of file diff --git a/wiki/concepts/Groupthink.md b/wiki/concepts/Groupthink.md deleted file mode 100644 index bef006c2..00000000 --- a/wiki/concepts/Groupthink.md +++ /dev/null @@ -1,60 +0,0 @@ ---- -title: "Groupthink" -type: concept -tags: [social-psychology, group-decision-making, janis] -sources: [] -last_updated: 2026-04-20 ---- - -# Groupthink - -## Aliases -- 群体思维 -- 群体思维模型 -- Groupthink Model - -## Summary -Irving Janis 1972 年提出的群体决策心理现象，描述高度凝聚的决策团队为维护表面一致而压制异议，导致次优甚至灾难性决策的倾向。 - -## Core Symptoms - -### 过度乐观 -- 团队对风险严重低估 -- 集体忽视道德或伦理警告 - -### 集体合理化 -- 质疑和挑战的声音被轻视 -- 对负面反馈的集体忽视 - -### 对外部群体的刻板印象 -- 过度丑化竞争对手或反对者 -- 合理化自身的所有行为 - -### 从众压力 -- 直接反对者受到同伴压力 -- 自我审查：不表达异议 - -### 自我任命守卫 -- 非正式成员阻止不同意见 -- 直接压制不同声音 - -## Prescription Remedies（Janis 建议的干预措施） -1. 领导者在决策前保持中立，鼓励批评性讨论 -2. 设置"魔鬼代言人"角色 -3. 鼓励小团体分别独立讨论后再汇合 -4. 保留外部专家或成员的多样性视角 - -## Historical Examples -- 猪湾入侵（Bay of Pigs）决策 -- 朝鲜战争决策 -- 水门事件掩盖行为 - -## Applications -- [[Academic Psychologist Agent]] 分析群体角色动态 -- 理解组织中的集体决策病理 -- 评估群体情境下的角色行为合理性 - -## Connections -- [[Academic Psychologist Agent]] ← 分析概念 ← [[Groupthink]] -- [[Irving Janis]] ← 提出者 ← [[Groupthink]] -- [[Social Identity Theory]] ← 相关理论 ← [[Groupthink]] diff --git a/wiki/concepts/Gruntwork-Landing-Zone.md b/wiki/concepts/Gruntwork-Landing-Zone.md deleted file mode 100644 index b4e8a5ac..00000000 --- a/wiki/concepts/Gruntwork-Landing-Zone.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "Gruntwork Landing Zone" -type: concept -tags: - - aws - - infrastructure - - landing-zone -sources: [ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs] -last_updated: 2026-04-18 ---- - -## Definition -Gruntwork 提供的预配置 AWS 基础架构框架，分为 R&D Labs 和 SAS 两种环境类型。 - -## Types -- **R&D Labs**：研发实验室环境，统一使用 swinford.net 域名 -- **SAS (Staging and Production)**：分阶段和生产环境，使用 intsas.local 域名 - -## Key Components -- SRE-provided AMIs：内置自动域加入脚本 -- 自助服务工具（如 MIM） -- 支持渠道（如 SMACKS 工单系统） - -## Connections -- [[Gruntwork]] ← provides ← [[Gruntwork-Landing-Zone]] -- [[swinford-net]] ← serves ← [[Gruntwork-Landing-Zone]] -- [[intsas-local]] ← serves ← [[Gruntwork-Landing-Zone]] \ No newline at end of file diff --git a/wiki/concepts/Guest-Confirmation.md b/wiki/concepts/Guest-Confirmation.md deleted file mode 100644 index 4ab616a6..00000000 --- a/wiki/concepts/Guest-Confirmation.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "Guest Confirmation" -type: concept -tags: [workflow, event-management] -aliases: [宾客确认, 活动确认] ---- - -## Definition -活动管理中的宾客确认工作流，指在活动（晚宴、婚礼、公司团建等）前逐一联系宾客，确认其出席状态、特殊需求（如饮食禁忌、+1 加人等）的标准化流程。 - -## Context -传统方式依赖人工逐一致电，效率低且易遗漏。AI Agent 通过自动外呼实现规模化确认。 - -## Workflow -1. 准备宾客名单（姓名 + 电话） -2. 配置事件信息（时间、地点、主题） -3. 设置 AI persona（角色名称、对话目标、开场白） -4. 逐个外呼并记录结果 -5. 汇总生成报告 - -## Related -- [[Event Guest Confirmation]] -- [[Voice Agent]] -- [[SuperCall]] \ No newline at end of file diff --git a/wiki/concepts/HCX.md b/wiki/concepts/HCX.md deleted file mode 100644 index 8dc00cec..00000000 --- a/wiki/concepts/HCX.md +++ /dev/null @@ -1,14 +0,0 @@ ---- -title: "HCX (Hybrid Cloud Extender)" -type: concept -tags: [VMware, Migration, Hybrid-Cloud] ---- - -## Description -VMware 提供的混合云扩展工具，实现 on-premises vSphere 和 SDDC 的双向可视化管理，支持每次迁移最多 200 台 VM。 - -## Type -- 产品/工具 - -## Related -- 用于 [[VMware-Cloud-on-AWS]] 的多云管理 \ No newline at end of file diff --git a/wiki/concepts/HIPO.md b/wiki/concepts/HIPO.md deleted file mode 100644 index 6e802d4c..00000000 --- a/wiki/concepts/HIPO.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "HIPO 计划" -type: concept -tags: [talent-development, leadership] -sources: [] -last_updated: 2026-04-20 ---- - -## Definition -High-Potential Talent Program，高潜力人才发展计划。 - -## Identification Criteria -绩效 × 潜力矩阵： -- 高绩效 × 高潜力 = 核心人才，重点培养 -- 高绩效 × 低潜力 = 业务骨干 -- 低绩效 × 高潜力 = 待观察，需要指导 - -## Development Components -- IDP（个人发展计划） -- 岗位轮换 -- 导师辅导 -- 挑战性任务 - -## Related Concepts -- [[行动学习]]：发展领导力的方法 diff --git a/wiki/concepts/HPA.md b/wiki/concepts/HPA.md deleted file mode 100644 index d853d905..00000000 --- a/wiki/concepts/HPA.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: "HPA" -type: concept -tags: [Kubernetes, EKS, Auto-Scaling] ---- - -## Description -HPA（Horizontal Pod Autoscaler）是 Kubernetes 的水平 Pod 自动扩缩容功能，根据 CPU、内存或自定义指标自动调整 Pod 副本数。 - -## Related Concepts -- [[VPA]] -- [[EKS 可靠性]] -- [[KEDA]] -- [[Auto-scaling]] - -## Related Entities -- [[EKS]] -- [[Kubernetes]] - -## Connections -- [[HPA]] ← 实现 [[EKS 可靠性]] \ No newline at end of file diff --git a/wiki/concepts/HandleLidSwitch.md b/wiki/concepts/HandleLidSwitch.md deleted file mode 100644 index 1943019d..00000000 --- a/wiki/concepts/HandleLidSwitch.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: "HandleLidSwitch" -type: concept -tags: [systemd, power-management] -date: 2026-04-17 ---- - -## Definition -systemd-logind 的电源管理配置项，用于控制笔记本合盖时的系统行为。 - -## Configuration Options -- `ignore`：不执行任何操作，系统继续运行 -- `suspend`：进入待机状态 -- `hibernate`：进入休眠状态 -- `poweroff`：关机 -- `lock`：锁定屏幕 - -## Related Config Items -- `HandleLidSwitch`：合盖时的动作（电池模式下） -- `HandleLidSwitchExternalPower`：连接外接电源合盖时的动作 -- `HandleLidSwitchDocked`：连接扩展坞合盖时的动作 - -## Use Cases -- 服务器场景：设置 ignore 防止合盖后系统休眠 -- 笔记本场景：合盖自动锁定或待机 - -## Connections -- controlled_by → [[systemd-logind]] \ No newline at end of file diff --git a/wiki/concepts/HealthSupplementMarketing.md b/wiki/concepts/HealthSupplementMarketing.md deleted file mode 100644 index d8a1426a..00000000 --- a/wiki/concepts/HealthSupplementMarketing.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: "Health Supplement Marketing" -type: concept -tags: [health-supplement, marketing, compliance, china] -last_updated: 2026-04-20 ---- - -## Definition -Health Supplement Marketing is the promotion of baojian shipin within registered/filed functional claims and without crossing into disease-treatment language. - -## Core Principles -- Health supplements are not drugs -- Do not claim cure, treatment, or replacement of medication -- Stay within approved function claims and standard wording -- Display required marks and disclaimers when applicable - -## Related Concepts -- [[HealthcareMarketingCompliance]] -- [[MedicalAdvertisingCompliance]] -- [[PatientPrivacyProtection]] diff --git a/wiki/concepts/HealthcareMarketingCompliance.md b/wiki/concepts/HealthcareMarketingCompliance.md deleted file mode 100644 index 0b6f9931..00000000 --- a/wiki/concepts/HealthcareMarketingCompliance.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "Healthcare Marketing Compliance" -type: concept -tags: [healthcare, compliance, marketing, china] -last_updated: 2026-04-20 ---- - -## Definition -Healthcare Marketing Compliance is the umbrella discipline of making healthcare promotion, content, and commercialization lawful, evidence-based, and platform-safe. - -## Core Principles -- Prior review beats post-publication cleanup -- Approved scope matters more than creative wording -- Consent and de-identification are required for patient data reuse -- Platform rules can be stricter than the statute itself - -## Related Entities -- [[Healthcare Marketing Compliance Specialist]] -- [[The Agency]] - -## Related Concepts -- [[MedicalAdvertisingCompliance]] -- [[HealthSupplementMarketing]] -- [[InternetHealthcareCompliance]] -- [[MedicalAestheticsCompliance]] -- [[PatientPrivacyProtection]] -- [[AcademicDetailingCompliance]] diff --git a/wiki/concepts/High-Availability.md b/wiki/concepts/High-Availability.md deleted file mode 100644 index fbd79aa6..00000000 --- a/wiki/concepts/High-Availability.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: High Availability -type: concept -tags: [Cloud, Reliability, Infrastructure] -sources: [The-Myths-and-Misconceptions-About-Cloud-Computing-LinkedIn.md] -last_updated: 2025-03-02 ---- - -## Definition -高可用性（High Availability）是指通过冗余设计、自动故障转移和分布式基础设施确保系统在任意时刻均可访问的设计原则。 - -## Core Mechanisms -- 冗余基础设施（Redundant Infrastructure）：关键组件多点部署 -- 自动故障转移（Automated Failover）：故障时自动切换到备用系统 -- 全球数据中心分布（Global Data Center Distribution）：跨地域部署 -- SLA 保障：服务级别协议保证 uptime 通常超过 99.99% - -## Key Claims -- 主要云提供商提供保证 uptime 超过 99.99% 的 SLA -- 冗余基础设施、自动故障转移和全球数据中心分布增强了可靠性 -- 云解决方案具有高度弹性 - -## Connections -- [[Cloud-Native]] ← requires ← [[High-Availability]]：云原生应用依赖高可用性 -- [[Multi-Cloud]] ← enables ← [[High-Availability]]：多云部署增强高可用性 -- [[混沌工程]] ← tests ← [[High-Availability]]：混沌工程主动测试系统韧性 diff --git a/wiki/concepts/Historical-Coherence-Check.md b/wiki/concepts/Historical-Coherence-Check.md deleted file mode 100644 index 6ef145cc..00000000 --- a/wiki/concepts/Historical-Coherence-Check.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: "Historical Coherence Check" -type: concept -tags: [history, worldbuilding, validation] -last_updated: 2026-04-20 ---- - -## Definition -历史一致性检查是 Academic Historian 提供的简洁验证框架，用于评估单个历史声明的准确性。 - -## Check Structure -``` -COHERENCE CHECK -=============== -Claim: [Statement being evaluated] -Verdict: [Accurate / Partially accurate / Anachronistic / Myth] -Evidence: [Source and reasoning] -Confidence: [High / Medium / Low — and why] -If fictional/inspired: [What historical parallels exist, what diverges] -``` - -## Verdict Categories -- **Accurate**：有充分史料支撑的声明 -- **Partially accurate**：主体正确但细节有误 -- **Anachronistic**：时代错误，包括明显错误和微妙错误 -- **Myth**：流行但不符合史实的说法 - -## Confidence Levels -- **High**: 有主要史料或学术共识支撑 -- **Medium**: 学术存在争议或史料有限 -- **Low**: 推测性或仅基于次级研究 - -## 与 Period Authenticity Report 的区别 -| 维度 | Period Authenticity Report | Historical Coherence Check | -|------|---------------------------|---------------------------| -| 范围 | 全方位验证 | 单一声明评估 | -| 复杂度 | 完整报告 | 简洁框架 | -| 用途 | 设置验证 | 声明核实 | - -## Related Concepts -- [[Period Authenticity Report]]：完整的时期验证报告 -- [[Anachronism]]：需要被检测的时代错误 -- [[Material Culture]]：验证物质细节的基础 - -## Source -Academic Historian Agent — The Agency 项目 diff --git a/wiki/concepts/Hub-and-Spoke.md b/wiki/concepts/Hub-and-Spoke.md deleted file mode 100644 index 57124ea5..00000000 --- a/wiki/concepts/Hub-and-Spoke.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: "Hub-and-Spoke" -type: concept -tags: - - networking - - topology ---- - -## Aliases -- Hub-and-Spoke -- 星型拓扑 -- Hub and Spoke - -## Description -一种网络拓扑结构，所有分支（Spoke）连接到中心节点（Hub），分支间的通信通常经过 Hub 中转。在 AWS 云网络架构中，Transit Gateway 充当 Hub，VPC 和 Landing Zones 作为 Spoke，实现集中化的网络管理。 - -## Use Cases -- AWS Transit Gateway 连接多个 VPC -- 企业广域网架构 -- 跨区域网络互联 - -## Related Concepts -- [[Transit Gateway]] -- [[SD-WAN]] -- [[Overlay Network]] - -## Related Entities -- [[AWS]] - -## Sources -- [[ctp-topic-18-wide-area-networking-in-aws-cloud]] - -## Related Sources -- [[ctp-topic-14-octane-hub-on-aws-real-life-experience]] \ No newline at end of file diff --git a/wiki/concepts/Hybrid-Cloud.md b/wiki/concepts/Hybrid-Cloud.md deleted file mode 100644 index 80188d18..00000000 --- a/wiki/concepts/Hybrid-Cloud.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: "Hybrid Cloud" -type: concept -tags: [Cloud, Deployment-Model] -sources: [Cloud-Maturity-Model-A-Detailed-Guide-For-Cloud-Adoption, Public-vs-Private-vs-Hybrid-Cloud-Differences-Explained] -last_updated: 2025-06-18 ---- - -## Summary -Hybrid Cloud（混合云）是一种组合使用公有云和私有云的云计算部署模式。 - -## Definition -混合云将公有云的可扩展性与私有云的安全性和控制性相结合，允许工作负载在两种环境之间灵活移动。典型用例包括：使用私有云处理敏感工作负载，使用公有云应对流量峰值，以及实现业务连续性和灾难恢复。 - -## Key Characteristics -- 结合公有云弹性和私有云安全性 -- 支持 policy-driven deployment（策略驱动部署） -- 可实现跨混合环境的工作负载优化 -- 支持同构（单一供应商）或异构（多供应商）架构 - -## Advantages -- 灵活性：根据安全、性能、成本需求分配工作负载 -- 扩展性：无需高额资本支出即可获得额外计算能力 -- 可靠性：分布式架构提升系统韧性 -- 成本效率：敏感工作负载在私有云，普通负载在公有云 - -## Limitations -- 复杂的成本管理 -- 跨云集成挑战 -- 额外的架构复杂性 -- 数据传输安全风险 - -## Connections -- [[Hybrid-Cloud]] ← type_of ← [[Cloud-Adoption]] -- [[Hybrid-Cloud]] ← combines ← [[Public-Cloud]] -- [[Hybrid-Cloud]] ← combines ← [[Private-Cloud]] - diff --git a/wiki/concepts/Hybrid-DNS-Resolution.md b/wiki/concepts/Hybrid-DNS-Resolution.md deleted file mode 100644 index 9757c512..00000000 --- a/wiki/concepts/Hybrid-DNS-Resolution.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: "Hybrid DNS Resolution" -type: concept -tags: - - DNS - - Networking - - Hybrid Cloud ---- - -## Definition -混合云 DNS 解析（Hybrid DNS Resolution）指通过配置转发规则，使云端资源能解析本地域名，同时本地资源也能解析云端域名的机制。 - -## Architecture Components - -### AWS Side -- [[Route-53-Private-Hosted-Zone]] -- [[Route-53-Resolver-Endpoint]]（入站/出站） -- IAM 角色和策略控制 - -### On-Premise Side -- Active Directory 托管 DNS -- DNS 转发器 - -## Key Capabilities -- **跨区域弹性**：在出站规则中配置多个区域的 AD 域控制器 IP，确保故障转移 -- **就近解析**：优化 Office 365 等全球化服务的访问性能 -- **安全防护**：防 DNS 隧道攻击、数据外泄、缓存污染 - -## Workflow -1. VPC 内的资源发起 DNS 查询 -2. Route 53 Resolver 检查是否有匹配的转发规则 -3. 如果有，通过 Outbound Endpoint 转发到本地 AD 域控制器 -4. 本地 DNS 返回解析结果 - -## Connections -- [[Route-53-Resolver-Endpoint]] ← implements ← [[Hybrid-DNS-Resolution]] -- [[Active-Directory]] ← provides ← 域控制器 ← [[Hybrid-DNS-Resolution]] \ No newline at end of file diff --git a/wiki/concepts/Hyperautomation.md b/wiki/concepts/Hyperautomation.md deleted file mode 100644 index c9f21821..00000000 --- a/wiki/concepts/Hyperautomation.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: "Hyperautomation" -type: concept -tags: [Automation, DevOps, ITSM] -sources: [modern-itsm-driving-efficiency-security-resilience] -last_updated: 2026-04-16 ---- - -## Summary -Hyperautomation（超级自动化）是结合 AI、ML 和多种自动化工具实现端到端流程自动化的方法论。 - -## Definition -Hyperautomation 是 Gartner 提出的技术趋势，融合机器人流程自动化（RPA）、AI、ML 和低代码平台，实现复杂业务流程的端到端自动化。与传统自动化不同，Hyperautomation 可处理非结构化数据和做出智能决策。 - -## Key Attributes -- **核心组件**：RPA、AI、ML、低代码/无代码平台、流程挖掘 -- **应用场景**：ITSM 流程自动化、业务流程优化、决策自动化 -- **与 ITSM 结合**：实现自学习、预测性和自主 IT 运营 - -## Connections -- [[ITSM]] ← 演进 ← [[Hyperautomation]] -- [[AIOps]] ← 集成 ← [[Hyperautomation]] \ No newline at end of file diff --git a/wiki/concepts/Hypothesis-Testing.md b/wiki/concepts/Hypothesis-Testing.md deleted file mode 100644 index a589ee0b..00000000 --- a/wiki/concepts/Hypothesis-Testing.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "Hypothesis Testing" -type: concept -tags: [statistics, experimentation] -sources: [project-management-experiment-tracker] -last_updated: 2026-04-20 ---- - -## Definition -Hypothesis Testing is a statistical framework for evaluating whether observed data provides enough evidence to reject a null hypothesis in favor of a treatment effect. - -## Core Principles -- State null and alternative hypotheses clearly -- Choose an appropriate test for the data type -- Set the decision threshold before the experiment starts -- Interpret p-values alongside practical significance - -## Related Concepts -- [[Statistical Significance]] -- [[Power Analysis]] -- [[A/B Testing]] - -## Related Entities -- [[Experiment Tracker]] - diff --git a/wiki/concepts/IAM-用户.md b/wiki/concepts/IAM-用户.md deleted file mode 100644 index 0a68f104..00000000 --- a/wiki/concepts/IAM-用户.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: "IAM 用户" -type: concept -tags: [AWS, IAM, Identity] -date: 2026-04-19 ---- - -## Definition -IAM 用户是 AWS IAM 中的持久化身份，代表使用 AWS 资源的人员或应用程序。 - -## Characteristics -- 长期凭证（Access Key + Secret Key） -- 可直接附加策略 -- 适用于服务账号而非人员 - -## Use Cases -- 服务间通信的凭证 -- CI/CD 管道的访问凭证 - -## Best Practice -- 优先使用联合访问替代 IAM 用户进行人员认证 -- IAM 用户仅用于非人员实体（服务账号） - -## Related Concepts -- [[IAM-角色]]: 临时凭证，适用于人员和服务的短期访问 -- [[IAM-策略]]: 定义 IAM 用户可执行的操作 -- [[联合访问]]: 优先使用的人员访问方式 - -## Connections -- [[IAM-用户]] ← uses ← [[IAM-策略]] -- [[IAM-用户]] ← alternative_to ← [[联合访问]] \ No newline at end of file diff --git a/wiki/concepts/IAM-策略.md b/wiki/concepts/IAM-策略.md deleted file mode 100644 index 4af6c8be..00000000 --- a/wiki/concepts/IAM-策略.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: "IAM 策略" -type: concept -tags: [AWS, IAM, Security, Policy] -date: 2026-04-19 ---- - -## Definition -IAM 策略是定义 AWS 权限的 JSON 文档，指定允许或拒绝的操作和资源。 - -## Core Concept -> "We only want to allow the access that is strictly required." - -最小权限原则是 IAM 策略设计的核心指导原则。 - -## Types -- **AWS 托管策略**：AWS 预定义的策略，可重用 -- **客户托管策略**：用户创建和维护的策略，可重用 -- **内联策略**：直接嵌入 IAM 角色或用户，不可重用 - -## Best Practices -- 使用内联策略进行角色特定的权限 -- 使用托管策略进行跨角色可重用的权限 -- 策略应细粒度，限制访问特定资源而非广泛开放 - -## JSON Structure -```json -{ - "Version": "2012-10-17", - "Statement": [{ - "Effect": "Allow|Deny", - "Action": ["s3:GetObject", "s3:ListBucket"], - "Resource": "arn:aws:s3:::bucket-name/*" - }] -} -``` - -## Related Concepts -- [[IAM-角色]]: 策略附加的目标 -- [[内联策略]]: 绑定到特定角色 -- [[托管策略]]: 可跨角色重用 -- [[最小权限原则]]: 策略设计原则 - -## Connections -- [[IAM-策略]] ← attached_to ← [[IAM-角色]] \ No newline at end of file diff --git a/wiki/concepts/IAM-角色.md b/wiki/concepts/IAM-角色.md deleted file mode 100644 index 1b65d231..00000000 --- a/wiki/concepts/IAM-角色.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "IAM 角色" -type: concept -tags: [AWS, IAM, Identity] -date: 2026-04-19 ---- - -## Definition -IAM 角色是 AWS IAM 中的身份，可以被其他实体 assum 以获取临时安全凭证。 - -## Core Concept -> "Roles don't enable actions; they tie together who can do something and what they can do." - -角色本身不执行操作，而是将"谁可以做什么"关联在一起。 - -## Characteristics -- 临时凭证（通过 AssumeRole API 获取） -- 可被服务（AWS Service Role）或用户 assum -- 包含信任策略和权限策略 -- 无持久化登录凭证 - -## Use Cases -- 授予服务访问 AWS 资源的权限（如 EC2 实例角色） -- 授予用户跨账号访问权限 -- 联合访问映射（AD 组 → IAM 角色 → 权限） - -## Types -- **服务角色**：供 AWS 服务使用 -- **跨账号角色**：跨 AWS 账号授权 -- **联合角色**：外部身份提供商映射的角色 - -## Related Concepts -- [[IAM-策略]]: 定义角色可执行的操作 -- [[信任策略]]: 定义谁可以 assum 角色 -- [[联合访问]]: AD 组映射到 IAM 角色的工作流 -- [[最小权限原则]]: 策略设计原则 - -## Connections -- [[IAM-角色]] ← contains ← [[IAM-策略]] -- [[IAM-角色]] ← defined_by ← [[信任策略]] \ No newline at end of file diff --git a/wiki/concepts/IAST.md b/wiki/concepts/IAST.md deleted file mode 100644 index 66312a20..00000000 --- a/wiki/concepts/IAST.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: "IAST（交互式应用安全测试）" -type: concept -tags: [安全, 测试, 运行时] -sources: [what-is-devsecops-best-practices-benefits-and-tools] -last_updated: 2026-04-16 ---- - -## Definition -IAST（Interactive Application Security Testing）在应用程序运行时动态分析行为，检测运行时刻的安全问题，可发现 SAST 和 DAST 可能遗漏的漏洞。 - -## Characteristics -- 在测试和部署阶段使用 -- 通过插桩技术监控应用行为 -- 实时检测运行时漏洞 -- 适合测试环境 - -## Connections -- [[DevSecOps]] ← uses ← [[IAST]] -- [[SAST]] ← complements ← [[IAST]] -- [[DAST]] ← complements ← [[IAST]] \ No newline at end of file diff --git a/wiki/concepts/ICP-备案.md b/wiki/concepts/ICP-备案.md deleted file mode 100644 index fe66dfad..00000000 --- a/wiki/concepts/ICP-备案.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "ICP 备案" -type: concept -tags: [china, compliance, regulations] -last_updated: 2026-04-21 ---- - -## Definition -ICP 备案（Internet Content Provider Registration）是中国大陆互联网监管要求，所有在中国大陆提供互联网信息服务的网站必须向工业和信息化部（MIIT）提交申请并获得备案号。备案号通常以字母+数字格式呈现，如 `京ICP备XXXXXXX号`。 - -## Key Claims -- 无有效 ICP 备案的网站将被百度严厉惩罚或排除在搜索结果外 -- ICP 备案是中国市场网站合法运营的先决条件 -- 备案流程通常需要 4-20 个工作日 -- 百度站长平台要求验证网站备案信息 - -## Relevance to Baidu SEO -- ICP 备案是百度衡量网站可信度的重要信号之一 -- 备案信息与网站实际运营主体必须一致 -- 百度可能将无备案或备案信息异常的网站降权 - -## Related Concepts -- [[百度生态系统]] -- [[移动端优先索引]] -- [[Baiduspider]] \ No newline at end of file diff --git a/wiki/concepts/ICP-定义.md b/wiki/concepts/ICP-定义.md deleted file mode 100644 index 5329c0fb..00000000 --- a/wiki/concepts/ICP-定义.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "ICP 定义" -type: concept -tags: [sales, outbound, icp] ---- - -## 定义 -ICP（Ideal Customer Profile，理想客户画像）是用于识别和筛选潜在客户的标准定义，必须具有排他性。 - -## 构建要素 - -### Firmographic Filters（公司特征过滤） -- 行业垂直领域（2-4 个具体行业） -- 收入范围或员工数量区间 -- 地理区域 -- 技术栈要求 - -### Behavioral Qualifiers（行为限定） -- 什么业务事件使他们成为现在买家？ -- 什么痛点使他们无法忽视你的产品？ -- 内部谁最强烈感受到该痛点？ -- 他们当前的变通方案是什么？ - -### Disqualifiers（排除条件） -- 哪些看起来不错但永远不会成交？ -- 哪些行业或细分市场赢率低于 15%？ -- 哪些公司阶段产品尚不成熟或过度？ - -## 关键原则 -- 有效的 ICP 必须能排除公司，否则只是 TAM 幻灯片 -- 必须可验证和可量化 -- 定期根据数据迭代优化 \ No newline at end of file diff --git a/wiki/concepts/IDENTITY.md b/wiki/concepts/IDENTITY.md deleted file mode 100644 index 4b1fc283..00000000 --- a/wiki/concepts/IDENTITY.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: "IDENTITY.md" -type: concept -tags: [OpenClaw, Agent] ---- - -## 定义 -IDENTITY.md 是 OpenClaw workspace 中的 Agent 结构化身份元数据文件，存储 Agent 的基本信息标签。 - -## 职责 -存储关键身份字段： -- **Name**：Agent 名称，影响界面和对话显示 -- **Creature**：Agent 类型定义（AI assistant、ghost、familiar、robot 等） -- **Vibe**：Agent 气质描述（直接、毒舌、靠谱等） -- **Emoji**：Agent 标识符 -- **Avatar**：Agent 头像路径（workspace 相对路径、URL 或 data URI） - -## 与 SOUL.md 的分工 -- IDENTITY.md：结构化的元数据（谁、长什么样、什么感觉） -- SOUL.md：叙事性的性格文档（怎么思考、怎么行事、有什么执念） - -前者是名片，后者是人物小传。 - -## 典型结构 -```markdown -# IDENTITY.md - Who Am I? -- **Name:** Nova -- **Creature:** AI assistant -- **Vibe:** 直接、有点毒舌、但总是靠谱 -- **Emoji:** 🦊 -- **Avatar:** avatars/nova.png -``` - -## 来源 -- [[万字讲透OpenClaw🦞从"能用"到"真好用"的分水岭：Workspace 深度解析]] - -## 相关 -- [[SOUL.md]]：叙事性性格文档 -- [[BOOTSTRAP.md]]：初始化时创建 IDENTITY.md \ No newline at end of file diff --git a/wiki/concepts/IPAM.md b/wiki/concepts/IPAM.md deleted file mode 100644 index 0c7f1015..00000000 --- a/wiki/concepts/IPAM.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: "IPAM" -type: concept -tags: - - Networking - - IP Address ---- - -## Definition -IPAM（IP Address Management，IP 地址管理）是一种用于规划、追踪和管理网络中的 IP 地址空间及 DNS/DHCP 服务的工具或平台。 - -## Key Functions -- IP 地址分配和追踪 -- DNS 记录管理 -- DHCP 服务配置 -- 地址空间规划 -- 合规性审计 - -## Common Tools -- **Infoblox**：企业级 IPAM 解决方案，提供 NIOS 操作系统和 Infoblox Grid 架构 -- **phpIPAM**：开源 IPAM 工具 -- **GestióIP**：另一款开源 IPAM 工具 - -## Use Cases -- 企业内网 IP 管理 -- DNS/DHCP 服务统一管理 -- 云环境与本地环境的 IP 地址协调 - -## Connections -- [[Infoblox]] ← provides ← IPAM -- [[Landing-Zone]] ← uses ← IPAM \ No newline at end of file diff --git a/wiki/concepts/IPv6-Networking.md b/wiki/concepts/IPv6-Networking.md deleted file mode 100644 index 95a9b3e1..00000000 --- a/wiki/concepts/IPv6-Networking.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "IPv6 Networking" -type: concept -tags: [Networking, VPC, AWS, IP-Address] ---- - -## Description -IPv6 Networking（IPv6 网络）是解决 VPC IP 地址耗尽的方案。通过双栈 VPC，节点支持 IPv4+IPv6 双协议栈，Pod 仅使用 IPv6 地址。IPv6 Pod 与 IPv4 目标交互需要在两层进行 NAT 转换。 - -## AWS Implementation -- 使用双栈 VPC -- 节点支持双栈 IP 地址 -- Pod 仅分配 IPv6 地址 -- 通过 NAT 解决 IPv6 与 IPv4 互操作 - -## Use Cases -- 解决大规模 Kubernetes 集群的 IP 耗尽问题 -- 支持更多 Pod 和服务 -- VPC 网络扩展 - -## Related Concepts -- [[VPC]] -- [[EKS]] - -## Related Entities -- [[AWS]] - -## Connections -- [[IPv6 Networking]] ← resolves [[IP Exhaustion]] -- [[IPv6 Networking]] ← extends [[VPC]] \ No newline at end of file diff --git a/wiki/concepts/IP纯净度.md b/wiki/concepts/IP纯净度.md deleted file mode 100644 index 8735e63f..00000000 --- a/wiki/concepts/IP纯净度.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: IP纯净度 -type: concept -tags: [IP, 网络安全, 风险评估] ---- - -## Definition -IP 纯净度（IP Reputation / IP Cleanliness）是评定某个 IP 地址是否安全可靠的风险等级指标。纯净度高的 IP（低风险）代表该 IP 具有良好的信誉，较少被用于垃圾邮件、恶意行为或被平台标记；纯净度低的 IP（高风险）可能被封禁或导致账号被关联。 - -## Evaluation Criteria -- **低风险（推荐）**：IP 信誉良好，未被标记，可安全使用 -- **中等风险（不推荐）**：存在一定风险，可能被平台关注 -- **高风险（禁用）**：IP 已被标记或污染，使用会导致封号 - -## Detection Methods -通过多个 IP 检测网站交叉验证： -- 国内 IP 检测点 -- 国外 IP 检测点 -- 谷歌 IP 检测点 -三处必须高度一致，否则可能被判定为代理异常 - -## Common Tools -- ip111.cn -- ipinfo.io -- scamalytics.com -- whatismyipaddress.com - -## Importance -- **账号安全**：低纯净度 IP 是导致账号被封的主要因素之一 -- **一致性**：代理 IP 在不同检测网站的结果必须一致 -- **稳定性**：建议使用静态住宅 IP，避免频繁切换 - -## Related Entities -- [[SOCKS5代理]] - -## Related Concepts -- [[代理配置]] -- [[静态IP]] -- [[住宅IP]] \ No newline at end of file diff --git a/wiki/concepts/ITIL-Framework.md b/wiki/concepts/ITIL-Framework.md deleted file mode 100644 index da3b2150..00000000 --- a/wiki/concepts/ITIL-Framework.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: "ITIL Framework" -type: concept -tags: [ITSM, Service-Management] ---- - -## Definition -ITIL（Information Technology Infrastructure Library）是一个广泛使用的 IT 服务管理框架，将业务流程分为五个核心阶段：服务战略（Service Strategy）、服务设计（Service Design）、服务转换（Service Transition）、服务运营（Service Operation）和持续改进（Continual Improvement）。 - -## Context -在 Oli 工作流流程中，ITIL 框架提供了需求管理的理论支撑。审批流程是请求处理的第一阶段，之后是需求管理和定义工作。云资源请求的完整端到端流程包括：审批阶段、需求管理和定义工作。 - -## Key Points -- 审批流程是请求处理的第一阶段 -- 服务目录正在开发中，将合并云产品的标准化清单 -- 目标是简化业务部门从目录中识别和请求服务的过程 - -## Related Concepts -- [[Demand Management]] -- [[Service Catalog]] -- [[Workflow Process]] \ No newline at end of file diff --git a/wiki/concepts/ITSM.md b/wiki/concepts/ITSM.md deleted file mode 100644 index 0e679c2d..00000000 --- a/wiki/concepts/ITSM.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: "ITSM" -type: concept -tags: [IT, Service Management, DevOps] -sources: [modern-itsm-driving-efficiency-security-resilience] -last_updated: 2026-04-16 ---- - -## Summary -ITSM（IT 服务管理）是管理 IT 服务交付和支持的框架，从传统工单系统演变为战略推动者。 - -## Definition -IT Service Management（IT 服务管理）是确保 IT 服务以满足业务需求的方式交付和支持的实践和方法论。现代 ITSM 融合 AIOps、Hyperautomation 和零信任架构，演变为 ITSM 2.0。 - -## Key Attributes -- **核心领域**：Problem Management、Incident Management、Change Management、Release Management、Configuration Management、Asset Management、Security & Compliance、DR/BC -- **技术演进**：AIOps、Hyperautomation、自愈 IT 生态 -- **业务价值**：运营卓越、风险缓解、创新加速 - -## Connections -- [[DevOps]] → 集成 → [[ITSM]] -- [[AIOps]] → 驱动 → [[ITSM]] -- [[Zero Trust Architecture]] → 保护 → [[ITSM]] \ No newline at end of file diff --git a/wiki/concepts/IaC.md b/wiki/concepts/IaC.md deleted file mode 100644 index 1575a3d8..00000000 --- a/wiki/concepts/IaC.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "IaC" -type: concept -tags: [devops, infrastructure, automation] -sources: [cloud-devop-maturity-guideline, DevOps-Culture-and-Transformation] -last_updated: 2026-04-16 ---- - -## Definition -IaC（Infrastructure as Code，基础设施即代码）是一种通过代码和版本控制管理基础设施的方法，替代手动配置和交互式界面操作。 - -## Key Benefits -- **可重复性**：相同配置可多次部署 -- **可版本化**：配置变更可追溯 -- **可测试性**：基础设施变更可自动化测试 -- **一致性**：消除人工配置差异 - -## Key Tools -- [[Terraform]]：声明式 IaC 工具 -- [[Ansible]]：命令式配置管理 -- AWS CloudFormation：（仅在另一源文件中提及） - -## Connections -- [[DevOps 成熟度模型]] ← 技术支柱 ← [[IaC]] -- [[CI/CD 流水线]] ← 依赖 ← [[IaC]] diff --git a/wiki/concepts/IaaS.md b/wiki/concepts/IaaS.md deleted file mode 100644 index bed85192..00000000 --- a/wiki/concepts/IaaS.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: "IaaS (Infrastructure as a Service)" -type: concept -tags: [Cloud, Service-Model] -sources: [Cloud-Maturity-Model-A-Detailed-Guide-For-Cloud-Adoption] -last_updated: 2025-02-28 ---- - -## Summary -IaaS（基础设施即服务）是云计算三大服务模型之一，提供虚拟化的计算资源。 - -## Definition -IaaS 通过互联网提供虚拟化的计算资源，包括服务器、存储和网络设备。 - -## Example Providers -- Amazon Web Services (AWS) EC2 -- Microsoft Azure Virtual Machines -- Google Compute Engine - -## Connections -- [[IaaS]] ← part_of ← [[Cloud-Maturity-Model]] -- [[IaaS]] ← type_of ← [[Cloud-Service-Models]] diff --git a/wiki/concepts/Idempotent-Operation.md b/wiki/concepts/Idempotent-Operation.md deleted file mode 100644 index 557f33ad..00000000 --- a/wiki/concepts/Idempotent-Operation.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: "Idempotent Operation" -type: concept -tags: [DevOps, GitOps, 基础概念] -sources: [ctp-topic-33-an-introduction-to-gitops.md] -last_updated: 2026-04-19 ---- - -## Definition -Idempotent Operation（幂等操作）是指可以多次执行而不会改变超出初始应用结果的操作。无论执行多少次，最终状态都与执行一次相同。 - -## Examples -- Kubernetes 部署：多次 apply 相同配置不会导致重复创建 -- Terraform apply：重复执行会产生相同的基础设施状态 -- 文件权限设置：重复 chmod 相同权限 -- 数据库 UPSERT：重复插入或更新 - -## Non-Idempotent Examples -- `curl` 请求：每次执行都会创建新资源 -- 计数器递增：每次执行都会改变值 -- 文件追加：重复执行会累积内容 - -## Importance in GitOps -- 确保部署过程可重复执行 -- 支持自动重试和恢复 -- 简化故障处理和调试 - -## Related Concepts -- [[GitOps]] -- [[Declarative Configuration]] -- [[Infrastructure as Code (IaC)]] - -## Related Sources -- [[ctp-topic-33-an-introduction-to-gitops]] — GitOps 入门介绍 \ No newline at end of file diff --git a/wiki/concepts/Identity-Governance.md b/wiki/concepts/Identity-Governance.md deleted file mode 100644 index 03211605..00000000 --- a/wiki/concepts/Identity-Governance.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: "Identity Governance" -type: concept -tags: [identity, governance, multi-agent, entity-resolution] -last_updated: 2026-04-20 ---- - -## Definition -Identity Governance 指在多智能体或多系统环境中，对实体身份的解析、归一化、合并、拆分、权限边界与审计进行统一治理的框架。 - -## Core Principles -- 同一实体必须收敛到同一个 canonical identity -- 身份写入必须可审计、可回滚 -- 合并与拆分应优先以提案形式进入复核流程 -- tenant 边界与 PII 脱敏默认启用 -- 代理身份与实体身份应分层治理，避免把 agent authorization 与 entity resolution 混为一谈 -- 身份/授权/证据链验证应 fail-closed - -## Related Entities -- [[Identity Graph Operator]] -- [[Agentic Identity & Trust Architect]] -- [[The Agency]] -- [[AI代理（Agent）]] - -## Related Concepts -- [[Audit Trail]] -- [[Zero Trust Access]] -- [[Multi-Agent-System-Reliability]] -- [[Idempotent Operation]] diff --git a/wiki/concepts/Ikigai.md b/wiki/concepts/Ikigai.md deleted file mode 100644 index 3d7f49e8..00000000 --- a/wiki/concepts/Ikigai.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: "Ikigai" -type: concept -tags: [个人发展, 职业规划] -date: 2026-03-29 ---- - -## Definition -Ikigai（日语"生命意义"）是四个圆的交集，代表： -- 你热爱的 -- 世界所需要的 -- 你能以此获得报酬的 -- 你所擅长的 - -## Finding Process -1. 反思热情和技能——做什么会忘记时间？周末下午会主动学什么？ -2. 分析市场需求——人们经常抱怨什么问题？愿意为什么付费？ -3. 寻找交集——热情和市场的重叠处，就是你的 Ikigai - -## Sources -- [[万字保姆级教程-让你90天跑通一人公司模式-附AI提示词]] \ No newline at end of file diff --git a/wiki/concepts/Immersive-Cockpit.md b/wiki/concepts/Immersive-Cockpit.md deleted file mode 100644 index fa44ec0a..00000000 --- a/wiki/concepts/Immersive-Cockpit.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "Immersive Cockpit" -type: concept -tags: [xr, spatial-computing, ux] -date: 2026-04-20 ---- - -## Definition -沉浸式座舱环境，结合固定视角与高存在感交互区，为 XR 用户提供真实感与舒适性兼具的座舱控制体验。 - -## Core Attributes -- 固定坐姿视角设计，最大化减少方向紊乱 -- 高存在感交互区，操作控件真实可及 -- 真实感与用户舒适性的平衡 - -## Related Concepts -- [[Spatial Controls]]：空间控件的具体实现 -- [[Motion Sickness Threshold]]：眩晕感临界点约束 - -## Related Entities -- [[A-Frame]]：原型化框架 -- [[Three.js]]：3D 渲染引擎 - -## Application -XR 模拟器、车辆驾驶舱、飞船座舱、训练模拟器设计 \ No newline at end of file diff --git a/wiki/concepts/Immutable-Infrastructure.md b/wiki/concepts/Immutable-Infrastructure.md deleted file mode 100644 index c8a5ca5f..00000000 --- a/wiki/concepts/Immutable-Infrastructure.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "Immutable Infrastructure" -type: concept -tags: [devops, security, infrastructure] -sources: [what-is-devsecops-best-practices-benefits-and-tools] -last_updated: 2026-04-20 ---- - -## Definition -不可变基础设施（Immutable Infrastructure）是一种基础设施管理范式，组件在部署后不会发生变化。如果需要更新或修复，会创建新版本并替换旧版本，而不是修改现有组件。 - -## Core Principles -- **不可变性**：部署后不修改现有组件 -- **幂等性**：每次部署产生相同结果 -- **版本化**：每个版本都可追溯和回滚 -- **自动化替换**：通过自动化工具完成组件替换 - -## Benefits -- 降低配置漂移风险 -- 提高环境一致性 -- 简化回滚操作 -- 增强安全性和可预测性 - -## Connections -- [[DevSecOps]] ← enables ← [[Immutable Infrastructure]] -- [[IaC]] ← implements ← [[Immutable Infrastructure]] -- [[容器化]] ← uses ← [[Immutable Infrastructure]] \ No newline at end of file diff --git a/wiki/concepts/Incremental-Updates.md b/wiki/concepts/Incremental-Updates.md deleted file mode 100644 index b733713f..00000000 --- a/wiki/concepts/Incremental-Updates.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "Incremental Updates" -type: concept -tags: [real-time, graph, sync] -last_updated: 2026-04-20 ---- - -## Definition -Incremental Updates（增量更新）是通过文件监视器和版本控制系统钩子实现图谱实时同步的机制，避免全量重建。 - -## Update Triggers -- **文件监视器**：监听文件系统变化（create、modify、delete、rename） -- **Git Hooks**：在 commit、push 时触发增量更新 -- **LSP 通知**：textDocument/didChange 事件 - -## Consistency Requirements -- 原子更新：从不将图谱置于不一致状态 -- 边引用验证：所有边必须指向有效节点 ID -- 文件节点优先：符号节点创建前必须存在父文件节点 - -## Performance Target -- 图谱更新传播到客户端：<500ms -- 内存占用：<500MB（典型项目） - -## Connections -- [[graphd]] ← 实现 ← [[Incremental Updates]] -- [[File Watcher]] ← 触发 ← [[Incremental Updates]] diff --git a/wiki/concepts/Infrastructure-as-Code-IaC.md b/wiki/concepts/Infrastructure-as-Code-IaC.md deleted file mode 100644 index f6ca342a..00000000 --- a/wiki/concepts/Infrastructure-as-Code-IaC.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: "Infrastructure as Code (IaC)" -type: concept -tags: [DevOps, 基础设施, 自动化, 版本控制] -sources: [DevOps-Culture-and-Transformation.md, ctp-topic-33-an-introduction-to-gitops.md] -last_updated: 2026-04-19 ---- - -## Definition -基础设施即代码（IaC）是一种通过代码实现基础设施管理的方法，支持一致性和版本控制的基础设施部署，使环境配置可重复、可审计。 - -## Key Tools（关键工具） -- Terraform -- AWS CloudFormation -- Ansible - -## Related Concepts -- [[DevOps 文化]] -- [[CI/CD 流水线]] -- [[GitOps]] -- [[Declarative Configuration]] -- [[Idempotent Operation]] diff --git a/wiki/concepts/Infrastructure-as-Code.md b/wiki/concepts/Infrastructure-as-Code.md deleted file mode 100644 index 112750ff..00000000 --- a/wiki/concepts/Infrastructure-as-Code.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "Infrastructure as Code (IaC)" -type: concept -tags: [infrastructure, devops, automation] -last_updated: 2026-04-21 ---- - -## Definition -Infrastructure as Code（基础设施即代码）是一种通过代码实现基础设施管理的方法论，替代传统手动配置，实现一致性、版本控制和自动化部署。 - -## Core Principles -- **声明式配置**：定义期望状态而非步骤 -- **版本控制**：所有基础设施变更通过 Git 管理 -- **自动化部署**：通过 CI/CD 流水线实现一键部署 -- **幂等性**：重复执行结果一致 - -## Key Tools -- [[Terraform]]：HashiCorp 开发的跨平台 IaC 工具 -- Terragrunt：Terraform 包装工具，提供模块化和变量共享 -- CloudFormation：AWS 原生 IaC 服务 - -## Related Concepts -- [[CI/CD 流水线]]：自动化测试、集成和部署的持续交付管道 -- [[Infrastructure Maintainer]]：使用 IaC 进行基础设施管理的智能体角色 - -## Application -The Agency 项目中的 [[Support Infrastructure Maintainer]] 使用 Terraform 实现 AWS 基础设施声明式管理，包括 VPC、子网、Auto Scaling Group、RDS 等资源。 \ No newline at end of file diff --git a/wiki/concepts/Init-System.md b/wiki/concepts/Init-System.md deleted file mode 100644 index d6afa07c..00000000 --- a/wiki/concepts/Init-System.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "Init System" -type: concept -tags: [Container, Security, Process] -last_updated: 2026-04-19 ---- - -## 定义 -Init 系统是容器内的初始化进程，用于处理系统信号和回收僵尸进程。常见实现包括 teeny、tini 等。 - -## 为什么需要 Init 系统 -容器默认只运行一个进程（PID 1），当该进程退出时容器终止。但以下情况需要 init 系统： -- 处理孤儿僵尸进程 -- 正确传播 SIGTERM 信号 -- 清理退出的子进程 -- 避免资源耗尽 - -## 工具示例 -- teeny：轻量级 init 系统 -- tini：Docker 官方推荐 -- dumb-init：简单易用 - -## 相关资源 -- 来源：[[CTP Topic 49 Container Lifecycle Hardening Standards]] -- 相关概念：[[Container-Lifecycle-Hardening]] \ No newline at end of file diff --git a/wiki/concepts/Instance-Scheduling.md b/wiki/concepts/Instance-Scheduling.md deleted file mode 100644 index f3bfded5..00000000 --- a/wiki/concepts/Instance-Scheduling.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "Instance Scheduling" -type: concept -tags: - - FinOps - - Cost-Optimization - - Automation -date: 2026-04-19 ---- - -## Aliases -- Instance Scheduler -- EC2 Scheduling -- RDS Scheduling -- 定时启停 - -## Definition -通过预设时间规则自动控制 EC2 和 RDS 实例启停的技术，实现非生产环境成本优化。 - -## Mechanism -- 基于 CloudWatch Events 定时触发 -- Lambda 读取 DynamoDB 配置表中的调度规则 -- 根据实例标签（Schedule、Period）执行启停操作 -- 支持时区配置和自定义工作时间 - -## Use Cases -- 开发/测试环境非工作时间自动关机 -- 按地区办公时间配置调度 -- 强制维护窗口配合（RDS） -- Override 状态强制保持停机 - -## Related Entities -- [[AWS Instance Scheduler]] -- [[CloudWatch Events]] -- [[DynamoDB Config Table]] - -## Related Concepts -- [[Cost Optimization]] -- [[Right Sizing]] -- [[Workload Optimization]] \ No newline at end of file diff --git a/wiki/concepts/Intent-Classification.md b/wiki/concepts/Intent-Classification.md deleted file mode 100644 index 362c18f6..00000000 --- a/wiki/concepts/Intent-Classification.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: "Intent Classification" -type: concept -tags: [Paid Media, Search Advertising, User Behavior] ---- - -## Definition -将搜索查询映射到买家意图阶段的过程，用于确保广告展示给具有相应购买意向的用户。 - -## Intent Stages -- **Informational（信息型）**：用户处于研究阶段，尚未购买意图 -- **Navigational（导航型）**：用户寻找特定品牌或网站 -- **Commercial（商业型）**：用户正在比较选项，准备购买 -- **Transactional（交易型）**：用户准备完成购买或行动 - -## Application -- 匹配查询意图与落地页内容 -- 优化广告系列结构，按意图分层 -- 识别意图不匹配（query 与 landing page 脱节） -- 评估查询-广告-落地页一致性（SQOS 评分） - -## Related Concepts -- [[Search Term Analysis]] -- [[Query Sculpting]] -- [[Match Type Optimization]] - -## Related Entities -- [[Search Query Analyst]] \ No newline at end of file diff --git a/wiki/concepts/InternetHealthcareCompliance.md b/wiki/concepts/InternetHealthcareCompliance.md deleted file mode 100644 index 57e8af7e..00000000 --- a/wiki/concepts/InternetHealthcareCompliance.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: "Internet Healthcare Compliance" -type: concept -tags: [internet-healthcare, telemedicine, compliance, china] -last_updated: 2026-04-20 ---- - -## Definition -Internet Healthcare Compliance covers online diagnosis, treatment, consultation, prescription circulation, and platform operations under Chinese healthcare regulation. - -## Core Principles -- First visits should not be handled as internet diagnosis/treatment -- Physicians must practice within their registered institutional scope -- Pharmacist review is required before electronic dispensing -- Health consultation must not be disguised diagnosis - -## Related Concepts -- [[HealthcareMarketingCompliance]] -- [[PatientPrivacyProtection]] diff --git a/wiki/concepts/Invariant-Verification.md b/wiki/concepts/Invariant-Verification.md deleted file mode 100644 index 4e524570..00000000 --- a/wiki/concepts/Invariant-Verification.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "Invariant Verification" -type: concept -tags: [smart-contract, security, testing] -sources: [blockchain-security-auditor] -last_updated: 2026-04-20 ---- - -## Definition -不变量验证（Invariant Verification）是通过属性驱动测试（Property-Based Testing）验证智能合约关键属性始终成立的方法。 - -## Invariant Examples -- `totalShares × pricePerShare = totalAssets`（资产管理器） -- `pool.balance ≥ sum(userBalances)`（余额不变量） -- `onlyOwner can upgrade`（权限不变量） -- `mint/Burn pair maintains supply`（代币供应不变量） - -## Tools -- **Echidna**：Property-based fuzzing -- **Foundry/Forge**：invariant testing -- **Medusa**：模糊测试 - -## Process -1. 定义协议不变量 -2. 编写 invariant 测试用例 -3. 使用模糊测试生成攻击输入 -4. 验证 invariant 是否被破坏 -5. 迭代修复直至测试通过 - -## Limitations -- 只能测试已想到的不变量 -- 模糊测试覆盖率有限 -- 复杂状态空间难以穷举 -- 需要领域专业知识定义不变量 - -## Connections -- [[Formal Verification]] ← is_formal_version_of ← [[Invariant Verification]] -- [[Echidna]] ← provides ← [[Invariant Verification]] -- [[Smart Contract Testing]] ← includes ← [[Invariant Verification]] - diff --git a/wiki/concepts/Inversion.md b/wiki/concepts/Inversion.md deleted file mode 100644 index 631cf4ff..00000000 --- a/wiki/concepts/Inversion.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -id: inversion -title: "Inversion" -type: concept -tags: [Agent, Skill, 设计模式] -sources: [Google-5-Agent-Skill-design-patterns-2026-03-19] -last_updated: 2026-04-17 ---- - -## Summary -最反直觉的 Agent Skill 设计模式，agent 先问用户再做。 - -## Definition -Inversion 模式把 agent 变成面试官，先问用户一系列问题，等用户回答完再行动。关键在于明确、不可协商的门控指令。 - -## How It Works -1. **门控指令**：明确、不可协商的门控条件（如"不到所有阶段完成就不开始构建"） -2. **逐阶段提问**：agent 逐个阶段提问，等待用户答案 -3. **阶段确认**：只有用户回答完当前阶段所有问题，才进入下一个阶段 -4. **最终行动**：等所有阶段完成后才执行最终行动 - -## Use Cases -- 项目规划：必须等用户回答完所有问题才生成最终计划 -- 需求收集：确保完全理解用户需求后再行动 -- 复杂任务启动：避免因信息不足导致的方向错误 - -## Key Insight -Agent 天生喜欢直接猜测和生成，Inversion 把这个流程完全反过来，通过强制提问确保用户参与每个阶段。 - -## Related Concepts -- [[Agent-Skill-设计模式]] -- [[Generator]]：可在最开始依赖 Inversion 收集必要变量 \ No newline at end of file diff --git a/wiki/concepts/InvestmentAnalysis.md b/wiki/concepts/InvestmentAnalysis.md deleted file mode 100644 index cdde2845..00000000 --- a/wiki/concepts/InvestmentAnalysis.md +++ /dev/null @@ -1,15 +0,0 @@ ---- -title: "Investment Analysis" -type: concept -tags: [finance] -sources: [support-finance-tracker] -last_updated: 2026-04-21 ---- - -定义：用于评估资本项目经济性的量化框架，常用指标包括净现值（NPV）、内部收益率（IRR）、回收期与风险评分，结合敏感性分析与决策规则给出投资建议。 - -## Typical Components -- NPV 计算与折现率设定 -- IRR 估算与收敛性检测 -- 回收期计算 -- 风险评分与投资建议规则 diff --git a/wiki/concepts/Invisible-Exclusion.md b/wiki/concepts/Invisible-Exclusion.md deleted file mode 100644 index 7d850925..00000000 --- a/wiki/concepts/Invisible-Exclusion.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: "Invisible Exclusion" -type: concept -tags: [design, accessibility, localization] -date: 2026-04-20 ---- - -## Definition -Invisible exclusion is hidden friction created when systems assume a narrow user model, such as Western naming patterns, single-calendar usage, or culture-specific symbols. - -## Examples -- First-name / last-name forms that fail for other naming conventions -- Color choices whose meaning changes across regions -- Icons or metaphors that do not translate culturally -- AI outputs that tokenize identity instead of representing it accurately - -## Connections -- [[Cultural Intelligence Strategist]] — detects and removes invisible exclusion -- [[Cultural Intelligence]] — broader discipline for inclusive design -- [[Global-First Architecture]] — one way to prevent exclusion at the system level diff --git a/wiki/concepts/KEDA.md b/wiki/concepts/KEDA.md deleted file mode 100644 index b09dc73c..00000000 --- a/wiki/concepts/KEDA.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "KEDA" -type: concept -tags: [Kubernetes, EKS, Auto-Scaling, Event-Driven] ---- - -## Description -KEDA（Kubernetes Event-driven Autoscaling）是基于外部事件的 Kubernetes 工作负载扩缩容框架。它使用 ScaledObject CRD 定义扩缩容规则，支持从零副本启动，可发布指标供 HPA 使用。 - -## Mechanism -- 使用 ScaledObject 自定义资源定义 -- 支持多种外部事件源（消息队列、HTTP API、Azure Blob 等） -- 可与 HPA 集成提供指标 -- 支持从零副本扩展 - -## Use Cases -- 基于消息队列深度自动扩缩容 -- 基于 HTTP 请求速率扩缩容 -- 事件驱动的工作负载 - -## Related Concepts -- [[HPA]] -- [[Auto-scaling]] - -## Related Entities -- [[EKS]] - -## Connections -- [[KEDA]] ← integrates_with [[HPA]] -- [[KEDA]] ← provides_metrics_for [[Auto-scaling]] \ No newline at end of file diff --git a/wiki/concepts/KOL-Partnership-Pyramid.md b/wiki/concepts/KOL-Partnership-Pyramid.md deleted file mode 100644 index 1f393850..00000000 --- a/wiki/concepts/KOL-Partnership-Pyramid.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: "KOL Partnership Pyramid" -type: concept -tags: [weibo, marketing, kol, influencer] -last_updated: 2026-04-21 ---- - -## Definition -KOL 合作金字塔模型是一种分层 influencer 营销策略，通过顶层、中层、底层 KOL 的协同实现品牌传播的几何级增长。 - -## Three-Tier Structure - -### Top-Tier KOL（顶层） -- **作用**：引爆认知，覆盖海量受众 -- **粉丝量级**：100万+ -- **特点**：强背书、高曝光、适合品牌背书 -- **合作形式**：首发、深度内容、代言 - -### Mid-Tier KOL（中层） -- **作用**：垂直渗透，深度影响细分人群 -- **粉丝量级**：10万-100万 -- **特点**：强互动、高信任、垂直领域权威 -- **合作形式**：产品评测、日常种草、话题参与 - -### Micro-KOC（底层） -- **作用**：草根信任，口碑扩散 -- **粉丝量级**：1万-10万 -- **特点**：真实感强、转化率高、成本可控 -- **合作形式**：真实体验、UGC 共创、口碑扩散 - -## KOL Screening Criteria -- **粉丝质量 > 粉丝数量**：检查活跃粉丝比例、互动真实性 -- **内容调性**：与品牌一致性评估 -- **历史数据**：曝光量、互动率、转化表现 -- **官方验证**：使用微博官方数据工具验证真实影响力 - -## Weibo Task Platform -- 官方 KOL/KOC 合作任务市场 -- 了解定价结构和效果预估 -- 标准化合作流程 - -## Creator Partnership Models -- **Direct Posts**：直接发布 -- **Reshares**：转发扩散 -- **Custom Content**：定制内容 -- **Livestream Co-hosting**：直播联动 -- **Long-term Ambassadorships**：长期代言 - -## Connections -- [[Marketing Weibo Strategist]] → uses → [[KOL Partnership Pyramid]] -- [[Fan Economy Operations]] ← complements ← [[KOL Partnership Pyramid]] \ No newline at end of file diff --git a/wiki/concepts/KPI-Tracking.md b/wiki/concepts/KPI-Tracking.md deleted file mode 100644 index a024918a..00000000 --- a/wiki/concepts/KPI-Tracking.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "KPI Tracking" -type: concept -tags: [] -last_updated: 2026-04-21 ---- - -## Definition -关键绩效指标监控，通过量化指标评估业务目标达成情况。 - -## Dashboard Design Principles -- 针对特定利益相关者需求定制 -- 清晰的分层结构（战略→运营→执行） -- 实时或近实时数据更新 -- 异常自动告警机制 -- 可下钻的钻取能力 - -## Common KPI Categories -- **收入指标**：月收入、ARR、客单价、转化率 -- **客户指标**：NPS、流失率、终身价值 -- **运营指标**：处理时间、错误率、库存周转 -- **营销指标**：CAC、ROI、触点转化率 - -## Related Concepts -- [[Data-Driven Decision Making]] -- [[Predictive Modeling]] - -## Source -- [[support-analytics-reporter]] - diff --git a/wiki/concepts/KPI-卡片.md b/wiki/concepts/KPI-卡片.md deleted file mode 100644 index 64509be5..00000000 --- a/wiki/concepts/KPI-卡片.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: "KPI 卡片" -type: concept -tags: [数据可视化, BI, 指标] ---- - -## Definition -关键绩效指标（Key Performance Indicator）可视化展示组件，以卡片形式直观展示核心业务数据。 - -## Common KPIs for E-commerce -- 总产品数 -- 热卖产品数（sold > X） -- 平均评分 -- 平均最终价格 -- 总 GMV -- 平均折扣比例 -- 好评占比 - -## Use Cases -- Dashboard 首页总览，快速了解业务整体状况 -- 实时监控关键指标变化 -- 目标达成率展示 - -## Related Concepts -- [[Superset-Dashboard]]：KPI 卡片的展示容器 -- [[Apache-Superset]]：BI 平台 \ No newline at end of file diff --git a/wiki/concepts/Kano-Model.md b/wiki/concepts/Kano-Model.md deleted file mode 100644 index f8a76ea1..00000000 --- a/wiki/concepts/Kano-Model.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "Kano Model" -type: concept -tags: [prioritization, product-management, customer-satisfaction] -sources: [raw/Agent/agency-agents/product/product-sprint-prioritizer.md] -last_updated: 2026-04-20 ---- - -## Definition -用户满意度分类模型，通过功能满足程度与用户满意度的非线性关系指导产品决策。 - -## Categories -- **Must-Be（必备型）**：基本需求，缺失导致强烈不满，存在不产生额外满意度 -- **Performance（绩效型）**：线性关系，越多越好 -- **Delighter（兴奋型）**：超出期望的惊喜功能 -- **Indifferent（无关型）**：用户不在意的功能 -- **Reverse（反向型）**：用户不喜欢的功能 - -## Application -指导产品路线图规划，平衡基本功能与创新功能的比例。 - -## Related Concepts -- [[RICE Framework]] -- [[MoSCoW Method]] -- [[Product Sprint Prioritizer]] diff --git a/wiki/concepts/Kano模型.md b/wiki/concepts/Kano模型.md deleted file mode 100644 index c18b571c..00000000 --- a/wiki/concepts/Kano模型.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "Kano模型" -type: concept -tags: [Product Management, Satisfaction Model] -sources: [] -last_updated: 2026-04-20 ---- - -## Definition -Kano模型是一种基于用户满意度二维度的产品质量功能分类模型。 - -## Dimensions -- **线性满意度**：功能越完善，用户越满意 -- **二元满意度**：功能存在则满意，不存在则不满意 - -## Categories -- **必备功能（Must-be）**：理所当然的功能，不满足会强烈不满 -- **一维功能（One-dimensional）**：功能好坏直接对应满意度高低 -- **激励功能（Attractive）**：超出期望的惊喜功能 -- **无关功能（Indifferent）**：用户不在意的功能 -- **反向功能（Reverse）**：用户不需要甚至反感的功能 - -## Usage -Kano模型由 [[Product Feedback Synthesizer]] 用于将用户反馈分类为不同满意度类型的功能。 - -## Connections -- [[Product Feedback Synthesizer]]：使用此模型进行反馈分析 -- [[RICE评分]]：结合使用的优先级框架 -- [[MoSCoW优先级]]：另一种优先级框架 -- [[NPS分析]]：用户忠诚度衡量指标 diff --git a/wiki/concepts/Keyboard-Navigation-Audit.md b/wiki/concepts/Keyboard-Navigation-Audit.md deleted file mode 100644 index c9858da2..00000000 --- a/wiki/concepts/Keyboard-Navigation-Audit.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -title: "Keyboard Navigation Audit" -description: 纯键盘导航测试，验证所有交互元素的可访问性 -tags: [accessibility, testing, keyboard] ---- - -## Definition -Keyboard Navigation Audit 是验证所有交互功能是否可以通过纯键盘（不使用鼠标）完成操作的测试方法。这是无障碍测试的核心环节。 - -## 全局导航检查清单 -- [ ] 所有交互元素可通过 Tab 键到达 -- [ ] Tab 顺序遵循视觉布局逻辑 -- [ ] 存在 Skip Navigation（跳转导航）链接 -- [ ] 无键盘陷阱（始终可以通过 Tab 离开） -- [ ] 每个交互元素的焦点指示器始终可见 -- [ ] Escape 键关闭模态框、下拉菜单和浮层 -- [ ] 关闭模态框/浮层后焦点返回触发元素 - -## 组件特定模式 - -### Tabs -- [ ] Tab 键在 Tab 列表和活动面板内容之间移动 -- [ ] 方向键在 Tab 按钮之间移动 -- [ ] Home/End 键移动到第一个/最后一个 Tab -- [ ] 选中 Tab 通过 aria-selected 指示 - -### Menus -- [ ] 方向键在菜单项之间导航 -- [ ] Enter/Space 激活菜单项 -- [ ] Escape 关闭菜单并将焦点返回触发器 - -### Carousels/Sliders -- [ ] 方向键在幻灯片之间移动 -- [ ] 暂停/停止控制可通过键盘操作 -- [ ] 当前位置被宣布 - -### Data Tables -- [ ] 表头通过 scope 或 headers 属性与单元格关联 -- [ ] Caption 或 aria-label 描述表格用途 -- [ ] 可排序列可通过键盘操作 - -## 结果指标 -- **总交互元素数**： -- **键盘可访问**：（百分比） -- **键盘陷阱数**： -- **缺失焦点指示器数**： - -## Related Concepts -- [[WCAG 2.2]] -- [[Screen Reader Testing]] -- [[POUR Principles]] - -## Source -- [[Accessibility Auditor]] \ No newline at end of file diff --git a/wiki/concepts/Kibana.md b/wiki/concepts/Kibana.md deleted file mode 100644 index 80997953..00000000 --- a/wiki/concepts/Kibana.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: "Kibana" -type: concept -tags: [Log-Analytics, Visualization, Elasticsearch] -date: 2026-04-14 ---- - -## Definition -Kibana 是 ELK Stack 的 Web 前端和可视化界面，用于日志数据的搜索、分析和可视化展示。 - -## Description -Kibana 提供交互式仪表板、时间序列可视化、图形图表等功能，用户可以通过查询语法搜索日志、创建可视化图表、构建仪表板。End users can view logs via Kibana, connecting from a specified network. - -## Usage -- 日志搜索和查询 -- 可视化仪表板构建 -- 告警规则配置 -- 权限管理（配合 RBAC） - -## Connections -- [[Kibana]] ← connects_to ← [[Elasticsearch]] -- [[ELK Stack]] ← depends_on ← [[Kibana]] -- [[Log Analytics]] ← uses ← [[Kibana]] \ No newline at end of file diff --git a/wiki/concepts/Kill-Switch.md b/wiki/concepts/Kill-Switch.md deleted file mode 100644 index af871490..00000000 --- a/wiki/concepts/Kill-Switch.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "Kill Switch" -type: concept -tags: [紧急恢复, 持续交付, 风险管控] -sources: ["https://launchdarkly.com/blog/rto-vs-rpo/"] -last_updated: 2025-07-26 ---- - -## Definition -Kill Switch（紧急关闭开关）是一种紧急机制，允许在发现问题时立即禁用某个功能，而不需要重新部署代码。 - -## Use Cases (from this source) -- 支付处理器异常？切换到备用提供商 -- 搜索结果异常？回退到旧算法 -- AI 模型产生幻觉？切换回上一版本 - -## Benefits -- 将 RTO 从小时级降至秒级 -- 无需在压力下调试 -- 保护用户数据和体验 - -## Connections -- [[Feature Flag]] ← 实现方式 → [[Kill Switch]] -- [[RTO (Recovery Time Objective)]] ← 降低工具 → [[Kill Switch]] diff --git a/wiki/concepts/Kirkpatrick.md b/wiki/concepts/Kirkpatrick.md deleted file mode 100644 index 8121aa2c..00000000 --- a/wiki/concepts/Kirkpatrick.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: "Kirkpatrick 四级评估模型" -type: concept -tags: [training-evaluation, instructional-design] -sources: [] -last_updated: 2026-04-20 ---- - -## Definition -培训效果评估的四级框架，由 Donald Kirkpatrick 提出，是企业培训领域最权威的评估模型。 - -## Four Levels -- **Level 1 (Reaction)**：反应评估——培训满意度调查 -- **Level 2 (Learning)**：学习评估——知识考试、技能实操评估 -- **Level 3 (Behavior)**：行为评估——培训后 30/60/90 天行为改变追踪 -- **Level 4 (Results)**：结果评估——业务指标变化 - -## Application Rules -- 所有培训项目至少达到 Level 2 -- 高投入项目必须追踪到 Level 3 - -## Related Concepts -- [[ADDIE 模型]]：课程设计框架 diff --git a/wiki/concepts/Knowledge-Base.md b/wiki/concepts/Knowledge-Base.md deleted file mode 100644 index 79b8d946..00000000 --- a/wiki/concepts/Knowledge-Base.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "Knowledge Base" -type: concept -tags: [] ---- - -## 定义 -经过整理、跨 Agent 共用的知识库目录，用于存储工具评测、架构决策、最佳实践等可复用知识。 - -## 示例 -``` -/Users/weishen/Workspace/nexus/openclaw/knowledgebase/ ← 知识库（经过整理的公共知识） -``` - -## 与 Agent Archive 的关系 -Agent Archive 是单一 Agent 的私有工作笔记，Knowledge Base 是整理后的公共知识。AI 在完成任务过程中将产出写入 Archive，验证通过后迁移到 Knowledge Base。 - -## 核心原则 -研究过程写入 Agent Archive；经过验证、可复用的知识沉淀到 Knowledge Base。 - -## 关联 -- [[Agent Archive]] -- [[Obsidian]] -- [[版本控制]] \ No newline at end of file diff --git a/wiki/concepts/Knowledge-Extraction.md b/wiki/concepts/Knowledge-Extraction.md deleted file mode 100644 index 7e43da00..00000000 --- a/wiki/concepts/Knowledge-Extraction.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "Knowledge Extraction" -type: concept -tags: [ai, knowledge-management, automation] -sources: [self-healing-home-server-infrastructure-management] -last_updated: 2026-04-17 ---- - -## Summary -Knowledge Extraction（知识提取）是指 AI Agent 从非结构化或半结构化数据源（如笔记、对话记录、邮件）中提取有价值信息并转化为结构化、可查询知识库的过程。 - -## Definition -将分散的、非结构化的信息通过 AI 处理转化为结构化、可复用知识的技术。 - -## Key Characteristics -- 从多种来源提取信息（Obsidian 笔记、ChatGPT 对话导出、邮件） -- 转化为原子事实（atomic facts） -- 构建可搜索的知识库 -- 随着时间推移价值递增 - -## Benefits -- 将个人知识资产结构化 -- 创建可搜索的知识库 -- 随时间累积价值（一个用户从 ChatGPT 历史中提取了 49,079 个原子事实） -- 支持 AI Agent 的上下文记忆 - -## Connections -- [[Obsidian]] ← stores ← [[Knowledge Extraction]]：Obsidian 笔记是知识提取的来源之一 -- [[Agentic AI]] ← performs ← [[Knowledge Extraction]]：AI Agent 执行知识提取 -- [[Knowledge Network]] ← built_by ← [[Knowledge Extraction]]：知识提取构建知识网络 \ No newline at end of file diff --git a/wiki/concepts/Kolb-体验式学习.md b/wiki/concepts/Kolb-体验式学习.md deleted file mode 100644 index 9b525d58..00000000 --- a/wiki/concepts/Kolb-体验式学习.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: "Kolb 体验式学习" -type: concept -tags: [learning-theory, experiential-learning] -sources: [] -last_updated: 2026-04-20 ---- - -## Definition -David Kolb 提出的体验式学习循环模型，强调学习是通过体验转化实现知识建构的过程。 - -## Four Stages -1. **Concrete Experience（具体经验）** -2. **Reflective Observation（反思观察）** -3. **Abstract Conceptualization（抽象概念化）** -4. **Active Experimentation（主动实验）** - -## Related Concepts -- [[混合学习]]：实践形式 diff --git a/wiki/concepts/Koppen-Climate-Classification.md b/wiki/concepts/Koppen-Climate-Classification.md deleted file mode 100644 index bd61a869..00000000 --- a/wiki/concepts/Koppen-Climate-Classification.md +++ /dev/null @@ -1,62 +0,0 @@ ---- -title: "Koppen Climate Classification" -type: concept -tags: [geography, climate, classification] -last_updated: 2026-04-20 ---- - -## Definition -柯本气候分类法（Koppen Climate Classification）是一种基于植物分布和温度降水模式的气候分类系统，由俄罗斯气候学家弗拉基米尔·柯本于 1884 年创立，是物理地理学的基础工具。 - -## Classification System - -### Main Climate Groups -- **A**: Tropical（热带气候） -- **B**: Dry（干旱气候） -- **C**: Temperate（温带气候） -- **D**: Continental（大陆性气候） -- **E**: Polar（极地气候） - -### Secondary Divisions -- f: Moist（湿润） -- m: Monsoon（季风） -- w: Dry winter（冬干） -- s: Dry summer（夏干） -- g: G来型（Gust来型） -- etc. - -### Common Examples -- **Af**: Tropical rainforest（热带雨林） -- **Am**: Tropical monsoon（热带季风） -- **Aw/As**: Tropical savanna（热带稀树草原） -- **BWh**: Hot desert（炎热沙漠） -- **BWk**: Cold desert（寒冷沙漠） -- **Cfa**: Humid subtropical（湿润亚热带） -- **Cfb**: Oceanic（海洋性气候） -- **Cwa**: Monsoon humid subtropical（季风亚热带） -- **Dfa/Dfb**: Hot/Cold continental（夏季炎热/寒冷大陆性） - -## Application in Worldbuilding - -### Rules for [[Geographic Coherence]] -1. Climate zone must match latitude（气候带必须匹配纬度） - - Tropical (A) typically within ±23.5° of equator - - Temperate (C) typically 30°-50° latitude - - Continental (D) typically 40°-60° latitude - - Polar (E) above 60° latitude - -2. Altitude affects classification（海拔影响分类） - - Higher elevation can create cooler microclimates - - Mountain regions may have vertical climate zones - -3. Rain shadows exist（雨影效应存在） - - Mountain ranges block moisture - - Leeward sides are typically drier - -## Related Concepts -- [[Geographic Coherence]]: Framework for validating world geography -- [[Biome]]: Vegetation type consistent with climate -- [[Hydrology]]: Water flow patterns in geographic systems - -## Source -- Primary source: [[raw/Agent/agency-agents/academic/academic-geographer.md]] \ No newline at end of file diff --git a/wiki/concepts/Kraljic-Matrix.md b/wiki/concepts/Kraljic-Matrix.md deleted file mode 100644 index c8bb2e23..00000000 --- a/wiki/concepts/Kraljic-Matrix.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: "Kraljic Matrix" -type: concept -tags: [supply-chain, procurement] ---- - -## Definition -Kraljic Matrix（克拉夫基矩阵）是一种供应商分类框架，将采购项按供应风险和利润影响分为四类：战略型（Strategic）、杠杆型（Leverage）、瓶颈型（Bottleneck）、常规型（Routine）。 - -## Framework - -### 四象限分类 - -| 类型 | 供应风险 | 利润影响 | 采购策略 | -|------|----------|----------|----------| -| **战略型** (Strategic) | 高 | 高 | 深度合作、伙伴关系、联合开发 | -| **杠杆型** (Leverage) | 低 | 高 | 竞争性招标、总量平衡、供应商替换 | -| **瓶颈型** (Bottleneck) | 高 | 低 | 寻找替代源、保持库存、关系维护 | -| **常规型** (Routine) | 低 | 低 | 简化流程、自动化采购、减少管理成本 | - -## Application -- 用于制定品类级采购策略 -- 指导供应商关系管理决策 -- 识别需要重点管理的采购项 - -## Connections -- [[Supply Chain Strategist]] ← uses ← [[Kraljic Matrix]] -- [[ABC 分类法]] — 供应商分级管理，与 Kraljic Matrix 配合使用 - diff --git a/wiki/concepts/Kubernetes-Service-Account.md b/wiki/concepts/Kubernetes-Service-Account.md deleted file mode 100644 index b592b5f2..00000000 --- a/wiki/concepts/Kubernetes-Service-Account.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: "Kubernetes Service Account" -type: concept -tags: [Kubernetes, Security, Authentication] -last_updated: 2026-04-19 ---- - -## 定义 -Kubernetes Service Account（服务账户）是 Pod 用于身份验证到 Kubernetes API Server 的机制。每个 Pod 关联一个服务账户，默认使用 default 服务账户。 - -## 安全最佳实践 -- 禁用自动挂载（`automountServiceAccountToken: false`） -- 使用私有服务账户而非默认账户 -- 通过 Role/RoleBinding 最小化权限 -- 定期轮换服务账户凭据 - -## 关联安全配置 -- `automountServiceAccountToken`：控制是否自动挂载服务账户令牌 -- `imagePullSecrets`：用于私有镜像仓库认证 - -## 相关资源 -- 来源：[[CTP Topic 49 Container Lifecycle Hardening Standards]] -- 相关概念：[[Container-Lifecycle-Hardening]] \ No newline at end of file diff --git a/wiki/concepts/LLM.md b/wiki/concepts/LLM.md deleted file mode 100644 index c70fc74b..00000000 --- a/wiki/concepts/LLM.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: "LLM" -type: concept -tags: [llm, ai, 大语言模型] -date: 2026-04-18 ---- - -## Definition -大型语言模型（Large Language Model），AI 应用的"天才大脑"，学习了过去上下五千年的所有知识，擅长思考和推理，但对当前情况一无所知。 - -## Core Characteristics -- **知识截止时间**：LLM 的知识有训练数据的时间节点限制，例如 ChatGPT-5 的知识截止到 2024 年 6 月 -- **静态知识**：只能回答训练数据范围内的问题，无法直接获取实时信息 -- **推理能力**：在思考方面非常出色，可以帮助写文章、分析问题、编程、画画等 - -## LLM Types -- **底座大模型（Base Model）**：通用模型，如 ChatGPT、DeepSeek、Qwen -- **专有模型（Specialized Model）**：专项训练的模型，如： - - 绘画模型：Midjourney、Stable Diffusion、Flux - - 编程模型：Claude、Cursor - -## Limitations -1. 无法直接获取实时信息 -2. 对当前情况一无所知 -3. 可能产生幻觉（胡编乱造） - -## Solution: Combine with RAG and Agent -最佳实践架构： -- **LLM**：用于思考和推理 -- **RAG**：用于提供实时外部知识（认知） -- **Agent**：用于自主决策和执行 - -## Related Concepts -- [[RAG]]：为 LLM 提供外部实时知识 -- [[AI代理]]：基于 LLM 构建的自主行动系统 -- [[向量数据库]]：RAG 系统的基础设施 \ No newline at end of file diff --git a/wiki/concepts/LSIF-Language-Server-Index-Format.md b/wiki/concepts/LSIF-Language-Server-Index-Format.md deleted file mode 100644 index f3a880b6..00000000 --- a/wiki/concepts/LSIF-Language-Server-Index-Format.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -title: "LSIF (Language Server Index Format)" -type: concept -tags: [index-format, lsp, serialization] -last_updated: 2026-04-20 ---- - -## Definition -LSIF（Language Server Index Format）是一种用于存储预计算代码语义索引的标准化格式，支持语言服务器数据的序列化、导入和导出。 - -## Use Cases -- **预计算索引**：在 CI/CD 管道中预先构建索引，加快本地启动 -- **跨工具共享**：不同工具（IDE、搜索、文档生成）共享同一索引 -- **归档与回放**：存储代码库的语义快照用于历史分析 - -## Connections -- [[Semantic Index]] ← 格式 ← [[LSIF (Language Server Index Format)]] -- [[graphd]] ← 支持 ← [[LSIF (Language Server Index Format)]] diff --git a/wiki/concepts/LSP-Client-Orchestration.md b/wiki/concepts/LSP-Client-Orchestration.md deleted file mode 100644 index da0139f9..00000000 --- a/wiki/concepts/LSP-Client-Orchestration.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: "LSP Client Orchestration" -type: concept -tags: [lsp, concurrency, architecture] -last_updated: 2026-04-20 ---- - -## Definition -LSP Client Orchestration 是指并发管理多个语言服务器客户端的架构模式，使异构编程语言的代码智能在统一平台协同工作。 - -## Core Pattern -```typescript -class LSPOrchestrator { - private clients = new Map(); - private capabilities = new Map(); - - async initialize(projectRoot: string) { - await Promise.all([ - this.initializeClient('typescript', tsClient), - this.initializeClient('php', phpClient), - this.initializeClient('go', goClient), - this.initializeClient('rust', rustClient), - this.initializeClient('python', pyrightClient) - ]); - } - - async getDefinition(uri: string, position: Position): Promise { - const lang = this.detectLanguage(uri); - const client = this.clients.get(lang); - if (!client || !this.capabilities.get(lang)?.definitionProvider) { - return []; - } - return client.sendRequest('textDocument/definition', { textDocument: { uri }, position }); - } -} -``` - -## Key Challenges -- 能力协商：不同语言服务器能力差异巨大，需动态检测 -- 生命周期管理：每个客户端需独立经历 initialize → initialized → shutdown → exit -- 请求路由：根据文件扩展名路由到正确的语言服务器 - -## Connections -- [[LSP (Language Server Protocol)]] ← 基于 ← [[LSP Client Orchestration]] -- [[graphd]] ← 实现 ← [[LSP Client Orchestration]] diff --git a/wiki/concepts/LSP-Language-Server-Protocol.md b/wiki/concepts/LSP-Language-Server-Protocol.md deleted file mode 100644 index 759df1b3..00000000 --- a/wiki/concepts/LSP-Language-Server-Protocol.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "LSP (Language Server Protocol)" -type: concept -tags: [protocol, code-intelligence, editor] -last_updated: 2026-04-20 ---- - -## Definition -Language Server Protocol（LSP）是微软提出的标准化协议，为编辑器/IDE 提供编程语言特性支持（自动补全、跳转定义、悬停文档等），实现语言功能与编辑器的解耦。 - -## Core Features -- **文本文档同步**：textDocument/didOpen、textDocument/didChange -- **代码导航**：textDocument/definition、textDocument/references、textDocument/documentSymbol -- **代码补全**：textDocument/completion -- **悬停文档**：textDocument/hover -- **诊断信息**：textDocument/publishDiagnostics - -## LSP 3.17 Key Capabilities -- 能力协商机制（initialize 阶段交换 serverCapabilities） -- 完整生命周期管理（initialize → initialized → shutdown → exit） -- Workspace symbols 和 文件 URI 标准化 - -## Language Servers -- TypeScript: typescript-language-server -- PHP: intelephense, phpactor -- Go: gopls -- Rust: rust-analyzer -- Python: pyright, pylance - -## Connections -- [[graphd]] ← 依赖使用 ← [[LSP (Language Server Protocol)]] -- [[LSP Client Orchestration]] ← 基于 ← [[LSP (Language Server Protocol)]] diff --git a/wiki/concepts/LUT.md b/wiki/concepts/LUT.md deleted file mode 100644 index 467bf3af..00000000 --- a/wiki/concepts/LUT.md +++ /dev/null @@ -1,52 +0,0 @@ ---- -title: "LUT" -type: concept -tags: [lut, color-grading, video-editing] -aliases: [Look-Up Table, 色彩查找表] -last_updated: 2026-04-21 ---- - -## Definition -Look-Up Table，色彩查找表，本质是预设的色彩映射，用于色彩空间转换和风格化调色。 - -## Types - -### Technical LUT（技术 LUT） -- **用途**：转换 LOG 素材到标准色彩空间 -- 示例：S-Log3 到 Rec.709、S-Log3 到 Log-C -- **使用时机**：使用 LOG 模式拍摄后，必须先应用技术 LUT 还原正常色彩，再进行创意调色 -- **常见误区**：应用创意 LUT 前未做一级校色 → 色彩必然崩坏 - -### Creative LUT（创意 LUT） -- **用途**：添加风格化外观 -- 类型：胶片 LUT、电影 LUT、时尚 LUT 等 -- **使用原则**：LUT 是起点而非终点——应用后必须微调参数 -- **强度控制**：建议 60%-80% 透明度；100% 通常过重 - -## Workflow - -### Correct Application Order（正确应用顺序） -1. **一级校色**（Primary Correction）：还原真实——白平衡、曝光、对比度统一 -2. **技术 LUT**：LOG 素材应用转换 LUT -3. **二级调色**（Secondary Correction）：局部调整——HSL、曲线、遮罩 -4. **创意 LUT**（可选）：风格化处理 -5. **微调**：在创意 LUT 基础上精细调整 - -### Why Order Matters（为何顺序重要） -- LOG 素材对比度被拉伸，直接应用创意 LUT 会导致色彩计算错误 -- 必须先还原正常对比度，再做风格化处理 - -## Creating Custom LUTs -- 将常用调色参数导出为 LUT -- 用于个人风格一致性 -- 多视频系列保持统一视觉风格 - -## Common LUT Formats -- .cube（通用格式，DaVinci/PR/FCP 都支持） -- .3dl -- .look - -## Connections -- [[调色分级]] ← 技术载体 ← [[LUT]] -- [[短视频剪辑]] ← 环节 ← [[LUT]] -- [[DaVinci Resolve]] ← 内置 LUT 支持 ← [[LUT]] diff --git a/wiki/concepts/LaTeX模板.md b/wiki/concepts/LaTeX模板.md deleted file mode 100644 index 66830ba9..00000000 --- a/wiki/concepts/LaTeX模板.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "LaTeX模板" -type: concept -tags: [] -last_updated: 2026-04-17 ---- - -## Definition -LaTeX 模板是预配置的文档类，提供统一格式以跳过 LaTeX 排版的样板配置。 - -## Common Templates -- article：短文章/报告 -- IEEE：IEEE 期刊论文格式 -- beamer：演示文稿（PPT 替代） -- ctex-art：中文文章 - -## Usage -1. 选择模板后填充内容 -2. 添加参考文献（可选） -3. 编译生成 PDF - -## Connections -- [[LaTeX编译]]：模板决定编译选项 -- [[Prismer]]：内置模板支持 \ No newline at end of file diff --git a/wiki/concepts/LaTeX编译.md b/wiki/concepts/LaTeX编译.md deleted file mode 100644 index 50b8fab0..00000000 --- a/wiki/concepts/LaTeX编译.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "LaTeX编译" -type: concept -tags: [] -last_updated: 2026-04-17 ---- - -## Definition -LaTeX 编译是将 LaTeX 源码转换为 PDF 的过程，通过 pdflatex、xelatex 或 lualatex 引擎完成。 - -## Mechanism -- pdflatex：默认引擎，输出 PDF -- xelatex：支持 CJK/中文，高级字体配置 -- lualatex：LuaLaTeX 引擎，支持 Lua 脚本扩展 - -## Usage -- 需要 2 次编译以正确解析交叉引用 -- 编译日志显示错误和警告信息 -- 错误自动修复需要解析日志后重新编译 - -## Connections -- [[LaTeX源码]]：LaTeX 编译的输入文件 -- [[PDF]]：LaTeX 编译的输出格式 -- [[Prismer]]：提供编译环境 \ No newline at end of file diff --git a/wiki/concepts/Labor-Law-Compliance.md b/wiki/concepts/Labor-Law-Compliance.md deleted file mode 100644 index 9df7cfb7..00000000 --- a/wiki/concepts/Labor-Law-Compliance.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: "Labor Law Compliance" -type: concept -tags: [hr, compliance, law] -sources: [recruitment-specialist] -last_updated: 2026-04-20 ---- - -## Definition -Labor Law Compliance 指招聘、合同签订、试用期、社保、公积金、背景调查和解约等环节遵守当地劳动法规与隐私要求。 - -## Core Principles -- JD 不得包含歧视性要求 -- 个人信息处理需要明确授权 -- 背景调查前必须取得书面同意 -- 试用期、合同期限和补偿标准必须符合当地法规 - -## Related Entities -- [[Recruitment Specialist]] -- [[The Agency]] diff --git a/wiki/concepts/Lambda.md b/wiki/concepts/Lambda.md deleted file mode 100644 index d37c29c2..00000000 --- a/wiki/concepts/Lambda.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: "Lambda" -type: concept -tags: - - AWS - - Serverless - - Compute - - Cloud-Native -date: 2024-09-03 ---- - -## Definition -AWS Lambda 是无服务器（Serverless）计算服务，开发者只需编写业务逻辑代码，AWS 自动处理服务器配置、扩展和运维。Lambda 函数由事件触发，当事件发生时执行相应的代码。 - -## Core Characteristics -- 事件驱动：Lambda 函数由状态变化（事件）触发 -- 按需付费：按请求数和执行时长计费 -- 自动扩展：AWS 自动处理负载均衡和扩展 -- 支持语言：Node.js、Python、Java、C#、Go、Ruby 等 - -## Invocation Types -- 同步调用：调用者等待响应 -- 异步调用：事件进入队列后立即返回 -- 事件源映射：根据流或队列事件触发 - -## Management Features -- 版本控制：发布代码快照，通过别名指向特定版本 -- 别名：指向特定版本的指针，支持蓝绿部署 -- Layers：共享公共代码库 -- 并发控制：设置函数并发上限 - -## Aliases -- AWS Lambda -- Lambda 函数 -- Lambda Function \ No newline at end of file diff --git a/wiki/concepts/Land-and-Expand.md b/wiki/concepts/Land-and-Expand.md deleted file mode 100644 index 1b3521eb..00000000 --- a/wiki/concepts/Land-and-Expand.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: "Land-and-Expand" -type: concept -tags: [sales, account-strategy, expansion] -date: 2026-04-20 ---- - -## Definition -Land-and-Expand（着陆后扩展）是一种 SaaS 销售策略，核心思想是在获得初始客户后，通过系统性方法将单个产品或部门的使用扩展到整个企业平台。 - -## Core Principles -- **Initial Land**：首先获得一个入口点（部门、团队或用例） -- **Expand Systematically**：基于客户成功证据，扩展到更多用例、部门或预算 -- **Platform Transformation**：将 point solution 发展为 enterprise platform - -## Key Signals for Expansion -- 容量阈值触发（80%+ license consumption） -- 功能采用速度加快 -- 部门级使用不对称 -- 客户业务增长带动需求增加 - -## Expansion Playbook Components -- Champion Enablement Kits（ROI decks、internal business cases、peer case studies） -- 产品内扩展提示（usage milestones、feature unlocks、tier upgrade nudges） -- RACI 矩阵（ Responsible、Accountable、Consulted、Informed） - -## Related Concepts -- [[NRR]]：净收入留存率 -- [[Multi-Threading]]：多线程关系建立 -- [[Account Health Score]]：账户健康评分 - -## References -- [[Sales Account Strategist]] \ No newline at end of file diff --git a/wiki/concepts/Last-30-Days-Skill.md b/wiki/concepts/Last-30-Days-Skill.md deleted file mode 100644 index adf7bd24..00000000 --- a/wiki/concepts/Last-30-Days-Skill.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "Last 30 Days Skill" -type: concept -tags: [openclaw, skill, market-research, reddit, twitter] -last_updated: 2026-04-17 ---- - -## Aliases -- Last 30 Days -- Last 30 Days skill -- last30days-skill - -## Definition -Matt Van Horn 开发的 OpenClaw skill，可获取指定主题在过去 30 天内 Reddit 和 X（Twitter）上的用户讨论、抱怨和功能请求。 - -## Functionality -- 搜索指定主题的 Reddit 帖子和评论 -- 搜索 X（Twitter）上关于该主题的推文 -- 汇总真实用户的痛点、抱怨和功能需求 -- 排序：按频率排名最常见的用户痛点 - -## Use Cases -- 市场研究：发现用户未满足的需求 -- 竞品分析：了解用户对竞品的抱怨 -- 产品创意：识别产品机会 -- 内容创作：获取用户关心的热门话题 - -## Connected Pages -- [[market-research-product-factory]] - -## Source -- GitHub: https://github.com/mvanhorn/last30days-skill/ \ No newline at end of file diff --git a/wiki/concepts/Lead-Generation-Funnel.md b/wiki/concepts/Lead-Generation-Funnel.md deleted file mode 100644 index a93f13d7..00000000 --- a/wiki/concepts/Lead-Generation-Funnel.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: "Lead Generation Funnel" -type: concept -tags: [marketing, conversion, sales] -last_updated: 2026-04-21 ---- - -## Definition -销售漏斗，从内容参与到销售对话的转化路径，通过战略定位和隐性 CTA 将感兴趣的读者转化为合格潜在客户。 - -## Funnel Stages -1. **Awareness**：通过高质量回答吸引目标受众关注 -2. **Engagement**：通过有价值内容建立信任和兴趣 -3. **Consideration**：读者开始将品牌视为问题解决方案 -4. **Conversion**：通过战略 CTA 将读者转化为销售线索 - -## CTA Strategy -- Never hard sell：避免激进销售语言 -- Subtle positioning：隐性定位，让专业价值说话 -- Value-driven：提供价值而非推销产品 -- Multiple touchpoints：多触点追踪，从回答到专栏到私信 - -## Key Metrics -- Traffic Conversion：3-8% of Zhihu traffic converting to website/CRM leads -- Lead Quality：50-200 qualified leads per month -- Business Impact：10-30% of leads from Zhihu converting to customers - -## Implementation -- Answer-level CTAs：回答末尾的自然延伸阅读 -- Profile-level CTAs：个人主页的完整价值主张 -- Column-level CTAs：专栏作为深度内容聚合和线索培育 -- Live/Event CTAs：知乎 Live 和活动实现深度互动转化 - -## Related Concepts -- [[Thought Leadership]] ← generates ← [[Lead Generation Funnel]] -- [[Content Pillar]] ← supports ← [[Lead Generation Funnel]] -- [[Sales Pipeline]] ← outputs ← [[Lead Generation Funnel]] \ No newline at end of file diff --git a/wiki/concepts/Lifecycle-Policy.md b/wiki/concepts/Lifecycle-Policy.md deleted file mode 100644 index a0633f31..00000000 --- a/wiki/concepts/Lifecycle-Policy.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: "Lifecycle Policy" -type: concept -tags: [AWS, Storage, Cost-Optimization] -sources: [] -last_updated: 2026-04-19 ---- - -## Definition -生命周期策略是一种自动化规则，用于在不同存储层之间自动转换数据、设置保留策略和管理过期对象，无需手动操作。 - -## Key Features -- 自动存储层转换：根据预设规则将数据从热存储移动到冷存储 -- 保留策略：设置快照和对象的保留期限 -- 过期清理：自动删除过期对象和不完整的分段上传 -- 成本优化：减少存储费用，优化存储支出 - -## AWS Services -- **S3 Lifecycle Policies**：转换对象到 S3 Standard → Intelligent-Tiering → Glacier 层级 -- **EFS Lifecycle Policies**：将文件在标准层和不频繁访问层之间移动 -- **EBS Snapshot Lifecycle**：归档快照到 Archive 层，使用 DLM 或 AWS Backup - -## Implementation -```json -{ - "Rules": [ - { - "ID": "MoveToGlacier", - "Status": "Enabled", - "Filter": {"Prefix": "archive/"}, - "Transitions": [ - {"Days": 365, "StorageClass": "GLACIER"} - ], - "Expiration": {"Days": 1825} - } - ] -} -``` - -## Connections -- [[S3-Intelligent-Tiering]] ← implements ← [[Lifecycle-Policy]] -- [[EFS-Inrequent-Access]] ← implements ← [[Lifecycle-Policy]] -- [[EBS-Snapshot-Archive]] ← uses ← [[Lifecycle-Policy]] \ No newline at end of file diff --git a/wiki/concepts/Liquid-Glass-Design-System.md b/wiki/concepts/Liquid-Glass-Design-System.md deleted file mode 100644 index 016a9dbb..00000000 --- a/wiki/concepts/Liquid-Glass-Design-System.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: "Liquid Glass Design System" -type: concept -tags: [design-system, apple, visionOS, ui-design] ---- - -## 定义 -Apple visionOS 26 的核心设计系统，提供半透明材质，能够适应光照/暗环境和周围内容，创建沉浸式的空间界面效果。 - -## 核心特性 -- Translucent Materials：半透明材质效果 -- Environment Adaptation：自适应光照环境 -- Content Blending：与周围数字内容融合 -- Depth Perception：深度感知支持 - -## 应用场景 -- 窗口背景 -- 面板和装饰 -- 控件容器 -- 空间小组件 - -## 相关技术 -- [[SwiftUI]] glassBackgroundEffect -- [[visionOS]] Native APIs -- [[RealityKit]] 渲染集成 - -## 相关实体 -- [[Apple]]：设计系统提供者 -- [[visionOS Spatial Engineer]]：设计系统实现者 \ No newline at end of file diff --git a/wiki/concepts/Listener-Pattern.md b/wiki/concepts/Listener-Pattern.md deleted file mode 100644 index 53c9b62a..00000000 --- a/wiki/concepts/Listener-Pattern.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "Listener Pattern" -type: concept -tags: [ECS, architecture, centralized-management] -sources: [] -last_updated: 2026-04-20 ---- - -## Definition -Listener Pattern（监听器模式）是一种集中管理 ECS 的架构方法，通过统一的监听器组件协调多个 ECS 服务的部署和流量管理。该模式解决了多个产品各自从 Gruntwork 下载代码并在本地使用的问题，实现集中化的 ECS 管理。 - -## Rationale -企业需要统一管理多个产品的容器化部署，Listener Pattern 提供了集中化的解决方案，便于： -- 统一的流量管理 -- 配置复用 -- 跨产品的标准化部署 - -## Related Concepts -- [[ECS (Elastic Container Services)]] -- [[Infrastructure as Code (IaC)]] -- [[Terraform]] - -## Related Entities -- [[Public Cloud Learning Sessions]] \ No newline at end of file diff --git a/wiki/concepts/Listing-Optimization.md b/wiki/concepts/Listing-Optimization.md deleted file mode 100644 index 9da6b6ef..00000000 --- a/wiki/concepts/Listing-Optimization.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: Listing Optimization -type: concept -tags: [ecommerce, seo, amazon, cross-border, localization] -aliases: [Product Listing, Multilingual Listing] ---- - -## Definition -商品 listing 优化，通过本地化语言、关键词策略、视觉设计和结构化内容提升搜索排名和转化率。 - -## Core Components -- Title：品牌 + 核心关键词 + 属性 + 卖點 + 规格 -- Bullet Points：五点清晰展示产品价值 -- Product Description：详细说明产品功能和使用场景 -- Backend Search Terms：隐藏关键词补充 -- Images：主图 + 生活方式图 + 信息图 - -## Key Principles -- 本地语言审查是强制要求：机器翻译是最大的转化率杀手 -- 文化禁忌和敏感词必须避免 -- 视觉本地化适配目标市场审美 -- A+ Content（亚马逊）大幅提升转化率 - -## Platforms with Listing Optimization -- Amazon：A+ Content、品牌故事模块 -- Shopee/Lazada：平台特定的 listing 结构 -- TikTok Shop：短视频内容优化 - -## Connections -- [[Marketing Cross-Border E-Commerce Specialist]] ← performs ← [[Listing Optimization]] \ No newline at end of file diff --git a/wiki/concepts/Lockable-Workflow.md b/wiki/concepts/Lockable-Workflow.md deleted file mode 100644 index d1d0a3aa..00000000 --- a/wiki/concepts/Lockable-Workflow.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "Lockable Workflow" -type: concept -tags: [n8n, security, workflow] -date: 2026-04-17 ---- - -## Definition -可锁定工作流模式，测试通过后锁定工作流，防止 AI Agent 悄悄修改 API 交互方式。 - -## Why Lock -- 未锁定的 工作流允许 Agent 自由修改 -- Agent 可能无意中改变请求格式或端点 -- 锁定确保 API 交互方式的稳定性 - -## Workflow -1. Agent 设计并创建工作流 -2. 手动测试验证功能正确性 -3. 手动锁定工作流 -4. Agent 只能通过 webhook 调用，无法修改 - -## Use Cases -- 保护生产环境 API 调用 -- 确保外部服务集成稳定性 -- 防止 Agent 绕过安全检查 \ No newline at end of file diff --git a/wiki/concepts/Log-Analytics.md b/wiki/concepts/Log-Analytics.md deleted file mode 100644 index 7b598a21..00000000 --- a/wiki/concepts/Log-Analytics.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: "Log Analytics" -type: concept -tags: [Log-Analytics, Observability, DevOps] -date: 2026-04-14 ---- - -## Definition -Log Analytics（日志分析）是云运维可观测性的核心组件，负责日志数据的采集、存储、搜索和可视化，帮助运维团队监控系统健康、排查故障和安全审计。 - -## Architecture -典型日志分析架构包含： -1. **采集层**：BEATS（Filebeat、Metricbeat、Heartbeat 等）从应用采集日志 -2. **处理层**：Logstash 聚合和转换日志数据 -3. **存储层**：Elasticsearch 或 OpenSearch 存储和索引日志 -4. **可视化层**：Kibana 提供查询和可视化界面 -5. **可选缓冲**：Redis 防止 Logstash 过载 - -## Security Measures -- 静态加密：加密节点 + NVMe 设备硬件级加密 -- 传输加密：TLS 1.2 -- VPC 间私有流量，不经过公网 -- 基于索引的访问控制 + RBAC - -## Regional Deployment -出于 GDPR 合规要求，日志农场按区域 split（Oregon 美国、Europe 欧洲）。 - -## Solutions Comparison -| 方案 | 成本（单农场/14天/100GB日） | SLA | 特点 | -|------|---------------------------|-----|------| -| Logz.io | ~$4,000/月 | 99.8% | 托管 ELK，试用期 | -| AWS OpenSearch | ~$1,500/月 | 99.9% | 托管，自动快照 | -| 自托管 ELK | 最低 | 自定义 | 维护量大 | -| Microfocus OBA | 较高 | 成熟 | 商业选项，自动化集群 | - -## Connections -- [[Log Analytics]] ← implements ← [[Observability-Engineering]] -- [[Log Analytics]] ← uses ← [[ELK Stack]] -- [[Log Analytics]] ← uses ← [[OpenSearch]] -- [[ELK Stack]] ← provides ← [[Log Analytics]] -- [[OpenSearch]] ← provides ← [[Log Analytics]] \ No newline at end of file diff --git a/wiki/concepts/Logstash.md b/wiki/concepts/Logstash.md deleted file mode 100644 index 0dcef080..00000000 --- a/wiki/concepts/Logstash.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -title: "Logstash" -type: concept -tags: [Log-Analytics, Data-Processing, ETL] -date: 2026-04-14 ---- - -## Definition -Logstash 是 ELK Stack 中的日志处理管道组件，负责接收、转换和 enrichment 日志数据，然后发送到 Elasticsearch 存储。 - -## Description -Logstash 支持多种输入源（文件、网络、Beats 等），通过过滤器对日志进行解析、转换、添加字段等处理，然后输出到目标存储。可选使用 Redis 作为消息队列缓冲，防止 Logstash 过载。 - -## Connections -- [[Logstash]] ← receives_from ← [[BEATS]] -- [[Logstash]] ← sends_to ← [[Elasticsearch]] -- [[Logstash]] ← uses_buffer ← [[Redis]] -- [[ELK Stack]] ← depends_on ← [[Logstash]] \ No newline at end of file diff --git a/wiki/concepts/Longue-Duree.md b/wiki/concepts/Longue-Duree.md deleted file mode 100644 index 7d291d56..00000000 --- a/wiki/concepts/Longue-Duree.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: "Longue Durée" -type: concept -tags: [history, historiography, annales-school] -last_updated: 2026-04-20 ---- - -## Definition -长时段（Longue Durée）是法国历史学家费尔南·布罗代尔提出的史学概念，指塑造人类历史发展的长期结构性力量，如地理、气候、人口、技术缓慢变迁等。 - -## Etymology -- 法语：longue durée，字面意思是"漫长的时期"或"长时段" - -##布罗代尔的三层时间结构 -1. **La longue durée（长时段）**：地理时间，几百年到几千年的缓慢变迁 -2. **La moyenne durée（中时段）**：社会经济时间，几十年到几代人的周期波动 -3. **Le temps court（短时段）**：事件时间，政治、战争、人物等即时事件 - -## Core Insight -历史事件只有放在长时段背景下才能被理解。短期事件往往只是长期结构的表面现象。 - -## Application in Worldbuilding -- 验证地理环境是否与设定时期匹配 -- 检查技术进步是否在合理的时间框架内 -- 确保社会结构变化有足够的物质基础 - -## Historical Examples -- 地中海地区：气候和地理决定了贸易路线和文明分布 -- 工业革命：不是突然发生，而是长期积累的结果 -- 中世纪欧洲：需要放在更长的欧洲历史框架中理解 - -## Criticism -- 过度强调结构可能忽视人类能动性 -- 难以应用于快速变化的时代 - -## Related Concepts -- [[Material Culture]]：长时段分析的关注点 -- [[Period Authenticity Report]]：使用长时段方法验证设置 -- [[Annales School]]：年鉴学派的核心方法论 - -## Source -布罗代尔（Braudel），《菲利普二世时代的地中海和地中海世界》 diff --git a/wiki/concepts/Luhmann-四原则.md b/wiki/concepts/Luhmann-四原则.md deleted file mode 100644 index eb5cb1c1..00000000 --- a/wiki/concepts/Luhmann-四原则.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "Luhmann 四原则" -type: concept -tags: [knowledge-management, validation] -date: 2026-04-19 ---- - -## Summary -- 定义：ZK Steward 使用的四项验证原则，确保笔记符合 Zettelkasten 方法论 - -## Four Principles -| 原则 | 检查问题 | -|------|---------| -| 原子性 | 能否独立理解？ | -| 连接性 | 是否至少2个有意义链接？ | -| 有机增长 | 是否避免过度结构化？ | -| 持续对话 | 是否激发进一步思考？ | - -## Usage -- [[ZK Steward]] 使用四原则作为验证门 - -## Connections -- [[Luhmann 四原则]] ← validation_for ← [[Zettelkasten]] -- [[Luhmann 四原则]] ← implemented_in ← [[ZK Steward]] \ No newline at end of file diff --git a/wiki/concepts/MCP.md b/wiki/concepts/MCP.md deleted file mode 100644 index 20096cf5..00000000 --- a/wiki/concepts/MCP.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "MCP" -type: concept -tags: [ai, mcp, protocol] -date: 2026-04-17 ---- - -## Definition -MCP（Modal Context Protocol）是一种基于 Client-Server 架构的协议，旨在实现大模型与外围服务的高效集成。 - -## Core Interfaces -MCP Server 提供三种功能接口： -- **资源获取**：类似 HTTP 的 GET 请求 -- **工具调用**：类似 POST 请求 -- **Promise 提示词**：用于多样化的交互与扩展 - -## MCP in Cursor -- 在 Cursor 中通过设置新增 MCP Server -- 支持两种接入方式：SSE 服务方式和本地执行命令方式 - -## Connections -- 属于 [[Agentic AI]] 技术栈 -- 与 [[Sequential Thinking]] 工具配合使用可提升 AI 决策质量 -- Cursor 支持 [[MCP]] 协议集成 diff --git a/wiki/concepts/MCP传输协议.md b/wiki/concepts/MCP传输协议.md deleted file mode 100644 index a63e5d36..00000000 --- a/wiki/concepts/MCP传输协议.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: "MCP传输协议" -type: concept -tags: [ai, mcp, transport] -date: 2026-04-20 ---- - -## Definition -MCP Server 常见的传输方式，包括 stdio、SSE 和 Streamable HTTP，用于不同部署与集成场景。 - -## Transport Types -- **stdio**：适合本地 CLI / 桌面集成 -- **SSE**：适合 Web 或远程 Agent 场景 -- **Streamable HTTP**：适合云端无状态部署 - -## Connections -- [[MCP]] -- [[MCP服务器]] -- [[MCP Builder]] diff --git a/wiki/concepts/MCP工具接口设计.md b/wiki/concepts/MCP工具接口设计.md deleted file mode 100644 index 520c2af2..00000000 --- a/wiki/concepts/MCP工具接口设计.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: "MCP工具接口设计" -type: concept -tags: [ai, mcp, design, tool-design] -date: 2026-04-20 ---- - -## Definition -以 Agent 为用户来设计 MCP 工具接口的规范，强调 verb_noun 命名、清晰描述、单一职责、可预测参数和结构化输出。 - -## Principles -- 工具名应使用 verb_noun 形式，例如 `search_tickets` -- 描述应说明何时使用，而不是只说它是什么 -- 每个工具只负责一件事 -- 参数应有明确类型、默认值和边界 - -## Connections -- [[MCP]] -- [[MCP服务器]] -- [[MCP Builder]] diff --git a/wiki/concepts/MCP服务器.md b/wiki/concepts/MCP服务器.md deleted file mode 100644 index c64ac9d0..00000000 --- a/wiki/concepts/MCP服务器.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: "MCP服务器" -type: concept -tags: [ai, mcp, protocol] -date: 2026-04-17 ---- - -## Definition -MCP（Model Context Protocol，模型上下文协议）是一种支持将外部工具和服务集成到 AI 代理的协议平台，赋予 AI 代理更丰富的执行能力。 - -## Full Name -Model Context Protocol - -## Context -- Cursor 的扩展功能 - -## Features -- 集成外部 API 和工具 -- 扩展 AI 代理功能范围 -- 支持添加和切换多个 MCP 服务器 - -## Usage -在 Cursor 中添加 MCP 服务器： -1. 打开设置面板 -2. 找到 MCP 服务器配置 -3. 添加或切换 MCP 服务器 - -## Related Entities -- [[Cursor]] \ No newline at end of file diff --git a/wiki/concepts/MEDDPICC.md b/wiki/concepts/MEDDPICC.md deleted file mode 100644 index de440726..00000000 --- a/wiki/concepts/MEDDPICC.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -title: "MEDDPICC" -type: concept -tags: [sales, qualification, methodology] -last_updated: 2026-04-20 ---- - -## Summary -- 定义：销售资格认证框架，用于评估和验证交易机会的可行性 -- 全称：Metrics, Economic Buyer, Decision Criteria, Decision Process, Paper Process, Identify Pain, Champion, Competition -- 目的：确保交易在进入销售漏斗前具备必要的验证元素 - -## Components - -### Metrics（关键指标） -- 客户期望达成的业务成果 -- 可量化的业务价值 - -### Economic Buyer（经济决策者） -- 有预算决策权的人 -- 能够批准购买决策的人 - -### Decision Criteria（决策标准） -- 客户用来评估供应商的标准 -- 采购决策的评分规则 - -### Decision Process（决策流程） -- 客户内部的采购审批流程 -- 各环节的参与者和时间节点 - -### Paper Process（文件流程） -- 合同谈判条款 -- 法务合规要求 - -### Identify Pain（痛点识别） -- 客户面临的具体业务问题 -- 问题的影响和紧迫性 - -### Champion（ champion） -- 内部支持者 -- 能够推动决策的人 - -### Competition（竞争） -- 竞争对手方案 -- 差异化价值主张 - -## Usage -- 作为诊断工具而非 checkbox -- 当销售代表无法阐述经济决策者时，不是 CRM 问题而是交易风险 -- 资格差距是 coaching 机会 - -## Connections -- [[Sales Coaching]]：使用 MEDDPICC 进行资格验证 coaching -- [[Sales Coach]]：实施框架的 AI Agent \ No newline at end of file diff --git a/wiki/concepts/ML-Ops.md b/wiki/concepts/ML-Ops.md deleted file mode 100644 index 97b09c94..00000000 --- a/wiki/concepts/ML-Ops.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "ML Ops" -type: concept -tags: [machine-learning, operations, lifecycle] -sources: [specialized-model-qa] -last_updated: 2026-04-20 ---- - -## Definition -ML Ops is the discipline of operationalizing machine learning models across development, deployment, monitoring, and governance. - -## Core Areas -- Data pipelines -- Training and deployment -- Monitoring and drift detection -- Governance and auditability - -## Relevance to Model QA -- Provides the operational context for audits -- Supplies monitoring and reproducibility artifacts -- Supports remediation and retraining loops - -## Related Concepts -- [[Model Audit]] -- [[Discrimination Metrics]] \ No newline at end of file diff --git a/wiki/concepts/MPP.md b/wiki/concepts/MPP.md deleted file mode 100644 index 40d090cc..00000000 --- a/wiki/concepts/MPP.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: "MPP" -type: concept -tags: [AWS, Redshift, 并行处理] -sources: [ctp-topic-68-introduction-to-redshift] -last_updated: 2026-04-18 ---- - -## Summary - -MPP（Massively Parallel Processing，大规模并行处理）是一种使查询能够跨多个计算节点并行执行的技术。 - -## Definition - -- **全称**：Massively Parallel Processing -- **作用**：提升查询速度和响应时间 -- **应用**：Redshift 等数据仓库系统 - -## Key Benefits - -- 跨节点并行处理查询 -- 提升查询性能 -- 缩短响应时间 -- 支持 PB 级数据处理 - -## Connections - -- [[AWS-Redshift]] → 使用 → [[MPP]] -- [[Compute-Node]] → 执行 → [[MPP]] \ No newline at end of file diff --git a/wiki/concepts/MVP.md b/wiki/concepts/MVP.md deleted file mode 100644 index f2d9bce7..00000000 --- a/wiki/concepts/MVP.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: "MVP" -type: concept -tags: [product-development, entrepreneurship, lean-startup] -last_updated: 2026-04-17 ---- - -## Aliases -- Minimum Viable Product -- 最小可行产品 - -## Definition -用最少的资源构建一个能够验证核心产品假设的版本。MVP 关注的是验证市场需求，而非功能完整性。 - -## Key Principles -- 只构建核心功能 -- 快速验证假设 -- 最小化时间成本 -- 获取真实用户反馈 - -## Connected Pages -- [[market-research-product-factory]] -- [[Market-Research]] \ No newline at end of file diff --git a/wiki/concepts/Machine-Learning.md b/wiki/concepts/Machine-Learning.md deleted file mode 100644 index 3ae6feea..00000000 --- a/wiki/concepts/Machine-Learning.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "Machine Learning" -type: concept -tags: [AI, data-science] -sources: [public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machine-learning-20240206] -last_updated: 2024-02-06 ---- - -## Summary -机器学习是 AI 的子领域，使用数据创建决策逻辑或模型，通过从数据中学习来改进预测和决策。 - -## Definition -Machine Learning (ML) 是人工智能的一个分支，通过算法从数据中学习，自动改进模型以进行预测或决策，无需明确编程。 - -## Key Attributes -- **类型**：AI 子领域 -- **核心方法**：监督学习、无监督学习、强化学习 -- **应用**：分类、预测、生成、推荐 - -## Connections -- [[AI]] ← is_parent_of ← [[Machine Learning]] -- [[Machine Learning]] ← enables ← [[Generative AI]] -- [[Amazon SageMaker]] ← hosts ← [[Machine Learning]] -- [[Machine Learning]] ← implements ← [[RAG]] \ No newline at end of file diff --git a/wiki/concepts/Management-Groups.md b/wiki/concepts/Management-Groups.md deleted file mode 100644 index 4b645168..00000000 --- a/wiki/concepts/Management-Groups.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: Management Groups -type: concept -tags: [Azure, Organization, Management] -date: 2026-04-14 ---- - -## Definition -Azure Management Groups 是用于组织和管理多个订阅的分层容器，类似于 Windows 父目录结构，允许跨订阅的统一策略应用和访问控制。 - -## Key Characteristics -- 支持嵌套层级结构，最多 6 层深度 -- 可将策略和访问权限继承到下层订阅 -- 支持治理需求的企业级组织结构 -- 每个 Management Group 可包含多个订阅 - -## Use Cases -- 按业务部门组织订阅 -- 按环境（生产、开发、测试）分离 -- 按产品线或项目分组 -- 统一应用安全合规策略 - -## Related Concepts -- [[Subscription]]：Azure 订阅，资源隔离的容器 -- [[Azure Landing Zone]]：使用 Management Groups 实现组织结构 -- [[Service Control Policies]]：类似 AWS 的组织策略 - -## Connections -- [[Management Groups]] ← organizes ← [[Subscription]] -- [[Azure Landing Zone]] ← uses ← [[Management Groups]] \ No newline at end of file diff --git a/wiki/concepts/Management-Packs.md b/wiki/concepts/Management-Packs.md deleted file mode 100644 index 08316a43..00000000 --- a/wiki/concepts/Management-Packs.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: "Management Packs" -type: concept -tags: [Monitoring, OBM] -last_updated: 2026-04-19 ---- - -## Definition -Management Packs 是 Micro Focus Operations Bridge Manager (OBM) 的管理包，用于定义监控策略、指标和阈值。 - -## Function -- 定义监控间隔 -- 指定需要收集的指标 -- 配置数据收集范围（账户、服务、命名空间） -- 设置阈值触发事件 -- 新实例自动部署监控策略 - -## Usage in OBM -```yaml -Management Pack Config: - - Role ARN: arn:aws:iam::123456789012:role/OBM-Role - - Account ID: target account - - Namespaces: AWS/EC2, AWS/Lambda, etc. - - Metrics: CPUUtilization, MemoryUtilization - - Thresholds: 80% (warning), 90% (critical) - - Frequency: 5 minutes -``` - -## References -- [[Operations Bridge Manager (OBM)]] -- [[CTP Topic 8 Implementation of Cloud monitoring using Micro Focus Operations Bridge]] \ No newline at end of file diff --git a/wiki/concepts/Market-Research.md b/wiki/concepts/Market-Research.md deleted file mode 100644 index 92562b52..00000000 --- a/wiki/concepts/Market-Research.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: "Market Research" -type: concept -tags: [market-research, product-development, competitive-intelligence, market-sizing] -last_updated: 2026-04-20 ---- - -## Definition -通过系统化收集和分析市场信息、竞争情报和用户需求，为产品策略和创新决策提供依据的过程。 - -## Core Components -- 行业分析（Industry Analysis） -- 竞争情报（Competitive Intelligence） -- 市场规模（Market Sizing） -- 细分市场分析（Segmentation Analysis） - -## Market Sizing Framework -- **TAM（Total Addressable Market）**：总可寻址市场，自顶向下和自底向上分析 -- **SAM（Serviceable Addressable Market）**：可服务市场，考虑地理和业务约束后的现实市场机会 -- **SOM（Serviceable Obtainable Market）**：可获得市场，通过竞争分析确定的可实现市场份额 - -## Research Tools -- Google Trends：搜索趋势分析 -- SEMrush / Ahrefs：关键词和竞争分析 -- SimilarWeb：网站流量分析 -- Statista：统计数据 -- CB Insights / PitchBook：投资和创业情报 - -## AI-Enhanced Approach -使用 Last 30 Days skill 等工具自动挖掘 Reddit 和 X 上的真实用户讨论，获取未经过滤的用户情绪数据。[[Product Trend Researcher]] 提供完整的趋势识别和竞争情报框架。 - -## Traditional Methods -- 问卷调查 -- 用户访谈 -- 焦点小组 -- 论坛和社交媒体浏览 - -## Connected Pages -- [[market-research-product-factory]] -- [[Last-30-Days-Skill]] -- [[Competitive Intelligence]] -- [[TAM/SAM/SOM]] \ No newline at end of file diff --git a/wiki/concepts/Marketing-Attribution-Modeling.md b/wiki/concepts/Marketing-Attribution-Modeling.md deleted file mode 100644 index 12d50a68..00000000 --- a/wiki/concepts/Marketing-Attribution-Modeling.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: "Marketing Attribution Modeling" -type: concept -tags: [] -last_updated: 2026-04-21 ---- - -## Definition -多触点归因模型，将转化功劳分配给营销漏斗中的不同触点（首次点击、末次点击、中间触点）。 - -## Attribution Models -| Model | First Touch | Last Touch | Middle Touches | -|-------|------------|------------|----------------| -| First Touch | 100% | - | - | -| Last Touch | - | 100% | - | -| Linear | - | - | 平均分配 | -| Time Decay | 较低 | 较高 | 随时间递减 | -| Position Based | 40% | 40% | 20% 均分 | -| Data-Driven | 基于算法 | 基于算法 | 基于算法 | - -## Multi-Touch Attribution SQL -```sql -WITH customer_touchpoints AS ( - SELECT customer_id, channel, campaign, - ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY touchpoint_date) as touch_sequence, - COUNT(*) OVER (PARTITION BY customer_id) as total_touches - FROM marketing_touchpoints -), -attribution_weights AS ( - SELECT *, - CASE - WHEN touch_sequence = 1 AND total_touches = 1 THEN 1.0 - WHEN touch_sequence = 1 THEN 0.4 - WHEN touch_sequence = total_touches THEN 0.4 - ELSE 0.2 / (total_touches - 2) - END as attribution_weight - FROM customer_touchpoints -) -SELECT channel, SUM(revenue * attribution_weight) as attributed_revenue -FROM attribution_weights -GROUP BY channel; -``` - -## Related Concepts -- [[Data-Driven Decision Making]] -- [[KPI Tracking]] - -## Source -- [[support-analytics-reporter]] - diff --git a/wiki/concepts/Material-Culture.md b/wiki/concepts/Material-Culture.md deleted file mode 100644 index 01aba44a..00000000 --- a/wiki/concepts/Material-Culture.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: "Material Culture" -type: concept -tags: [history, anthropology, worldbuilding] -last_updated: 2026-04-20 ---- - -## Definition -物质文化是指人们在特定历史时期生产和使用的物质对象、技术、建筑及日常物品，以及这些物品如何反映和塑造社会结构。 - -## Core Focus Areas -- **Diet**: 实际饮食内容，包括阶级差异 -- **Clothing**: 材料、款式、社会标记 -- **Architecture**: 建筑材料、风格、幸存与失传 -- **Technology**: 存在的技术、不存在的技术、区域性技术 -- **Currency/Trade**: 经济系统、贸易路线、商品 - -## Annales School Approach -Academic Historian 采用年鉴学派方法，关注： -- La longue durée（长时段）：塑造历史的长期结构 -- Histoire immobile：几乎不变的历史结构 -- 地中海模式（布罗代尔）：地理、物质、经济三层结构 - -## Importance in Worldbuilding -1. 提供历史感知的"质感" -2. 避免现代价值观投射（presentism） -3. 通过物质条件理解社会结构 -4. 创造可信的虚构社会 - -## 与 Social Structure 的关系 -物质文化是经济基础，社会结构是上层建筑： -- 先理解物质条件（饮食、贸易、技术） -- 再讨论政治或战争 - -## Common Myths -- 中世纪"黑暗"：实际上城市卫生、贸易网络比想象中发达 -- 古代"落后"：需要具体分析，避免泛化 - -## Related Concepts -- [[Longue Durée]]：长时段分析框架 -- [[Period Authenticity Report]]：物质文化是报告的核心组成部分 -- [[Academic Anthropologist]]：共享物质文化分析方法 - -## Source -Academic Historian Agent — The Agency 项目 diff --git a/wiki/concepts/McKee-故事结构.md b/wiki/concepts/McKee-故事结构.md deleted file mode 100644 index 498951e1..00000000 --- a/wiki/concepts/McKee-故事结构.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: "McKee 故事结构" -type: concept -tags: [narrative-theory, story-structure, screenplay] ---- - -## 定义 -Robert McKee 在《故事》一书中提出的专业剧本写作理论，强调故事设计而非写作风格。 - -## 核心概念 -- **Controlling Idea**：故事通过角色和情节传达的关于生活本质的主张/论点 -- **对立统一（Antithesis）**：通过对比冲突制造戏剧张力 -- **三幕结构（Three-Act Structure）**： - - Setup（设置）：建立世界、角色、规则 - - Confrontation（对抗）：冲突升级、阻碍增多 - - Resolution（解决）：高潮、最终对决、新平衡 - -## 与其他框架关系 -- 与 [[Campbell 英雄之旅]] 互补，McKee 更注重主题论证 -- 与 [[Todorov 均衡模型]] 共享 equilibrium-disruption-return 结构 - -## 来源框架 -- [[Narratologist]] 使用此框架识别故事的 controlling idea 和 structure model diff --git a/wiki/concepts/McKinsey-SCQA-Framework.md b/wiki/concepts/McKinsey-SCQA-Framework.md deleted file mode 100644 index eaaeec98..00000000 --- a/wiki/concepts/McKinsey-SCQA-Framework.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "McKinsey SCQA Framework" -type: concept -tags: [consulting, strategic-communication, framework] -sources: [] -last_updated: 2026-04-21 ---- - -## Definition -Situation-Complication-Question-Answer，麦肯锡的结构化叙事框架，通过四步引导读者从情境到解决方案 - -## Structure -- **Situation**：设定背景，描述当前状态 -- **Complication**：揭示挑战或障碍 -- **Question**：提出核心问题 -- **Answer**：给出解决方案或答案 - -## Application -用于 Executive Summary Generator 的第一步"情境概述"，帮助建立叙事逻辑 - -## Related Concepts -- [[BCG Pyramid Principle]] -- [[Bain Action-Oriented Model]] -- [[Executive Summary]] \ No newline at end of file diff --git a/wiki/concepts/MedicalAdvertisingCompliance.md b/wiki/concepts/MedicalAdvertisingCompliance.md deleted file mode 100644 index 392374df..00000000 --- a/wiki/concepts/MedicalAdvertisingCompliance.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: "Medical Advertising Compliance" -type: concept -tags: [advertising, medical, compliance, china] -last_updated: 2026-04-20 ---- - -## Definition -Medical Advertising Compliance covers the approval, content, and publication rules governing ads for drugs, devices, and medical services in China. - -## Core Principles -- Publish only after required review/approval -- Avoid absolute claims, guarantees, endorsements, and efficacy comparisons -- Keep copy within approved indications, scope, and certificate details -- Use internal legal/compliance review before release - -## Related Concepts -- [[HealthcareMarketingCompliance]] -- [[MedicalAestheticsCompliance]] -- [[HealthSupplementMarketing]] diff --git a/wiki/concepts/MedicalAestheticsCompliance.md b/wiki/concepts/MedicalAestheticsCompliance.md deleted file mode 100644 index 5bbb5f2c..00000000 --- a/wiki/concepts/MedicalAestheticsCompliance.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: "Medical Aesthetics Compliance" -type: concept -tags: [medical-aesthetics, compliance, china] -last_updated: 2026-04-20 ---- - -## Definition -Medical Aesthetics Compliance is the subdomain of healthcare compliance governing yimei advertising, qualification display, and prohibited persuasion techniques. - -## Core Principles -- Do not create appearance anxiety as a marketing lever -- Before-and-after comparisons are high-risk or prohibited -- Separate lifestyle beauty from medical aesthetics correctly -- Verify institution, physician, and product qualifications before publication - -## Related Concepts -- [[HealthcareMarketingCompliance]] -- [[MedicalAdvertisingCompliance]] diff --git a/wiki/concepts/Memory-Tagging.md b/wiki/concepts/Memory-Tagging.md deleted file mode 100644 index 82159c57..00000000 --- a/wiki/concepts/Memory-Tagging.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: "Memory Tagging" -type: concept -tags: [memory, tagging, multi-agent, recall] -last_updated: 2026-04-21 ---- - -## Definition -Memory Tagging 是一种通过标签系统实现记忆精准召回的机制。在多智能体工作流中，每个记忆被标记为项目名和接收 agent 名，使后续 agent 能够自动检索所需上下文。 - -## Core Pattern -- **项目名标签**：确保同一项目的所有记忆可被召回 -- **接收方标签**：使特定 agent 可检索面向其的交付物 -- **类型标签**：区分 sprint-plan、research-brief、api-spec 等记忆类型 - -## Example -``` -记忆标签组合： -- retroboard + sprint-prioritizer + sprint-plan -- retroboard + ux-researcher + research-brief -- retroboard + backend-architect + api-spec -- retroboard + frontend-developer + api-spec -``` - -## Connections -- [[MCP Memory Server]]：支撑 remember/recall 操作的服务器 -- [[Multi-Agent Workflow]]：应用场景 -- [[Memory Backend]]：相关但不同的记忆架构方案 diff --git a/wiki/concepts/Memory-目录.md b/wiki/concepts/Memory-目录.md deleted file mode 100644 index b5976dcc..00000000 --- a/wiki/concepts/Memory-目录.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: "Memory 目录" -type: concept -tags: [OpenClaw, Agent, 长期记忆] ---- - -## 定义 -Memory 目录是 OpenClaw workspace 中的长期记忆存储机制，按日期滚动存储 Agent 与用户的对话中积累的重要信息。 - -## 职责 -- 解决 LLM 对话无状态问题（每次新会话什么都不记得） -- 存储用户偏好、工作背景、项目经验等持续信息 -- 支持 Agent 在多个会话之间积累理解 - -## 运作机制 -``` -对话发生 -↓ -Agent 通过普通文件工具把重要信息写入 `memory/` 或 `MEMORY.md` -↓ -下次对话开始 -↓ -Agent 通过 `memory_search` / `memory_get` 检索相关记忆 -↓ -相关记忆被注入到当前对话的上下文里 -↓ -Agent 表现出"我记得你说过……"的能力 -``` - -## 记忆方案 -- **builtin**：默认方案，原始记忆是 Markdown 文件，系统维护本地索引 -- **qmd**：底层围着 Markdown 文件转，换了一套更强的检索/索引方式 - -## 关键点 -对 Agent 来说，真正算数的长期记忆，是 workspace 里那些 Markdown 文件，不是什么看不见摸不着的黑盒数据库。 - -## 来源 -- [[万字讲透OpenClaw🦞从"能用"到"真好用"的分水岭：Workspace 深度解析]] - -## 相关 -- [[Workspace]]：包含 memory/ 目录的工作台目录 -- [[SOUL.md]]：配合 memory/ 实现个性化 -- [[USER.md]]：配合 memory/ 固化用户偏好 \ No newline at end of file diff --git a/wiki/concepts/Merge-Point.md b/wiki/concepts/Merge-Point.md deleted file mode 100644 index 4489ba87..00000000 --- a/wiki/concepts/Merge-Point.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "Merge Point" -type: concept -tags: [multi-agent, workflow, synchronization] -last_updated: 2026-04-21 ---- - -## Definition -Merge Point 是多智能体工作流中的关键同步节点，多个输入在此汇合后触发下一阶段。常见于一个 Agent 依赖多个前置 Agent 输出时的场景。 - -## Usage Scenario -在 landing page sprint 中，Frontend Developer 需要 Content Creator 和 UI Designer 的输出才能开始构建： - -``` -Content Creator ─┐ - ├──→ Merge Point → Frontend Developer -UI Designer ─────┘ -``` - -## Connections -- [[Multi-Agent Workflow]]：所属工作流模式 -- [[Parallel Kickoff]]：前置启动模式 -- [[Sequential Handoffs]]：相关交接概念 - diff --git a/wiki/concepts/Mermaid.md b/wiki/concepts/Mermaid.md deleted file mode 100644 index b6b63637..00000000 --- a/wiki/concepts/Mermaid.md +++ /dev/null @@ -1,15 +0,0 @@ ---- -title: "Mermaid" -type: concept -tags: [] -last_updated: 2025-12-18 ---- - -## Definition -一种用文本描述生成图表的标记语言，支持 ER 图、时序图、流程图等多种图表类型。 - -## Usage -在本文中，通过 Mermaid 代码描述数据结构（ER 图）和工作流（时序图），然后嵌入飞书文档渲染为可视化图表。 - -## Aliases -- Mermaid 图表语言 \ No newline at end of file diff --git a/wiki/concepts/Meta-Generative-Operator.md b/wiki/concepts/Meta-Generative-Operator.md deleted file mode 100644 index 600b0e06..00000000 --- a/wiki/concepts/Meta-Generative-Operator.md +++ /dev/null @@ -1,17 +0,0 @@ ---- -title: "Meta-Generative Operator" -type: concept -tags: [] ---- - -## Definition -元生成算子，记作 M: G × P → G，其中 G 是生成器空间，P 是提示空间。该算子使用优化后的提示来更新生成器本身。 - -## Context -元生成算子是递归自优化系统的核心组件，它实现了"生成器优化自身"的自引用循环。通过 M(G, P*)，系统能够利用优化结果改进其自身的生成能力。 - -## Related Concepts -- [[Generator Space]] -- [[Optimization Operator]] -- [[Self-Map]] -- [[Recursive Self-Optimizing Generative Systems]] \ No newline at end of file diff --git a/wiki/concepts/Metal.md b/wiki/concepts/Metal.md deleted file mode 100644 index 37e1d05a..00000000 --- a/wiki/concepts/Metal.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "Metal" -type: concept -tags: [graphics, rendering, apple, gpu, metal] -date: 2026-04-20 ---- - -## Definition -Metal 是 Apple 的 GPU 编程框架，提供低开销的 GPU 访问接口，用于构建高性能图形渲染和计算应用。 - -## Core Attributes -- 低开销 GPU 访问 -- GPU 着色器支持 -- 硬件加速渲染 -- GPU 计算内核 -- Instanced rendering -- Triple buffering - -## Related Concepts -- [[Spatial Computing]]：应用场景 -- [[Vision Pro]]：目标平台 - -## Related Entities -- Apple：框架开发者 - -## Application -3D 渲染、游戏开发、机器学习加速、科学计算可视化 \ No newline at end of file diff --git a/wiki/concepts/Micro-Interaction.md b/wiki/concepts/Micro-Interaction.md deleted file mode 100644 index bc09abf5..00000000 --- a/wiki/concepts/Micro-Interaction.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "Micro-Interaction" -type: concept -tags: [] ---- - -## Definition -微交互设计是指在用户与界面交互时产生的细小、专注的交互瞬间，通过视觉反馈、动画效果提升用户体验。 - -## Examples -- **按钮悬停效果**：光晕扫过、轻微上浮、阴影加深 -- **表单验证庆祝**：成功时显示 ✨ 闪烁动画 -- **加载动画**：带有个性的跳动圆点动画 -- **进度庆祝**：任务完成时显示 🎉 庆祝动画 - -## Design Principles -- 使用 cubic-bezier 缓动函数实现流畅动画 -- 保持动画时长在 0.3-0.5s 范围 -- 动画应服务于功能反馈而非纯粹装饰 -- 需支持 reduced-motion 偏好设置 - -## Related Concepts -- [[Whimsy Taxonomy]] -- [[Easter Egg]] - -## Sources -- [[design-whimsy-injector]] \ No newline at end of file diff --git a/wiki/concepts/Micro-Sprint.md b/wiki/concepts/Micro-Sprint.md deleted file mode 100644 index f9b67a71..00000000 --- a/wiki/concepts/Micro-Sprint.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "Micro-Sprint" -type: concept -tags: [productivity, task-management, cognitive-load] -sources: [product-behavioral-nudge-engine] -last_updated: 2026-04-20 ---- - -## Definition -将大任务拆分为 5 分钟内可完成的微型冲刺单元，降低认知负担，防止用户决策瘫痪。 - -## Mechanism -- 将大量待办事项（如 50 个）拆分为最小可执行单元 -- 每次只推送 1 个单一、可操作、低摩擦的行动项 -- 通过时间盒（5 minutes）创造紧迫感和完成动机 - -## Example -``` -message: "Hey! You've got a few quick follow-ups pending. Let's see how many we can knock out in the next 5 mins. I'll tee up the first draft. Ready?" -actionButton: "Start 5 Min Sprint" -``` - -## Related Concepts -- [[Cognitive Load Reduction]] -- [[Momentum Nudge]] -- [[Pomodoro Technique]] - -## Connections -- [[Behavioral Nudge Engine]] ← implements ← [[Micro-Sprint]] -- [[Habit Tracking & Accountability Partner]] ← uses ← [[Micro-Sprint]] diff --git a/wiki/concepts/Microhistory.md b/wiki/concepts/Microhistory.md deleted file mode 100644 index 8e3d426d..00000000 --- a/wiki/concepts/Microhistory.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: "Microhistory" -type: concept -tags: [history, historiography, methodology] -last_updated: 2026-04-20 ---- - -## Definition -微历史是一种历史研究方法，通过对特定个人、家庭、社区或事件的深入细致研究，揭示更广泛的社会、文化和经济结构。 - -## Origin -- 1960-1970年代兴起于意大利 -- 代表人物：金兹伯格（Carlo Ginzburg）、列维（Emmanuel Le Roy Ladurie） -- 《奶酪与蛆虫》（金兹伯格，1976）是经典之作 - -## Key Characteristics -- 从微观切入：通过具体案例揭示宏观结构 -- 文献密集：利用档案、日记、法院记录等一手资料 -- 反结构主义：强调个体能动性与偶然性 -- 去中心化：关注边缘人群、非主流声音 - -## 与 Macrohistory 的对比 -| 维度 | Microhistory | Macrohistory | -|------|--------------|--------------| -| 视角 | 自下而上 | 自上而下 | -| 对象 | 个人、边缘群体 | 社会结构、国家、文明 | -| 方法 | 深度个案研究 | 计量分析、大规模数据 | -| 局限 | 难以推广 | 可能忽视个体差异 | - -## Application in Worldbuilding -- 为虚构角色提供历史背景深度 -- 通过小人物视角展现大时代 -- 增添历史叙事的真实感和人情味 - -## Example Topics -- 14世纪黑死病期间一个村庄的命运 -- 法国大革命中一个工匠家庭的经历 -- 清朝一个县衙门的日常运作 - -## Related Concepts -- [[Material Culture]]：微历史关注日常生活的物质基础 -- [[Historical Coherence Check]]：验证微历史细节的准确性 -- [[Academic Historian]]：Academic Historian 的方法论工具之一 - -## Source -金兹伯格《奶酪与蛆虫》（1976） diff --git a/wiki/concepts/Miping.md b/wiki/concepts/Miping.md deleted file mode 100644 index b2abf08b..00000000 --- a/wiki/concepts/Miping.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: "Miping" -type: concept -tags: [cryptography, compliance, government-it] -last_updated: 2026-04-20 ---- - -## Definition -Miping（商用密码应用安全性评估）是政府与重要信息系统中对身份认证、传输加密、数据存储加密和密码产品应用情况进行检查评估的合规要求。 - -## Core Points -- 常涉及 SM2、SM3、SM4 等国密算法 -- 电子签章、CA 证书与身份认证常需使用国密体系 -- 往往是系统验收前必须完成的步骤之一 -- 需要将密码应用设计融入整体安全架构 - -## Related Concepts -- [[Compliance Enforcement]] -- [[Government Procurement]] -- [[Digital Government]] - -## Related Entities -- [[Government Digital Presales Consultant]] diff --git a/wiki/concepts/MoSCoW-Method.md b/wiki/concepts/MoSCoW-Method.md deleted file mode 100644 index c5cb112c..00000000 --- a/wiki/concepts/MoSCoW-Method.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "MoSCoW Method" -type: concept -tags: [prioritization, agile, requirements] -sources: [raw/Agent/agency-agents/product/product-sprint-prioritizer.md] -last_updated: 2026-04-20 ---- - -## Definition -需求优先级分类方法，将功能分为四个类别以明确交付优先级。 - -## Categories -- **Must-Have（必须有）**：基本期望，缺失会导致客户不满 -- **Should-Have（应该有）**：重要但不紧急的需求 -- **Could-Have（可以有）**：期望但不关键的功能 -- **Won't-Have（不能有）**：当前 sprint 明确排除的需求 - -## Application -用于 sprint 规划中的故事选择和干系人期望管理，确保核心功能优先交付。 - -## Related Concepts -- [[RICE Framework]] -- [[Kano Model]] -- [[Sprint Planning]] -- [[Product Sprint Prioritizer]] diff --git a/wiki/concepts/MoSCoW优先级.md b/wiki/concepts/MoSCoW优先级.md deleted file mode 100644 index 51cdc5bf..00000000 --- a/wiki/concepts/MoSCoW优先级.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "MoSCoW优先级" -type: concept -tags: [Product Management, Prioritization Framework] -sources: [] -last_updated: 2026-04-20 ---- - -## Definition -MoSCoW是一种需求优先级排序技术，将功能分为四类以确定交付优先级。 - -## Categories -- **Must-have（必须有）**：不满足则产品无法发布的核心功能 -- **Should-have（应该有）**：重要但不紧急的功能 -- **Could-have（可以有）**：期望但不必需的功能 -- **Won't-have（不必须有）**：当前版本不包含的功能 - -## Usage -MoSCoW由 [[Product Feedback Synthesizer]] 用于将用户反馈分类为可交付的功能优先级。 - -## Connections -- [[Product Feedback Synthesizer]]：使用此框架进行反馈分类 -- [[RICE评分]]：另一种优先级框架 -- [[Kano模型]]：基于满意度二维度的功能分类 diff --git a/wiki/concepts/Model-Audit.md b/wiki/concepts/Model-Audit.md deleted file mode 100644 index 04017745..00000000 --- a/wiki/concepts/Model-Audit.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: "Model Audit" -type: concept -tags: [ml-ops, governance, assurance] -sources: [specialized-model-qa] -last_updated: 2026-04-20 ---- - -## Definition -模型审计是一套系统化流程，用于独立验证模型的设计、数据、训练、性能、解释性与业务影响。 - -## Typical Scope -- 文档与治理 -- 数据与标签 -- 特征稳定性 -- 模型复制 -- 校准与性能 -- 可解释性与公平性 -- 业务影响 - -## Use in Model QA -- 提供证据驱动的质量结论 -- 将问题分级并提出修复建议 -- 形成可复核的审计轨迹 - -## Related Concepts -- [[Population Stability Index (PSI)]] -- [[Calibration Testing]] -- [[Discrimination Metrics]] \ No newline at end of file diff --git a/wiki/concepts/Momentum-Nudge.md b/wiki/concepts/Momentum-Nudge.md deleted file mode 100644 index 00501077..00000000 --- a/wiki/concepts/Momentum-Nudge.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: "Momentum Nudge" -type: concept -tags: [gamification, behavioral-psychology, engagement] -sources: [product-behavioral-nudge-engine] -last_updated: 2026-04-20 ---- - -## Definition -即时正向反馈与持续动力构建机制，通过庆祝已完成的任务而非聚焦剩余任务来维持用户动力。 - -## Mechanism -- 庆祝已完成的微任务（如"完成了 5 个！"） -- 立即提供强化反馈 -- 提供清晰的退出选项或继续选项 - -## Example -> "Nice work! We sent 15 follow-ups, wrote 2 templates, and thanked 5 customers. That's amazing. Want to do another 5 minutes, or call it for now?" - -## Success Metrics -- Action Completion Rate（行动完成率） -- User Retention（用户留存） -- Engagement Health（参与健康度） - -## Related Concepts -- [[Micro-Sprint]] -- [[Default Bias]] -- [[Opt-Out Completion]] - -## Connections -- [[Behavioral Nudge Engine]] ← implements ← [[Momentum Nudge]] diff --git a/wiki/concepts/Morning-Briefing.md b/wiki/concepts/Morning-Briefing.md deleted file mode 100644 index 94383452..00000000 --- a/wiki/concepts/Morning-Briefing.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: "Morning Briefing" -type: concept -tags: [automation, reporting, ai-agent] -sources: [self-healing-home-server-infrastructure-management] -last_updated: 2026-04-17 ---- - -## Summary -Morning Briefing（每日简报）是 AI Agent 定时生成的综合报告，包含天气、日历、系统健康、任务状态等信息，在每天早晨自动交付给用户。 - -## Definition -AI Agent 每天定时生成并发送的综合报告，汇总多个数据源的关键信息。 - -## Typical Content -- **天气**：当前条件和预报 -- **日历**：当天事件、冲突检测 -- **系统健康**：CPU/RAM/存储、服务状态、最近部署、告警 -- **任务看板**：昨日完成、进行中、阻塞项 -- **亮点**：夜间脑暴要点、待处理邮件、本周截止 - -## Value -- 用户早晨快速了解全局状态 -- 无需手动检查多个系统 -- 自动化日常信息汇总 -- 支持远程运维（如边遛狗边处理部署问题） - -## Connections -- [[Agentic AI]] ← generates ← [[Morning Briefing]]：AI Agent 生成每日简报 -- [[Cron Jobs]] ← triggers ← [[Morning Briefing]]：定时任务触发简报生成 -- [[K3s]] ← monitored_by ← [[Morning Briefing]]：K3s 集群健康状态包含在简报中 \ No newline at end of file diff --git a/wiki/concepts/Motion-Sickness-Threshold.md b/wiki/concepts/Motion-Sickness-Threshold.md deleted file mode 100644 index c00c08f3..00000000 --- a/wiki/concepts/Motion-Sickness-Threshold.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: "Motion Sickness Threshold" -type: concept -tags: [xr, spatial-computing, ux] -date: 2026-04-20 ---- - -## Definition -运动阈值，眩晕感临界点，是 XR 座舱设计的核心约束指标。 - -## Core Attributes -- 坐姿体验优化 -- 视角锚定机制 -- 舒适度与真实感平衡 - -## Related Concepts -- [[Immersive Cockpit]]：应用场景 - -## Application -评估 XR 体验的眩晕风险，指导座舱设计参数调整 \ No newline at end of file diff --git a/wiki/concepts/Multi-Account-Strategy.md b/wiki/concepts/Multi-Account-Strategy.md deleted file mode 100644 index 903d74af..00000000 --- a/wiki/concepts/Multi-Account-Strategy.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: "Multi-Account Strategy" -type: concept -tags: [AWS, Architecture, Security] -sources: [how-to-simplify-multi-account-deployments-monitoring, how-to-simplify-multi-account-deployments-monitoring-centralized-logs-for-aws-cloudformation-stacksets] -last_updated: 2026-04-16 ---- - -## Summary -多账号策略是 AWS 推荐的企业级云架构模式，通过将工作负载分离到多个 AWS 账号来提升安全性、治理能力和故障隔离。 - -## Definition -Multi-Account Strategy（多账号策略）是指在 AWS Organizations 框架下，使用多个 AWS 账号组织云资源的管理策略，通常包括：管理账号（Management Account）、日志账号（Log Archive Account）、安全账号（Security Account）和多个工作负载账号（Workload Accounts）。 - -## Key Attributes -- **目的**：安全性提升、治理能力增强、故障隔离、成本核算 -- **实现方式**：AWS Organizations + Organizational Units (OU) -- **核心组件**：管理账号、成员账号、组织单元 - -## Why -- 资源隔离：不同业务线、环境（生产/开发/测试）相互隔离 -- 安全边界：最小权限原则，账号间无法相互访问 -- 合规要求：满足 ISO 27001、HIPAA 等合规审计需求 -- 成本追踪：按账号独立核算成本 - -## Connections -- [[AWS Organizations]] ← 组织 ← [[Multi-Account Strategy]] -- [[StackSets]] ← 依赖 ← [[Multi-Account Strategy]] -- [[AWS Organizations]] 是实施多账号策略的核心服务 \ No newline at end of file diff --git a/wiki/concepts/Multi-Agent-Orchestration.md b/wiki/concepts/Multi-Agent-Orchestration.md deleted file mode 100644 index 72440ee6..00000000 --- a/wiki/concepts/Multi-Agent-Orchestration.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "Multi-Agent Orchestration" -type: concept -tags: [multi-agent, orchestration, rust] -date: 2026-03-05 ---- - -## Definition -多 Agent 编排是协调和管理多个 AI Agent 协同工作的技术，Nexus Spatial 使用 Rust 作为高性能 DAG 执行引擎。 - -## Why Rust -- 亚毫秒调度精度 -- 零 GC 暂停，保证响应延迟 -- 内存安全，适合 agent sandboxing -- 适合 CPU 密集型的 DAG 执行 - -## Architecture -- 14-table 数据模型（users, workflows, nodes, edges, executions, etc.） -- 内置 node types: ai_agent, prompt_template, conditional, transform, input/output, human_review, loop, parallel_split/join, webhook_trigger, delay -- WebSocket 实时流，支持 per-channel 序列号、gap 检测、snapshot 恢复 - -## Scaling Targets -- Year 1: 5,000 并发 agent executions, 10,000 WebSocket 连接 -- Year 2: 50,000 并发, 100,000 WebSocket 连接 - -## Related Concepts -- [[Multi-Agent Team]]：协作架构 -- [[Spatial AI Operations]]：应用领域 -- [[Rust]]：实现语言 - -## Related Entities -- [[Nexus Spatial]]：产品实现 diff --git a/wiki/concepts/Multi-Agent-Team.md b/wiki/concepts/Multi-Agent-Team.md deleted file mode 100644 index 4cad3a08..00000000 --- a/wiki/concepts/Multi-Agent-Team.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: "Multi-Agent Team" -type: concept -tags: [] -sources: [multi-agent-team] -last_updated: 2026-04-17 ---- - -## Definition -多 Agent 团队是一种 AI Agent 协作架构，每个 Agent 有独立的角色、人格和优化的模型，通过共享内存和私有上下文实现协同工作。 - -## Core Components - -### Specialized Agents -- 每个 Agent 有 distinct role、personality、model -- 模型选择与任务复杂度匹配（Claude Opus 用于复杂推理，Claude Sonnet 用于快速分析，Gemini 用于网络研究） - -### Shared Memory -- 项目文档、目标、关键决策所有 Agent 可访问 -- 包含：GOALS.md、DECISIONS.md、PROJECT_STATUS.md - -### Private Context -- 每个 Agent 维护自己的对话历史和领域特定笔记 -- 存储在独立目录（如 agents/milo/、agents/josh/） - -### Single Control Plane -- 单一 Telegram 群组，通过 @tag 触发特定 Agent -- 支持 @all 广播，默认 @milo（团队lead）处理 - -### Scheduled Tasks -- Agent 主动工作而非被动响应 -- 定时任务示例：Milo 早8点晨会总结、Josh 早9点关键指标、Marketing 早10点内容创意 - -## Key Insights -- **Personality matters**: 鲜明人格让与 Agent 交互更像与团队对话 -- **Shared memory + private context**: 组合关键，共享建立共同基础，私有积累领域专业知识 -- **Right model for right job**: 便宜模型做简单任务 -- **Start with 2, not 4**: lead + one specialist 开始，识别瓶颈后再扩展 - -## Related Concepts -- [[Agent Chain]]：多个 Agent 串联工作 -- [[Shared Memory]]：团队共享上下文 -- [[Scheduled Tasks]]：定时任务机制 -- [[OpenClaw]]：支持多 Agent 协调的工具 -- [[Civil Engineer]]：多智能体体系中的专业化工程角色案例 \ No newline at end of file diff --git a/wiki/concepts/Multi-Agent-Workflow.md b/wiki/concepts/Multi-Agent-Workflow.md deleted file mode 100644 index 73e3c52e..00000000 --- a/wiki/concepts/Multi-Agent-Workflow.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: "Multi-Agent Workflow" -type: concept -tags: [multi-agent, workflow, coordination] -last_updated: 2026-04-21 ---- - -## Definition -Multi-Agent Workflow 是一种多智能体协作架构，多个专业 Agent 通过分阶段并行工作实现复杂任务交付。每个 Agent 有独立角色、人格、优化的模型，通过共享内存+私有上下文实现协同。 - -## Key Components -- **独立角色**：每个 Agent 承担特定专业职责 -- **并行工作**：独立任务同时执行 -- **顺序交接**：依赖任务按序传递 -- **共享上下文**：通过共享内存保持信息一致性 - -## Pattern Types -- Parallel Kickoff：多个工作流同时启动 -- Merge Point：多输入汇合触发下一阶段 -- Feedback Loop：审查后迭代修改 -- Quality Gates：设置检查点确保质量 - -## Connections -- [[Multi-Agent Team]]：相关概念 -- [[Parallel Kickoff]]：并行启动模式 -- [[Merge Point]]：合并依赖点 -- [[Feedback Loop]]：反馈迭代机制 - diff --git a/wiki/concepts/Multi-Channel-Personal-Assistant.md b/wiki/concepts/Multi-Channel-Personal-Assistant.md deleted file mode 100644 index ad1dc0b5..00000000 --- a/wiki/concepts/Multi-Channel-Personal-Assistant.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "Multi-Channel Personal Assistant" -type: concept -tags: [AI助理, 多渠道] -last_updated: 2026-04-17 ---- - -## Definition -多渠道个人助手是一种 AI Agent 工作模式，通过统一接口整合多个通信渠道（消息、日历、邮件、任务管理等），解决应用切换疲劳问题。 - -## Key Characteristics -- 统一对话入口（Telegram 等） -- 多渠道任务、日程、消息、提醒统一管理 -- 与外部服务（Asana、Todoist、Google Workspace、Slack 等）深度集成 -- Context 跨渠道保持 - -## Related Concepts -- [[Agent Chain]] -- [[Multi-Agent Team]] -- [[Context Memory]] - -## Connections -- [[Asana]] — 项目管理集成 -- [[Multi-Channel Assistant]] — Source page diff --git a/wiki/concepts/Multi-Channel-Support.md b/wiki/concepts/Multi-Channel-Support.md deleted file mode 100644 index 53f49ba3..00000000 --- a/wiki/concepts/Multi-Channel-Support.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -id: multi-channel-support -title: "Multi-Channel Support Framework" -type: concept -tags: [customer-service, support, framework] -sources: [support-support-responder.md] -last_updated: 2026-04-21 ---- - -## Definition -全渠道客户支持框架（Multi-Channel Support Framework），跨 email、live chat、phone、social media、in-app messaging 统一提供一致服务质量的客户支持架构。 - -## Support Channels -| Channel | Response Time SLA | Key Features | -|---------|------------------|--------------| -| Email | 2 hours | 优先级路由、工单跟踪 | -| Live Chat | 30 seconds | 并发限制 3、自动化路由 | -| Phone | 3 rings | 回拨选项、优先级队列 | -| Social Media | 1 hour | 关键词监控、私下升级 | -| In-App Messaging | 即时 | 上下文帮助、主动触发 | - -## Core Components -- Support Tiers：Tier 1（通用）、Tier 2（技术）、Tier 3（专家）的分层支持 -- Priority Routing：企业客户 > 计费问题 > 技术紧急情况 -- SLA Compliance：响应时间和解决时间的双重 SLA 监控 - -## Key Metrics -- First Response Time：首次响应平均时间 -- Resolution Time：从创建到解决的总时间 -- First Contact Resolution Rate：首次联系解决百分比 -- Customer Satisfaction (CSAT)：客户满意度评分 - -## Connections -- [[Support Responder]] — 实现该框架的核心智能体 -- [[Customer Success]] — 框架的服务目标 -- [[Knowledge Base Management]] — 框架的支持系统 \ No newline at end of file diff --git a/wiki/concepts/Multi-Cloud.md b/wiki/concepts/Multi-Cloud.md deleted file mode 100644 index 2d9701ce..00000000 --- a/wiki/concepts/Multi-Cloud.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -title: "Multi-Cloud" -type: concept -tags: [Cloud, Deployment-Model] -sources: [Cloud-Maturity-Model-A-Detailed-Guide-For-Cloud-Adoption, How-Can-a-Multi-Cloud-Strategy-Transform-Your-Business-ROI] -last_updated: 2025-03-01 ---- - -## Summary -Multi-Cloud（多云）是一种使用多个云服务商服务的云计算部署策略，通过同时利用多个公有云提供商（如AWS、Azure、Google Cloud）的优势服务，避免单一供应商锁定，提升灵活性、弹性和成本效率。 - -## Definition -多云策略指同时使用多个云服务商（Azure、GCP、AWS等）的服务，而非依赖单一提供商。该策略允许企业根据具体需求选择各提供商的优势服务，如计算、存储、AI工具等，以提升效率、安全性和性能。 - -## Key Benefits -1. **避免供应商锁定（Vendor Lock-In）**：不依赖单一供应商，可自由选择最佳服务 -2. **提升弹性和可靠性**：单一提供商故障时其他提供商继续服务 -3. **增强安全性**：在不同环境部署不同安全机制 -4. **可扩展性**：快速适应需求波动 -5. **成本优化**：利用竞争性定价，报告示例如优化后可达30%运营成本降低 -6. **访问创新能力**：利用不同提供商的不同功能、工具和服务 -7. **满足监管合规**：支持地区和行业特定的数据主权要求 -8. **性能优化**：为不同工作负载选择最佳提供商 - -## Implementation Steps -1. **评估需求**：识别目标、预算分析、资源要求 -2. **选择提供商**：对齐服务与需求，评估功能、安全、合规、成本 -3. **集成与管理**：采用Kubernetes、Terraform等工具进行集成 -4. **监控与优化**：持续跟踪性能、成本，如使用CloudHealth或Datadog - -## Industry Use Cases -- **电商**：高峰期（如黑色星期五）弹性扩展 -- **医疗**：HIPAA合规，区域数据主权 -- **金融**：安全强化、严格合规要求、投资回报最大化 - -## Challenges -- 集成复杂性：需处理兼容性问题 -- 安全风险：需统一安全策略 -- 专业人才缺乏：需多云管理技能 - -## Connections -- [[Multi-Cloud]] ← type_of ← [[Cloud-Adoption]] -- [[Multi-Cloud]] ← depends_on ← [[AWS]], [[Azure]], [[Google Cloud]] -- [[Multi-Cloud]] ← enables ← [[DevOps]] -- [[Multi-Cloud]] ← relates_to ← [[Cloud Security]] -- [[Multi-Cloud]] ← relates_to ← [[Vendor Lock-In]] -- [[Multi-Cloud]] ← relates_to ← [[Data Sovereignty]] diff --git a/wiki/concepts/Multi-Jurisdictional-Compliance.md b/wiki/concepts/Multi-Jurisdictional-Compliance.md deleted file mode 100644 index ab00908b..00000000 --- a/wiki/concepts/Multi-Jurisdictional-Compliance.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: "Multi-Jurisdictional Compliance" -type: concept -tags: [compliance, legal, multi-jurisdiction, regulatory] -sources: [support-legal-compliance-checker] -last_updated: 2026-04-21 ---- - -## Concept Summary -多司法管辖区合规指企业在多个国家/地区运营时，需要同时满足不同司法管辖区的法律法规要求的管理方法。 - -## Key Dimensions -- **监管框架**：GDPR（欧盟）、CCPA（加州）、HIPAA（医疗）、SOX（财务）、PCI-DSS（支付） -- **数据保护**：数据主体权利（访问、更正、删除、可携带）、数据本地化要求 -- **跨境传输**：Standard Contractual Clauses、adequacy decisions、数据驻留要求 -- **审计追踪**：决策文档化、法规引用、审批流程 - -## Compliance Assessment Template -监管合规评估报告包含： -1. Executive Summary（合规状态概述、风险评估总结） -2. Detailed Compliance Analysis（数据保护、行业特定合规、合同审查） -3. Risk Mitigation Strategies（关键风险领域、框架改进） -4. Implementation Roadmap（30天/90天/180+天阶段） - -## Relationship to Related Concepts -- [[Privacy Policy Generator]]：多辖区合规的具体实施工具 -- [[Contract Review System]]：跨境合同风险评估 -- [[GDPR Compliance Framework]]：欧盟数据保护核心框架 \ No newline at end of file diff --git a/wiki/concepts/Multi-Tenant-Management.md b/wiki/concepts/Multi-Tenant-Management.md deleted file mode 100644 index 1fadf6ee..00000000 --- a/wiki/concepts/Multi-Tenant-Management.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "Multi-Tenant Management" -type: concept -tags: [SaaS, multi-tenancy, isolation] -sources: [How-Agentic-AI-can-help-for-Cloud-DevOps] -last_updated: 2026-04-16 ---- - -## Summary -Multi-Tenant Management（多租户管理）是 SaaS 环境中自动化管理多个客户租户的隔离、配置、计费和生命周期流程的实践。 - -## Definition -在共享基础设施上为多个客户提供隔离的 SaaS 服务，包括租户配置、监控、计费和下线管理。 - -## Key Processes -- **Self-Service Tenant Provisioning**：租户自助配置 -- **Tenant Isolation**：确保租户间数据和资源隔离 -- **Automated Tenant Decommissioning**：自动化租户下线 -- **Multi-Tenant Cost Optimization**：多租户成本分摊和优化 - -## Connections -- [[Agentic AI]] ← automates ← [[Multi-Tenant Management]]：Agentic AI 自动化多租户管理 -- [[SaaS]] ← requires ← [[Multi-Tenant Management]]：SaaS 依赖多租户管理 -- [[Serverless Computing]] ← enables ← [[Multi-Tenant Management]]：Serverless 实现多租户成本优化 diff --git a/wiki/concepts/N8N-节点.md b/wiki/concepts/N8N-节点.md deleted file mode 100644 index b0934ebb..00000000 --- a/wiki/concepts/N8N-节点.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: "N8N 节点" -type: concept -tags: [n8n, workflow, node] ---- - -## Definition -N8n 工作流自动化平台的基本构建单元。每个节点执行特定任务，通过可视化方式连接形成完整的工作流。 - -## Node Types（节点类型） - -### 1. Trigger（触发器） -- 触发工作流执行的入口 -- 示例：Webhook、Telegram、Schedule - -### 2. Action（操作节点） -- 执行具体的操作 -- 示例：发送邮件、写入数据库 - -### 3. Utility（工具节点） -- 数据转换和处理 -- 示例：JSON、Date Time、Item Lists - -### 4. Code（代码节点） -- 自定义 JavaScript/Python 代码 -- 实现复杂逻辑 - -### 5. Advanced AI（高级 AI 节点） -- AI Agent 专用节点 -- 支持 LLM 调用、工具调用、记忆模块 - -## Importance -节点分类使自动化工作流设计更加结构化和高效。理解每种节点的作用是构建有效 AI Agent 的前提。 - -## Connected Pages -- [[n8n]] — 使用节点构建工作流 -- [[N8N Full Tutorial Building AI Agents in 2025 for Beginners!]] — 教程详细解释了节点分类 \ No newline at end of file diff --git a/wiki/concepts/NFR.md b/wiki/concepts/NFR.md deleted file mode 100644 index 8c256571..00000000 --- a/wiki/concepts/NFR.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -id: nfr -title: "NFR（非功能需求）" -type: concept -tags: [sre, requirements, reliability] -last_updated: 2026-04-19 ---- - -## Definition -NFR（Non-Functional Requirements，非功能需求）是评判系统运行状况的标准，决定可用性、性能、安全性、可扩展性等属性。 - -## Key Aspects -- **可用性（Availability）**：系统正常运行时间比例（如 99.9%、99.99%） -- **性能（Performance）**：响应时间、吞吐量等 -- **安全性（Security）**：数据加密、访问控制等 -- **可扩展性（Scalability）**：水平/垂直扩展能力 - -## Cloud Context -在云端，NFR 应更规范化，利用云原生服务： -- AWS Backup 定义备份策略和测试频率 -- DR 规划包含季度测试和 IaC 基础设施 -- NFR Epic 集成到 Sprint backlog - -## Relationship with SRE -- [[SRE]] 通过 [[Error Budget（错误预算）]] 和 [[SLO（服务等级目标）]] 实现 NFR -- [[混沌工程]] 验证 NFR 是否满足 - -## References -- [[CTP Topic 41 NFR's and Error Budgets]] — NFR 在云和敏捷开发中的应用 -- [[Brendan Standing]] — Micro Focus SRE 负责人 \ No newline at end of file diff --git a/wiki/concepts/NFS永久挂载.md b/wiki/concepts/NFS永久挂载.md deleted file mode 100644 index e55ab32b..00000000 --- a/wiki/concepts/NFS永久挂载.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: "NFS永久挂载" -type: concept -tags: [mount, nfs, fstab] -date: 2026-04-16 ---- - -## Definition -NFS 永久挂载是指通过配置文件实现网络文件系统（NFS）在系统开机时自动挂载，而不是依赖手动执行 mount 命令。Linux 系统通过 /etc/fstab 文件管理所有文件系统挂载点。 - -## Implementation -在 /etc/fstab 中添加配置行： -``` -192.168.3.17:/volume2/backup /mnt/nas_backup nfs defaults,timeo=900,retrans=5,_netdev 0 0 -``` - -## Key Parameters -- **defaults**：使用默认挂载参数（rw, suid, dev, exec, auto, nouser, async） -- **timeo=900**：超时时间 90 秒（单位 1/10 秒） -- **retrans=5**：超时重试次数 5 次 -- **_netdev**：关键参数，指定为网络设备，等待网络服务启动后再挂载 - -## Why _netdev is Critical -_netdev 参数告诉系统： -1. 这是一个网络文件系统 -2. 必须等到网络服务完全启动后再尝试挂载 -3. 防止开机过程因网络未就绪而卡死 - -## Testing -```bash -# 卸载当前挂载 -sudo umount /mnt/nas_backup -# 模拟开机挂载 -sudo mount -a -# 验证挂载 -df -h | grep nas_backup -``` - -## Common Issues -- **挂载失效**：nfs-common 服务启动慢于 mount -a 执行 -- **解决**：启用 remote-fs.target 服务：`sudo systemctl enable remote-fs.target` - -## Related Entities -- [[NFS]]：网络文件系统协议 -- [[NAS]]：网络附加存储设备 - diff --git a/wiki/concepts/NPS分析.md b/wiki/concepts/NPS分析.md deleted file mode 100644 index b8f7668b..00000000 --- a/wiki/concepts/NPS分析.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: "NPS分析" -type: concept -tags: [Customer Analytics, Loyalty Metric] -sources: [] -last_updated: 2026-04-20 ---- - -## Definition -NPS（Net Promoter Score，净推荐值）是一种衡量用户忠诚度和推荐意愿的指标。 - -## Calculation -- ** promoters（推荐者）**：评分9-10分，忠诚用户 -- **passives（被动者）**：评分7-8分，满意但不主动推荐 -- **detractors（贬低者）**：评分0-6分，不满意用户 - -``` -NPS = 推荐者百分比 - 贬低者百分比 -``` - -取值范围：-100 到 +100 - -## Usage -NPS由 [[Product Feedback Synthesizer]] 用于衡量用户忠诚度和反馈洞察的业务影响，相关指标：反馈洞察提升 NPS 10+ 分。 - -## Success Criteria -- NPS > 0：良好 -- NPS > 50：优秀 -- NPS > 70：世界级 - -## Connections -- [[Product Feedback Synthesizer]]：使用NPS衡量反馈分析效果 -- [[CSAT]]：另一种客户满意度指标 -- [[CES]]：客户努力程度指标 -- [[流失预测]]：基于满意度建模的流失预警 diff --git a/wiki/concepts/NRR.md b/wiki/concepts/NRR.md deleted file mode 100644 index d96cb957..00000000 --- a/wiki/concepts/NRR.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: "NRR (Net Revenue Retention)" -type: concept -tags: [metrics, revenue, saas, retention] -date: 2026-04-20 ---- - -## Definition -NRR（Net Revenue Retention，净收入留存率）是 SaaS 行业的终极成功指标，在单个数字中捕获扩展、收缩和流失。 - -## Formula -``` -NRR = (Starting ARR + Expansion - Contraction - Churn) / Starting ARR × 100% -``` - -## Target Benchmarks -- 优秀：120%+ -- 良好：100-120% -- 警惕：<100% - -## NRR Optimization Strategies -- **Expansion**：向上销售、交叉销售 -- **Contraction Management**：提前识别并干预 -- **Churn Prevention**：预警信号监控和主动干预 - -## Related Concepts -- [[Land-and-Expand]]：扩展策略 -- [[Account Health Score]]：账户健康评分 - -## References -- [[Sales Account Strategist]] \ No newline at end of file diff --git a/wiki/concepts/Nano-Banana-2.md b/wiki/concepts/Nano-Banana-2.md deleted file mode 100644 index 6aaaedc3..00000000 --- a/wiki/concepts/Nano-Banana-2.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: "Nano Banana 2" -type: concept -tags: [ai, image-generation] -sources: [全网最全-Nano-Banana-2-使用指南-2025年12月更新-1.md] -last_updated: 2025-12-19 ---- - -## Summary -Google 发布的推理型图像生成模型（正式代号 Gemini 3 Pro Image），是 Nano Banana 系列的第二代产品。与传统图像模型不同，Nano Banana 2 在生成图像前会进行内部推理，自动补完用户的深层次需求。 - -## Key Capabilities -- **推理能力**：生成图像前进行内部推理，思考用户给出的提示词并自动补完深层次需求 -- **更高图像质量**：相比第一代大幅提升 -- **多语言长文本渲染**：支持复杂的中文界面和长文本渲染 -- **高分辨率输出**：支持 1K、2K、4K 分辨率 -- **多图像组合**：最多可将 14 张输入图像组合为 1 张输出图像 -- **最新知识支持**：根据最新知识库进行填充 -- **中文界面生成**：擅长生成复杂的中文界面 - -## Use Cases -- 科研配图生成 -- 技术路线图绘制 -- 教学插画制作 -- 儿童绘本创作 -- 电商配图设计 -- 海报生成 -- 漫画生成 -- 游戏界面伪造 -- 监控录像画面模拟 -- 顶刊科研配图 - -## Connections -- [[Google]] ← publishes -- [[Gemini 3 Pro Image]] ← is_also_known_as -- [[DeepSider]] ← provides_access (国内访问) -- [[Nano Banana Pro]] ← is_preceded_by - -## Aliases -- Gemini 3 Pro Image -- Nano2 \ No newline at end of file diff --git a/wiki/concepts/Nano-Banana-Pro.md b/wiki/concepts/Nano-Banana-Pro.md deleted file mode 100644 index 6f90403c..00000000 --- a/wiki/concepts/Nano-Banana-Pro.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: "Nano Banana Pro" -type: concept -tags: [ai, image-generation] -sources: [google-nano-banana-pro-prompt-guide.md] -last_updated: 2025-12-18 ---- - -## Summary -Google 生成式 AI 团队发布的专业级图像生成模型，从"趣味性"图像生成转向"功能性"专业资产生产。支持文本渲染、角色一致性、视觉合成、世界知识（搜索）和高分辨率（4K）输出。 - -## Key Capabilities -- **意图理解引擎**：物理规则推演、构图美学理解、语义上下文推理 -- **文本渲染**：SOTA 级别的清晰易读、风格化文本渲染 -- **角色一致性**：最多 14 张参考图像（6 张高保真度），身份锁定 -- **信息锚定**：利用 Google 搜索，基于实时数据生成图像 -- **高级编辑**：语义指令进行复杂编辑（图像修补、着色、风格转换） -- **维度转换**：2D 示意图与 3D 可视化之间的转换 -- **高分辨率**：原生 1K 至 4K 图像生成 -- **思考模式**：渲染前生成临时思考图像优化构图 - -## Connections -- [[Google]] ← publishes -- [[提示词黄金法则]] ← applies to -- [[文本渲染]] ← capability of -- [[角色一致性]] ← capability of -- [[信息锚定]] ← capability of -- [[4K分辨率]] ← supports \ No newline at end of file diff --git a/wiki/concepts/Negative-Keyword-Architecture.md b/wiki/concepts/Negative-Keyword-Architecture.md deleted file mode 100644 index 5b82cbe6..00000000 --- a/wiki/concepts/Negative-Keyword-Architecture.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: "Negative Keyword Architecture" -type: concept -tags: [Paid Media, Search Advertising, Campaign Management] ---- - -## Definition -分层否定关键词列表的系统化构建方法，用于阻止不相关搜索查询触发广告展示，是付费搜索账户优化的关键机制。 - -## Tier Structure -- **Account-Level**：整个账户通用 -- **Campaign-Level**：特定活动级别 -- **Ad Group-Level**：特定广告组级别 -- **Shared Negative Lists**：跨活动共享的否定列表 - -## Best Practices -- 定期审计和更新否定关键词列表 -- 检测否定关键词与正面关键词的冲突 -- 使用决策树结构（if query contains X AND Y, negative at level Z） -- 按意图阶段分层管理（信息型查询通常需要否定） - -## Related Concepts -- [[Search Term Analysis]] -- [[Query Sculpting]] -- [[Intent Classification]] - -## Related Entities -- [[Search Query Analyst]] \ No newline at end of file diff --git a/wiki/concepts/Negative-Prompt-Library.md b/wiki/concepts/Negative-Prompt-Library.md deleted file mode 100644 index b6372ed3..00000000 --- a/wiki/concepts/Negative-Prompt-Library.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: "Negative Prompt Library" -type: concept -tags: [AI Generation, Prompt Engineering] -date: 2026-04-20 ---- - -## Definition -针对图像和视频平台的显式负向提示库，用于阻止"AI 怪异感"（AI weirdness）并确保生成内容符合预期标准。 - -## Key Categories -- **克隆面孔约束**：no duplicate faces, no cloned faces, distinct facial structures -- **文本约束**：no text, no symbols, no generated signs, no gibberish -- **构图约束**：no hero-symbol composition, no oversized cultural symbols -- **物理约束**：no extra fingers, no distorted hands, no unnatural lighting -- **风格约束**：no stock photo tropes, no futuristic/sci-fi tropes, no generic smiles - -## Usage -在提示词中添加负向约束需要使用平台特定的语法： -- Midjourney：--no 参数 -- Stable Diffusion：negative prompt 字段 -- Sora/Runway：在提示词中明确排除 - -## Related Concepts -- [[InclusiveVisualsSpecialist]] — 使用此库的角色 -- [[CloneFaces]] — 此库解决的主要问题之一 -- [[GibberishText]] — 此库解决的主要问题之一 -- [[PhysicalRealityConstraints]] — 视频生成中的相关约束类型 \ No newline at end of file diff --git a/wiki/concepts/Network-Segregation.md b/wiki/concepts/Network-Segregation.md deleted file mode 100644 index acb59669..00000000 --- a/wiki/concepts/Network-Segregation.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: "Network Segregation" -type: concept -tags: - - Network-Security - - AWS ---- - -## Definition -网络隔离是通过防火墙或其他安全设备控制不同网络区域之间通信的安全策略，确保敏感 workloads 与不受信任的网络区域分离。 - -## Application -在 AWS Landing Zone 环境中，通过 Checkpoint 防火墙控制服务器间通信（server-to-server communications），阻断内部网络（on-prem、VPN）直接访问 AWS 生产网段。 - -## Related Concepts -- [[Checkpoint-Firewall]] -- [[SPI-Features]] -- [[AWS-Landing-Zone]] - -## Related Entities -- [[AWS]] \ No newline at end of file diff --git a/wiki/concepts/Node-Classes.md b/wiki/concepts/Node-Classes.md deleted file mode 100644 index 39881390..00000000 --- a/wiki/concepts/Node-Classes.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "Node Classes" -type: concept -tags: [Kubernetes, Karpenter, EC2, Instance-Configuration] -sources: [] -last_updated: 2026-04-19 ---- - -## Definition -Node Classes 是 Karpenter 的核心组件，定义 EC2 实例的 provisioning 配置细节。 - -## Key Attributes -- **子网**：实例部署的 subnet -- **节点角色**：IAM 角色和策略 -- **AMI**：Amazon Machine Image（可使用 EKS 优化 AMI 或自定义 AMI） -- **安全组**：实例附加的安全组 - -## Related Concepts -- [[Node-Pools]]：定义调度约束和容量限制 -- [[Karpenter]]：使用 Node Classes 的 compute management tool -- [[AMI]]：Amazon Machine Image - -## Aliases -- Node Classes -- Karpenter Node Classes \ No newline at end of file diff --git a/wiki/concepts/Node-Pool.md b/wiki/concepts/Node-Pool.md deleted file mode 100644 index 13b84444..00000000 --- a/wiki/concepts/Node-Pool.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "Node Pool" -description: EKS Auto Mode 的节点池概念，用于管理一组相同配置的 Kubernetes 节点 -type: concept -tags: - - AWS - - EKS - - Kubernetes ---- - -## Definition -Node Pool（节点池）是 EKS Auto Mode 中管理一组相同配置节点的概念。默认包含两个节点池：general purpose 和 system，还有一个节点类。 - -## Default Configuration -- **General Purpose 节点池**：默认锁定 AMD64 架构，支持自定义节点池用于 Graviton 实例 -- **System 节点池**：带有 taint，系统插件需要相应的 tolerations -- **节点类**：默认创建一个节点类 - -## Behavior -- 默认节点池不可变，配置为零权重，允许自定义节点池被优先使用 -- 实例动态确定和自动整合 -- 优化计算成本 - -## Relationship -- 由 [[Carpenter]] 管理 -- 运行 [[BottleRocket]] 操作系统 -- 属于 [[EKS-Auto-Mode]] - -## References -- [[public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks-auto-mode]] \ No newline at end of file diff --git a/wiki/concepts/Node-Pools.md b/wiki/concepts/Node-Pools.md deleted file mode 100644 index 9cbfd30f..00000000 --- a/wiki/concepts/Node-Pools.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "Node Pools" -type: concept -tags: [Kubernetes, Karpenter, Compute-Management] -sources: [] -last_updated: 2026-04-19 ---- - -## Definition -Node Pools 是 Karpenter 的核心组件，定义 Kubernetes 集群中节点的调度约束和容量限制。 - -## Key Attributes -- **调度约束**：定义哪些 Pod 可以调度到该节点池 -- **容量限制**：定义节点池的最大/最小节点数 -- **实例类型**：指定可使用的 EC2 实例类型 -- **可用区**：定义节点部署的可用区 - -## Use Cases -- 单节点池：统一的工作负载 -- 混合节点池：计算+加速节点 -- 隔离节点池：基于成本、安全或多租户的隔离 - -## Related Concepts -- [[Node-Classes]]：定义实例配置细节 -- [[Karpenter]]：使用 Node Pools 的 compute management tool -- [[Consolidation-Policies]]：节点整合策略 - -## Aliases -- Node Pools -- Karpenter Node Pools \ No newline at end of file diff --git a/wiki/concepts/Node-js.md b/wiki/concepts/Node-js.md deleted file mode 100644 index 28445ef4..00000000 --- a/wiki/concepts/Node-js.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: "Node.js" -type: concept -tags: [javascript, runtime, server-side] -last_updated: 2026-04-17 ---- - -## 定义 -Node.js 是基于 Chrome V8 引擎的 JavaScript 运行时，用于构建快速、可扩展的网络应用和服务端代码。 - -## 核心特性 -- 事件驱动、非阻塞 I/O 模型 -- 跨平台（Windows、Linux、macOS） -- 前后端统一 JavaScript 语言 -- 丰富的 npm 生态系统 - -## 常用版本管理工具 -- [[nvm]]：Node 版本管理器，推荐用于多版本环境 -- n：Node 版本管理工具 - -## 常用包管理工具 -- [[npm]]：Node 包管理器 -- [[npx]]：Node 包执行工具 - -## 常用进程管理工具 -- [[pm2]]：Node 进程管理器 - -## 关联 -- 基于：V8 引擎 -- 框架：Express、FastAPI（Python）、NestJS -- 场景：服务端开发、CLI 工具、AI Agent diff --git a/wiki/concepts/Nudge-Sequence-Logic.md b/wiki/concepts/Nudge-Sequence-Logic.md deleted file mode 100644 index ab1f7d78..00000000 --- a/wiki/concepts/Nudge-Sequence-Logic.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: "Nudge Sequence Logic" -type: concept -tags: [multi-channel, user-engagement, personalization] -sources: [product-behavioral-nudge-engine] -last_updated: 2026-04-20 ---- - -## Definition -多渠道触达用户的序列逻辑，根据用户响应情况自动切换沟通渠道和频率。 - -## Logic Example -``` -Day 1: SMS（高触达率渠道） -Day 3: Email（书面记录渠道） -Day 7: In-App Banner（应用内提醒） -``` - -## Adaptation Rules -- 如果用户停止响应每日 SMS nudges -- 自动切换为每周邮件摘要 -- 暂停主动推送并询问用户偏好调整 - -## Related Concepts -- [[UserProfile]] -- [[Behavioral Nudge Engine]] - -## Connections -- [[Behavioral Nudge Engine]] ← uses ← [[Nudge Sequence Logic]] diff --git a/wiki/concepts/Nunchi-Reading-Context.md b/wiki/concepts/Nunchi-Reading-Context.md deleted file mode 100644 index 1dcdc218..00000000 --- a/wiki/concepts/Nunchi-Reading-Context.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: "Nunchi（눈치）" -id: nunchi-reading-context -type: concept -tags: [korea, business, communication, culture] -sources: [[specialized-korean-business-navigator]] -last_updated: 2026-04-20 ---- - -## Definition -Nunchi（눈치，字面意思"用眼力测量"）是阅读情境和情感上下文的能力，在韩国商务中至关重要。它涉及从非语言线索、语气、沉默和上下文推断真实意图。 - -## Core Principle -韩国商务沟通优先和谐而非清晰——人们不会直接说"不"，而是通过间接表达保护双方关系和面子。 - -## Communication Decoder - -| 韩国表达 | 字面意思 | 实际含义 | 应对 | -|---|---|---|---| -| 좋은데요... | "That's nice, but..." | 犹豫，有顾虑 | 询问具体顾虑 | -| 검토해보겠습니다 | "We'll review it" | 可能是拒绝，体面退出 | 等待5天，无跟进则放弃 | -| 긍정적으로 검토하겠습니다 | "We'll review positively" | 真正有兴趣，内部流程启动 | 主动发送支持材料 | -| 어려울 것 같습니다 | "It seems difficult" | 明确拒绝 | 体面接受，保留关系 | -| 한번 보고 드려야 할 것 같습니다 | "I need to report upward" | 决策权不在此人，품의流程触发 | 好信号，提供所需材料 | - -## Cultural Context -- **沉默不是拒绝**：3-7天沉默意味着内部讨论正在进行 -- **"Yes"不等于同意**：韩国式同意可能是礼貌性回应 -- **走廊决策**：真正决策发生在会议之外 -- **关系优先**：合同是关系的结果而非原因 - -## Development Path -外国专业人员应逐步培养独立nunchi能力，使Agent的干预必要性随时间降低。 - -## Related Concepts -- [[품의（共识审批）]] -- [[关系生命周期]] -- [[KakaoTalk商务沟通]] \ No newline at end of file diff --git a/wiki/concepts/OAuth.md b/wiki/concepts/OAuth.md deleted file mode 100644 index fea49105..00000000 --- a/wiki/concepts/OAuth.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -title: "OAuth" -type: concept -tags: [authentication, authorization, google] -sources: [] ---- - -## Definition -OAuth（开放授权）是一种授权机制，允许第三方应用在获得用户授权后访问其 Google 账号中的敏感信息，而无需提供密码。 - -## Context -- 在 gog CLI 配置中用于授权访问 Google Workspace 六大服务 -- Google OAuth 需要创建 OAuth 客户端 ID 并下载 credentials.json -- 未验证的 Google 应用需要添加测试用户才能完成授权 - -## Connections -- [[GOG-CLI-安装配置指南]] ← 授权机制于 ← [[OAuth]] -- [[Google-Cloud-Console]] ← 创建凭证于 ← [[OAuth]] \ No newline at end of file diff --git a/wiki/concepts/OLAP.md b/wiki/concepts/OLAP.md deleted file mode 100644 index a117a201..00000000 --- a/wiki/concepts/OLAP.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: "OLAP" -type: concept -tags: [数据库, 数据分析] -sources: [ctp-topic-68-introduction-to-redshift] -last_updated: 2026-04-18 ---- - -## Summary - -OLAP（Online Analytical Processing，在线分析处理）是一种用于支持复杂分析查询和决策支持的数据库技术。 - -## Definition - -- **全称**：Online Analytical Processing -- **用途**：数据挖掘、报表分析、复杂查询 -- **对比**：OLTP（在线事务处理） - -## Key Features - -- 支持多维分析 -- 适合聚合和汇总查询 -- 处理大量历史数据 -- 支持复杂 SQL 查询 - -## Connections - -- [[AWS-Redshift]] → 支持 → [[OLAP]] \ No newline at end of file diff --git a/wiki/concepts/OS-Hardening.md b/wiki/concepts/OS-Hardening.md deleted file mode 100644 index b15f7729..00000000 --- a/wiki/concepts/OS-Hardening.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: "OS Hardening" -type: concept -tags: [Security, Linux, AWS] ---- - -## Definition -OS Hardening（操作系统加固）是通过关闭不必要服务、优化内核参数和应用安全补丁来减少系统攻击面的技术过程。 - -## Techniques -- 关闭不必要的端口和服务 -- 优化内核参数 -- 应用安全补丁 -- 配置防火墙规则 -- 禁用弱协议和算法 -- 实施最小权限原则 - -## Related Concepts -- [[Foundation AMI]] — 应用 OS Hardening 的目标镜像 -- [[CIS Benchmarks]] — 安全配置基准 -- [[Standard AMI]] — 企业标准化镜像 \ No newline at end of file diff --git a/wiki/concepts/Observability-Engineering.md b/wiki/concepts/Observability-Engineering.md deleted file mode 100644 index d2724c55..00000000 --- a/wiki/concepts/Observability-Engineering.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: "Observability Engineering" -type: concept -tags: [monitoring, sre] ---- - -## Definition -可观测性工程是通过收集、分析和利用系统运行时数据（指标、日志、追踪）来持续理解系统健康状态的能力。 - -## Three Pillars -1. **Metrics（指标）**：数值型数据，如 CPU 使用率、请求延迟 -2. **Logs（日志）**：事件记录，详细描述系统活动 -3. **Traces（追踪）**：请求在系统中的完整调用链路 - -## Goal -不仅知道"系统是否正常运行"，更能理解"系统为什么这样运行"，实现： -- 问题快速定位 -- 根因分析 -- 主动式运维 -- 容量规划 - -## Related Tools -- Prometheus：指标收集和存储 -- Grafana：可视化 -- Jaeger：分布式追踪 -- ELK Stack：日志分析 - -## Related Concepts -- [[SRE]]：站点可靠性工程 -- [[Monitoring]]：监控 -- [[Alerting]]：告警 \ No newline at end of file diff --git a/wiki/concepts/Obsidian-CLI.md b/wiki/concepts/Obsidian-CLI.md deleted file mode 100644 index 9af81c53..00000000 --- a/wiki/concepts/Obsidian-CLI.md +++ /dev/null @@ -1,14 +0,0 @@ ---- -title: "Obsidian CLI" -type: concept -tags: [] -sources: ["Obsidian-必装-Skills"] -last_updated: 2026-04-18 ---- - -## Description -Obsidian 官方命令行工具，让 AI Agent 能够直接调用 Obsidian 的命令行接口。通过该工具，AI Agent 可以实现对笔记、任务、属性的增删改查，以及对插件开发环境的调试与管理。 - -## Connections - -- Obsidian CLI 可配合 [[Claude Skills]] 实现 [[TUI]] 交互 \ No newline at end of file diff --git a/wiki/concepts/Obsidian-Skills.md b/wiki/concepts/Obsidian-Skills.md deleted file mode 100644 index 42ef1d55..00000000 --- a/wiki/concepts/Obsidian-Skills.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: "Obsidian Skills" -type: concept -tags: [] -sources: ["Obsidian-必装-Skills"] -last_updated: 2026-04-18 ---- - -## Description -写给 AI Agent 的"说明书"，通过特定技能扩展 AI Agent 操作 Obsidian 的能力。这些 Skills 使 AI 能够执行网页内容抓取、笔记增删改查、数据库视图创建、Mermaid 图表生成、学习系统构建等任务。 - -## Core Skills -- **defuddle**：网页内容清洗工具，剔除广告和导航栏 -- **obsidian-cli**：Obsidian 官方命令行工具 -- **obsidian-bases**：.base 格式数据库配置文件创建 -- **obsidian-markdown**：Obsidian 增强 Markdown 编写 -- **json-canvas**：.canvas 白板文件创建 -- **obsidian-canvas-creator**：解决节点重叠的 Canvas 创建 -- **mermaid-visualizer**：Mermaid 架构图生成 -- **excalidraw-diagram**：手绘风格 Excalidraw 图表 -- **tutor-skills**：学习知识库构建与互动测验 -- **scholar-skill**：学术论文分级阅读 \ No newline at end of file diff --git a/wiki/concepts/Obsidian-插件组合.md b/wiki/concepts/Obsidian-插件组合.md deleted file mode 100644 index e8aac6da..00000000 --- a/wiki/concepts/Obsidian-插件组合.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: "Obsidian 插件组合" -type: concept -tags: [Obsidian, 插件, 知识管理] ---- - -## Description -Obsidian 插件组合是指根据不同使用场景和需求，将 10 款核心插件进行合理搭配以发挥最大效率的策略。 - -## 组合类型 - -### 知识管理流 -- **组合**：Dataview + Templater + Calendar -- **用途**：自动化记录与检索 -- **场景**：适合需要大量笔记管理和检索的用户 - -### 任务管理流 -- **组合**：Kanban + Projects + Outliner -- **用途**：复杂任务拆解与执行 -- **场景**：适合项目管理和多任务处理 - -### 学习研究流 -- **组合**：Spaced Repetition + DB Folder -- **用途**：知识记忆与结构化存储 -- **场景**：适合学习和研究场景 - -## 插件分类 - -### 核心生产力插件（强烈推荐安装） -- [[Templater]]：动态模板插件 -- [[Dataview]]：SQL 查询插件 -- [[Spaced Repetition]]：间隔重复学习插件 -- [[QuickAdd]]：快速添加插件，支持快捷键快速创建笔记 - -### 效率增强插件（推荐按需选择） -- [[Kanban]]：看板视图插件 -- [[Projects]]：项目管理插件 -- [[Outliner]]：大纲视图插件 - -### 信息可视化插件（辅助型插件） -- [[Calendar]]：日历视图插件 -- [[DB Folder]]：数据库文件夹插件 - -### 便利性插件（可选安装） -- [[Homepage]]：主页插件 -- [[File Explorer Note Count]]：文件管理器笔记计数插件 - -## Connections -- [[Obsidian]] → 使用 → [[Obsidian 插件组合]] -- [[Dataview]] ← 替代方案 → [[DB Folder]] -- [[Kanban]] ← 配合使用 → [[Projects]] \ No newline at end of file diff --git a/wiki/concepts/Onboarding.md b/wiki/concepts/Onboarding.md deleted file mode 100644 index f03b2b7f..00000000 --- a/wiki/concepts/Onboarding.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: "Onboarding" -type: concept -tags: [hr, recruiting, onboarding] -sources: [recruitment-specialist] -last_updated: 2026-04-20 ---- - -## Definition -Onboarding 是从 offer 接受、入职准备到试用期内帮助新员工融入组织的标准化流程。 - -## Core Principles -- T-7 到 Day 30 分阶段推进 -- 入职当天完成合同、系统、权限与培训 -- 试用期目标必须清晰且可衡量 -- 以体验和留存为导向设计流程 - -## Related Entities -- [[Recruitment Specialist]] -- [[The Agency]] diff --git a/wiki/concepts/OpenClaw-部署专家.md b/wiki/concepts/OpenClaw-部署专家.md deleted file mode 100644 index 3113e31e..00000000 --- a/wiki/concepts/OpenClaw-部署专家.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: "OpenClaw 部署专家" -type: concept -tags: [openclaw, deployment, troubleshooting] -last_updated: 2026-04-17 ---- - -## Definition -AionUi 内置的 OpenClaw 安装、诊断和修复助手，帮助用户完成 OpenClaw 的初始安装、网关配置、故障排查和远程恢复。 - -## Components -- 安装引导：指导用户完成 OpenClaw 的 npm 安装 -- 诊断功能：运行 openclaw doctor 检测配置问题 -- 修复能力：自动修复配置文件、重启网关 -- 远程救援：通过 WebUI/Telegram 远程执行诊断和修复 - -## Use Cases -- 新用户首次安装 OpenClaw -- OpenClaw 连接失败时的故障排查 -- 无头运行（headless）或远程机器上的 OpenClaw 恢复 -- 配置文件的自动修复 - -## Related -- [[AionUi]] — 部署专家的载体应用 -- [[OpenClaw]] — 被部署和管理的 AI Agent -- [[Remote Rescue]] — 通过远程渠道执行的救援能力 \ No newline at end of file diff --git a/wiki/concepts/OpenSearch.md b/wiki/concepts/OpenSearch.md deleted file mode 100644 index e182f568..00000000 --- a/wiki/concepts/OpenSearch.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "OpenSearch" -type: concept -tags: [Log-Analytics, AWS, Open-Source, Elasticsearch] -date: 2026-04-14 ---- - -## Definition -OpenSearch 是 AWS 的开源日志分析和搜索引擎，基于 Elasticsearch 和 Kibana 的开源分支，提供托管服务。 - -## Description -OpenSearch 是 ELK Stack 的 AWS 托管替代方案，由 AWS 维护。与 Logz.io 等商业解决方案相比，OpenSearch 提供更低成本（约 $1,500/月 vs $4,000/月）和更高的可用性 SLA（99.9% vs 99.8%）。 - -## Features -- 托管日志分析服务 -- 与 ELK Stack 兼容 -- 自动快照备份 -- 支持细粒度访问控制 - -## Cost Comparison（单农场、14天保留、每日 100GB） -- Logz.io：约 $4,000/月 -- AWS OpenSearch：约 $1,500/月 -- 自托管 ELK：成本最低但维护量大 - -## Connections -- [[OpenSearch]] ← extends ← [[ELK Stack]] -- [[Log Analytics]] ← implements ← [[OpenSearch]] \ No newline at end of file diff --git a/wiki/concepts/OpenTelemetry-Collector.md b/wiki/concepts/OpenTelemetry-Collector.md deleted file mode 100644 index 644d3341..00000000 --- a/wiki/concepts/OpenTelemetry-Collector.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: "OpenTelemetry Collector" -type: concept -tags: - - OpenTelemetry - - Collector - - Data-Processing -date: 2024-04-02 ---- - -## Definition -OpenTelemetry Collector 是用于接收、处理和导出遥测数据的独立组件，作为数据管道在应用和后端存储之间进行数据标准化和转发。 - -## Architecture -Collector 包含四大组件： - -### Receivers（接收器） -- AWS 特有接收器（ECS、EC2、EKS） -- 开源接收器（Prometheus、OTLP、Fluent Bit） -- 支持拉取（pull）和推送（push）模式 - -### Processors（处理器） -- 数据过滤和转换 -- 批量处理和重试 -- 内存限流和队列管理 - -### Exporters（导出器） -- AWS 原生：CloudWatch、X-Ray、OTLP -- 开源：Prometheus、Jaeger、Zipkin -- 第三方：Datadog、New Relic、Grafana - -### Extensions（扩展） -- SIGV 授权 -- 健康检查 -- zPages 调试 -- 内存配置 - -## Deployment Modes -- **Agent 模式**：与应用部署在同一主机，收集本地数据 -- **Gateway 模式**：独立部署，收集多个 Agent 的数据 - -## Related Concepts -- [[OpenTelemetry]]：父框架 -- [[ADOT]]：AWS 发行版，包含预配置 Collector -- [[Fluent-Bit]]：日志收集器，可将数据转发至 Collector -- [[OTLP]]：数据交换协议 \ No newline at end of file diff --git a/wiki/concepts/OpenTelemetry.md b/wiki/concepts/OpenTelemetry.md deleted file mode 100644 index d872f160..00000000 --- a/wiki/concepts/OpenTelemetry.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: "OpenTelemetry" -type: concept -tags: - - OpenTelemetry - - Observability - - Telemetry - - Cloud-Native -date: 2024-04-02 ---- - -## Definition -OpenTelemetry（OTel）是厂商中立的遥测数据采集框架，提供统一的数据格式和跨语言 SDK，用于收集 Metrics、Logs、Traces 三种可观测性信号。 - -## Core Components -- **SDKs**：支持 11 种编程语言的自动和手动 instrumentation 库 -- **Collector**：数据标准化和转发组件 -- **Protocol (OTLP)**：统一的遥测数据格式 - -## Key Capabilities -- 厂商中立：不绑定特定后端监控系统 -- 自动 instrumentation：自动捕获常见框架和库的遥测数据 -- 统一数据格式：OTLP 标准化跨语言数据交换 -- 可扩展架构：支持自定义处理器和导出器 - -## Related Concepts -- [[OpenTelemetry-Collector]]：数据收集和处理核心组件 -- [[ADOT]]：AWS 发行版 -- [[OTLP]]：OpenTelemetry Protocol 数据格式 -- [[可观测性三大支柱]]：Metrics、Logs、Traces - -## Use Cases -- 微服务架构的可观测性集成 -- 跨云厂商的监控数据统一采集 -- 统一日志、指标、追踪数据格式 \ No newline at end of file diff --git a/wiki/concepts/Operational-Excellence.md b/wiki/concepts/Operational-Excellence.md deleted file mode 100644 index f4df0165..00000000 --- a/wiki/concepts/Operational-Excellence.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: "Operational Excellence" -type: concept -tags: [operations, continuous-improvement] -sources: [project-management-studio-operations] -last_updated: 2026-04-20 ---- - -## Definition -Operational Excellence is the practice of continuously improving processes, controls, and support systems so that operations remain reliable, efficient, and scalable. - -## Core Principles -- Make workflows predictable and documented -- Measure performance and spot regressions early -- Improve reliability through standardization -- Use automation and knowledge management to reduce friction - -## Related Entities -- [[Studio Operations]] -- [[The Agency]] diff --git a/wiki/concepts/Opportunity-Assessment.md b/wiki/concepts/Opportunity-Assessment.md deleted file mode 100644 index a5bccdd6..00000000 --- a/wiki/concepts/Opportunity-Assessment.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: "Opportunity Assessment" -type: concept -tags: [product-management, prioritization, decision-framework] -sources: [product-manager.md] -last_updated: 2026-04-20 ---- - -## Definition -机会评估是在讨论解决方案之前编写的文档，通过 RICE 框架量化机会价值，支撑 build/explore/defer/kill 决策。 - -## Structure -1. **Why Now?**：市场信号、用户行为变化或竞争压力，为什么现在紧急 -2. **User Evidence**：访谈发现、行为数据、support 信号 -3. **Business Case**：收入影响、成本影响、战略契合度、市场规模 -4. **RICE Prioritization Score**：R × I × C ÷ E -5. **Options Considered**：构建/MVP/购买/延期选项对比 -6. **Recommendation**：Build / Explore further / Defer / Kill + 理由 + 下一步 - -## RICE Score Formula -| Factor | Description | -|--------|-------------| -| Reach | 每季度触达用户数 | -| Impact | 对指标的影响（0.25/0.5/1/2/3） | -| Confidence | 信心水平（%） | -| Effort | 人力月数 | -| **Score** | **(R × I × C) ÷ E** | - -## Use Case -- 在进入 PRD 编写前做优先级决策 -- 对齐 leadership 对战略契合和资源意愿 -- 正式 build/defer/kill 推荐文档化推理 - -## Connection -- [[Product Manager Agent]] ← conducts ← [[Opportunity Assessment]] -- [[RICE Prioritization Score]] ← calculated_in ← [[Opportunity Assessment]] -- [[Roadmap (Now / Next / Later)]] ← informed_by ← [[Opportunity Assessment]] diff --git a/wiki/concepts/Opt-Out-Completion.md b/wiki/concepts/Opt-Out-Completion.md deleted file mode 100644 index f07975ab..00000000 --- a/wiki/concepts/Opt-Out-Completion.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: "Opt-Out Completion" -type: concept -tags: [ux-design, behavioral-psychology, user-autonomy] -sources: [product-behavioral-nudge-engine] -last_updated: 2026-04-20 ---- - -## Definition -提供清晰的退出路径而非强制持续的机制，尊重用户自主权同时保持参与度。 - -## Mechanism -- 每个交互都提供明确的"退出"或"继续"选项 -- 不使用黑暗模式（dark patterns）强制用户继续 -- 用户可以随时调整偏好 - -## Example -> "Great job! Want to do 5 more minutes, or call it for the day?" - -## Related Concepts -- [[Momentum Nudge]] -- [[Default Bias]] -- [[Cognitive Load Reduction]] - -## Connections -- [[Behavioral Nudge Engine]] ← implements ← [[Opt-Out Completion]] diff --git a/wiki/concepts/Optimization-Operator.md b/wiki/concepts/Optimization-Operator.md deleted file mode 100644 index 8a6ae8e1..00000000 --- a/wiki/concepts/Optimization-Operator.md +++ /dev/null @@ -1,16 +0,0 @@ ---- -title: "Optimization Operator" -type: concept -tags: [] ---- - -## Definition -优化算子，记作 O: P × Ω → P，其中 P 是提示空间，Ω 是理想目标或评估标准的抽象表示。该算子根据理想目标 Ω 改进提示 P。 - -## Context -在递归自优化生成系统中，优化算子负责将生成的原始提示优化为更高质量的版本。这个优化后的版本随后用于更新生成器本身。 - -## Related Concepts -- [[Generator Space]] -- [[Meta-Generative Operator]] -- [[Recursive Self-Optimizing Generative Systems]] \ No newline at end of file diff --git a/wiki/concepts/Oracle-Manipulation.md b/wiki/concepts/Oracle-Manipulation.md deleted file mode 100644 index 24adb3e4..00000000 --- a/wiki/concepts/Oracle-Manipulation.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: "Oracle Manipulation" -type: concept -tags: [smart-contract, vulnerability, defi, security] -sources: [blockchain-security-auditor] -last_updated: 2026-04-20 ---- - -## Definition -预言机操纵（Oracle Manipulation）是指攻击者通过操纵区块链上的价格数据源（预言机）来影响资产价格，从而在 DeFi 协议中获取不正当利益。 - -## Attack Vector -1. 识别使用链上价格预言机的协议 -2. 通过 Flash Loan 借用大量资产 -3. 在单笔交易内操纵交易对储备量 -4. 协议使用被操纵的价格计算抵押品价值 -5. 攻击者借出超出正常限额的资产 -6. 归还 Flash Loan，利润落袋 - -## Vulnerable Patterns -- **Spot Price Oracle**：使用 Uniswap V2 即时价格 -- **缺乏 TWAP 时间加权） -- **缺乏价格更新验证** -- **过长的价格 staleness 容忍** - -## Mitigation -- **TWAP（Time-Weighted Average Price）**：使用时间加权平均价格 -- **Chainlink Oracle**：使用去中心化预言机网络 -- **价格更新验证**：检查 timestamp、roundId -- **价格波动限制**：设置最大允许偏差 - -## Connections -- [[DeFi Attack Vector]] ← is_type_of ← [[Oracle Manipulation]] -- [[Flash Loan Attack]] ← exploits ← [[Oracle Manipulation]] -- [[Chainlink]] ← provides ← [[Oracle Manipulation]] Mitigation - diff --git a/wiki/concepts/Ordered-Layer.md b/wiki/concepts/Ordered-Layer.md deleted file mode 100644 index b6d9b7d0..00000000 --- a/wiki/concepts/Ordered-Layer.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -id: Ordered-Layer -title: "Ordered Layer" -type: concept -tags: - - AWS - - Firewall - - Security-Policy -date_added: 2026-04-18 ---- - -## Definition -防火墙策略的一种组织方式，按顺序执行多个过滤规则，优先级从高到低。 - -## Layer Priority -1. **地理屏蔽** — 阻止特定地区的流量 -2. **BU 隔离** — 按业务单元隔离流量 -3. **产品隔离** — 按产品线隔离流量 -4. **环境隔离** — 开发环境与生产环境隔离 - -## Key Features -- 逐层过滤，确保流量满足所有前置条件 -- 支持 PSDC 等共享服务的合法访问 -- 与 AWS 标签集成，实现动态策略执行 - -## Use Case -- 在 Checkpoint 防火墙中实现多层次的流量控制 -- 确保跨 VPC、访问本地或互联网的流量受到精细化策略约束 - -## Related Concepts -- [[Checkpoint Firewall]] -- [[Tagging Methodology]] -- [[Transit Gateway]] \ No newline at end of file diff --git a/wiki/concepts/Outcome-Driven-Development.md b/wiki/concepts/Outcome-Driven-Development.md deleted file mode 100644 index c29990a5..00000000 --- a/wiki/concepts/Outcome-Driven-Development.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: "Outcome-Driven Development" -type: concept -tags: [product-management, philosophy, development] -sources: [product-manager.md] -last_updated: 2026-04-20 ---- - -## Definition -结果驱动开发（Outcome-Driven Development）是一种产品开发哲学，核心是以可衡量的业务成果（outcome）而非功能产出（output）来定义成功。 - -## Core Tenets -1. **Feature 是 Hypothesis**：每个功能都是假设，需要验证 -2. **Shipped ≠ Success**：交付了没人用的功能是浪费，不是胜利 -3. **Measurement is Mandatory**：上线后必须追踪成功指标 vs 目标 -4. **Learning is Valuable**：未达目标的功能是学习，不是失败 - -## Quote -> "Features are hypotheses. Shipped features are experiments. Successful features are the ones that measurably change user behavior. Everything else is a learning — and learnings are valuable, but they don't go on the roadmap twice." - -## Success Criteria Framework -| Timeframe | Metric | Target | Owner | -|-----------|--------|--------|-------| -| Launch day | Error rate | < 0.5% | Eng | -| 7 days | Feature activation | ≥ 20% | PM | -| 30 days | Retention delta | +8pp | PM | -| 60 days | Support tickets | −30% | CS | -| 90 days | NPS delta | +5 points | PM | - -## Why Outcome Over Output -- Output 容易衡量但不一定有价值 -- Outcome 连接到业务目标和用户价值 -- 避免"忙碌但无用"陷阱 - -## Connection -- [[Outcome-Driven Development]] ← guides ← [[Product Manager Agent]] -- [[Opportunity Assessment]] ← applies ← [[Outcome-Driven Development]] -- [[Launch Phase]] ← measures ← [[Outcome-Driven Development]] diff --git a/wiki/concepts/Overlay-Network.md b/wiki/concepts/Overlay-Network.md deleted file mode 100644 index 51d3821f..00000000 --- a/wiki/concepts/Overlay-Network.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "Overlay Network" -type: concept -tags: - - networking - - virtualization ---- - -## Aliases -- Overlay Network -- 叠加网络 - -## Description -叠加网络（Overlay Network）是在现有物理网络（Underlay）之上构建的逻辑网络，用于实现复杂的路由和隧道功能。常见的 Overlay 协议包括 VXLAN、GRE、IPsec 等。在 SD-WAN 架构中，Overlay 网络负责路径选择和流量调度，与底层的物理网络解耦。 - -## Use Cases -- SD-WAN 叠加网络 -- 容器网络（如 Kubernetes CNI） -- VPN 隧道 -- 云间互联 - -## Related Concepts -- [[SD-WAN]] -- [[Hub-and-Spoke]] - -## Related Entities -- [[AWS]] - -## Sources -- [[ctp-topic-18-wide-area-networking-in-aws-cloud]] \ No newline at end of file diff --git a/wiki/concepts/PIM-Privileged-Identity-Management.md b/wiki/concepts/PIM-Privileged-Identity-Management.md deleted file mode 100644 index 24721379..00000000 --- a/wiki/concepts/PIM-Privileged-Identity-Management.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: PIM（Privileged Identity Management） -type: concept -tags: [Azure, Security, Access-Control] -date: 2026-04-14 ---- - -## Definition -PIM（Privileged Identity Management，特权身份管理）是 Azure AD 的一项安全功能，用于管理和监控 Azure 环境中拥有提升权限的用户访问。PIM 通过实时审批流程和角色激活机制，减少长期特权账号带来的安全风险。 - -## Key Characteristics -- 特权角色的临时激活 -- 多因素认证强制要求 -- 审批工作流支持 -- 详细审计日志记录 -- 访问权限到期自动撤销 - -## Use Cases -- 按需激活管理员权限 -- 实施最小权限原则 -- 合规审计和报告 -- 紧急访问场景管理 - -## Related Concepts -- [[Azure Active Directory]]：Azure 身份识别服务 -- [[Zero Trust Architecture]]：零信任架构 -- [[Azure Landing Zone]]：使用 PIM 实施访问管理 - -## Connections -- [[PIM（Privileged Identity Management）]] ← manages ← [[Azure Active Directory]] -- [[Azure Landing Zone]] ← uses ← [[PIM（Privileged Identity Management）]] \ No newline at end of file diff --git a/wiki/concepts/POUR-Principles.md b/wiki/concepts/POUR-Principles.md deleted file mode 100644 index 112f81d0..00000000 --- a/wiki/concepts/POUR-Principles.md +++ /dev/null @@ -1,79 +0,0 @@ ---- -title: "POUR Principles" -description: WCAG 无障碍设计的四大核心原则：Perceivable、Operable、Understandable、Robust -tags: [accessibility, wcag, design-principles] ---- - -## Definition -POUR 是 WCAG（Web Content Accessibility Guidelines）无障碍设计的四大核心原则的首字母缩写，是评估数字产品无障碍性的基础框架。 - -## 四大原则 - -### P — Perceivable（可感知） -**核心要求**：所有信息都必须以用户可感知的方式呈现 - -具体要求： -- 提供文本替代方案（alt 文本、字幕） -- 提供音频描述 -- 内容可以以不同方式呈现（放大、高对比度） -- 区分前后景（足够对比度） - -技术要点： -- 图像 alt 文本 -- 视频字幕 -- 音频转录 -- 颜色对比度 ≥ 4.5:1 - -### O — Operable（可操作） -**核心要求**：所有功能都必须可以通过键盘操作 - -具体要求： -- 所有功能可通过键盘使用 -- 用户有足够时间阅读和使用内容 -- 不以可能引发癫痫的方式设计内容 -- 提供帮助用户导航和找到内容的机制 - -技术要点： -- 键盘可访问性 -- 跳过链接 -- 无键盘陷阱 -- 焦点指示器 - -### U — Understandable（可理解） -**核心要求**：信息和操作必须是可理解的 - -具体要求： -- 文本可读且可理解 -- 内容以可预测的方式出现和操作 -- 帮助用户避免和纠正错误 - -技术要点： -- 清晰的标签 -- 错误建议 -- 一致的导航 -- 简单语言 - -### R — Robust（健壮） -**核心要求**：内容必须能被各种用户代理可靠解释 - -具体要求： -- 使用标准兼容的技术 -- 状态信息可被辅助技术识别 -- 提供状态和变化的机器可读通知 - -技术要点： -- 语义 HTML -- ARIA 正确使用 -- 标准化技术 - -## 与 Accessibility Auditor 的关系 -[[Accessibility Auditor]] 智能体默认验证所有四个 POUR 原则，确保测试产品达到 WCAG 2.2 AA 级别合规。 - -## Related Concepts -- [[WCAG 2.2]] -- [[Screen Reader Testing]] -- [[Keyboard Navigation Audit]] - -## Source -- [[Accessibility Auditor]] -- W3C WCAG 2.2 \ No newline at end of file diff --git a/wiki/concepts/PRD.md b/wiki/concepts/PRD.md deleted file mode 100644 index 6f669fc0..00000000 --- a/wiki/concepts/PRD.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: "PRD" -type: concept -tags: [] -last_updated: 2025-12-18 ---- - -## Definition -Product Requirements Document，产品需求文档。是产品经理最核心的工作交付物，描述产品功能、交互、业务逻辑的文档。 - -## Key Components -- 功能描述：每个功能的详细说明 -- 业务流程：用户操作流程和数据流向 -- 边界情况：异常场景、空数据处理等 -- 交互原型：页面布局和交互细节 - -## Evolution -本文认为 AI 将改变 PRD 的角色：未来需求实现可能"端到端"，不再需要传统文档。 - -## Aliases -- Product Requirements Document -- 产品需求文档 -- PRD 文档 \ No newline at end of file diff --git a/wiki/concepts/PaaS.md b/wiki/concepts/PaaS.md deleted file mode 100644 index 30117b3d..00000000 --- a/wiki/concepts/PaaS.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: "PaaS (Platform as a Service)" -type: concept -tags: [Cloud, Service-Model] -sources: [Cloud-Maturity-Model-A-Detailed-Guide-For-Cloud-Adoption] -last_updated: 2025-02-28 ---- - -## Summary -PaaS（平台即服务）是云计算三大服务模型之一，提供应用开发和部署平台。 - -## Definition -PaaS 提供完整的应用开发和部署平台，使开发者能够专注于应用程序本身而非底层基础设施。 - -## Example Providers -- AWS Elastic Beanstalk -- Google App Engine -- Microsoft Azure App Service - -## Connections -- [[PaaS]] ← part_of ← [[Cloud-Maturity-Model]] -- [[PaaS]] ← type_of ← [[Cloud-Service-Models]] diff --git a/wiki/concepts/Packer.md b/wiki/concepts/Packer.md deleted file mode 100644 index e62625f5..00000000 --- a/wiki/concepts/Packer.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -id: Packer -title: "Packer" -type: concept -tags: - - DevOps - - IaC - - AMI - - AWS -last_updated: 2026-04-18 ---- - -## Aliases -- HashiCorp Packer - -## Summary -- **定义**：HashiCorp 开发的开源工具，通过模板定义自动构建机器镜像（AMI、VMDK、QCOW2 等） -- **用途**：实现基础设施的不可变部署 -- **云迁移价值**：标准化镜像构建，确保环境一致性 - -## Key Details -- **核心功能**： - - 多平台镜像构建（AWS AMI、VMware、Vagrant、Docker 等） - - JSON/HCL 模板定义 - - 预置和后置配置脚本 - - 并行构建加速 -- **工作流程**： - 1. 定义模板（Builder 配置） - 2. 运行 provisioner（配置脚本） - 3. 输出镜像 -- **与 Terraform 集成**： - - Packer 构建 AMI - - Terraform 使用 AMI 部署基础设施 - -## Octane Hub 案例 -- Octane Hub 使用 Packer 构建自定义 AMI -- 从手动控制台脚本演进到自动化镜像构建 - -## Connections -- [[Terraform]] ← uses_ami_from ← [[Packer]] -- [[Infrastructure-as-Code-IaC]] ← implementd_by ← [[Packer]] -- [[AMI]] ← built_by ← [[Packer]] \ No newline at end of file diff --git a/wiki/concepts/Paper-Trading.md b/wiki/concepts/Paper-Trading.md deleted file mode 100644 index 473c633d..00000000 --- a/wiki/concepts/Paper-Trading.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "Paper Trading" -type: concept -tags: [trading, backtesting, simulation] -sources: [polymarket-autopilot] -last_updated: 2026-04-17 ---- - -## Description -模拟交易（Paper Trading）是指使用虚拟资金在真实市场环境中测试交易策略的方法。交易者可以在不承担真实风险的情况下验证策略有效性、学习市场行为并积累经验。 - -## Key Characteristics -- 虚拟资金：使用模拟资本，不承担真实财务风险 -- 实时市场：在真实市场环境中执行模拟订单 -- 绩效追踪：记录每笔交易的盈亏、胜率等指标 -- 策略迭代：根据回测结果调整策略参数 - -## Role in AI Agent Context -AI Agent 通过 Cron Jobs 定时执行模拟交易，记录绩效数据并生成每日报告，实现策略的自动化测试和优化。 - -## Related Concepts -- [[Cron Jobs]] — 定时执行机制 -- [[Subagent 管理]] — 并行市场分析 -- [[Discord Integration]] — 绩效报告推送 \ No newline at end of file diff --git a/wiki/concepts/Parallel-Kickoff.md b/wiki/concepts/Parallel-Kickoff.md deleted file mode 100644 index d7d8cb5a..00000000 --- a/wiki/concepts/Parallel-Kickoff.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: "Parallel Kickoff" -type: concept -tags: [multi-agent, workflow, parallel] -last_updated: 2026-04-21 ---- - -## Definition -Parallel Kickoff 是一种多智能体工作流启动模式，多个独立工作流同时开始执行，适用于相互之间无依赖关系的任务。 - -## Usage Scenario -在 landing page sprint 中，Content Creator 和 UI Designer 可同时开始工作，因二者相互独立： -- Content Creator 编写文案 -- UI Designer 设计规格 - -二者输出合并后交付给 Frontend Developer。 - -## Example -``` -Morning (9:00) -├── Content Creator → 编写文案（并行） -└── UI Designer → 设计规格（并行） -``` - -## Connections -- [[Multi-Agent Workflow]]：所属工作流模式 -- [[Merge Point]]：后续合并节点 -- [[Parallel Work]]：相关概念 - diff --git a/wiki/concepts/Parallel-Work.md b/wiki/concepts/Parallel-Work.md deleted file mode 100644 index 758ce8e9..00000000 --- a/wiki/concepts/Parallel-Work.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: "Parallel Work" -type: concept -tags: [multi-agent, workflow, concurrency] -last_updated: 2026-04-21 ---- - -## Definition -并行工作（Parallel Work）是一种多智能体协作模式，其中多个智能体同时执行任务，通过独立工作减少总体完成时间。 - -## Core Principle -相互独立的任务可以同时由不同智能体处理，无需等待彼此完成。 - -## Workflow Pattern -``` -Agent A ─┬─→ [独立任务 A] - │ -Agent B ─┴─→ [独立任务 B] -``` - -## Example -在 Multi-Agent Workflow: Startup MVP 中： -- Week 1：Sprint Prioritizer 和 UX Researcher **并行运行** -- Week 2：Frontend Developer 和 Rapid Prototyper **并行构建** -- Week 3：Frontend Developer 继续 + Growth Hacker **启动策略规划** - -## Key Requirements -- 任务必须相互独立，无依赖关系 -- 需要明确的输入和输出定义 -- 输出最终需要合并或由协调者整合 - -## Advantages -- 减少总体执行时间 -- 充分利用并行处理能力 -- 加快 MVP 交付速度 - -## Disadvantages -- 增加了协调复杂度 -- 需要清晰的边界定义 -- 合并输出可能产生冲突 - -## Related Concepts -- [[Sequential Handoffs]]：顺序交接模式 -- [[Quality Gates]]：质量门控 -- [[Context Passing]]：上下文传递 -- [[Multi-Agent Team]]：多智能体团队 diff --git a/wiki/concepts/Partial-Dependence-Plots.md b/wiki/concepts/Partial-Dependence-Plots.md deleted file mode 100644 index 774b6b93..00000000 --- a/wiki/concepts/Partial-Dependence-Plots.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: "Partial Dependence Plots" -type: concept -tags: [interpretability, feature-analysis, ml-ops] -sources: [specialized-model-qa] -last_updated: 2026-04-20 ---- - -## Definition -偏依赖图（PDP）展示某个特征变化时，模型平均预测如何变化，用于分析边际效应。 - -## Use in Model QA -- 验证单调性假设 -- 识别非线性阈值 -- 检查特征与预测之间的边际关系 - -## Limitations -- 在强相关特征下可能误导 -- 更适合做辅助解释而非唯一依据 - -## Related Concepts -- [[SHAP Analysis]] -- [[Model Audit]] \ No newline at end of file diff --git a/wiki/concepts/PatientPrivacyProtection.md b/wiki/concepts/PatientPrivacyProtection.md deleted file mode 100644 index e80ebd8b..00000000 --- a/wiki/concepts/PatientPrivacyProtection.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: "Patient Privacy Protection" -type: concept -tags: [privacy, pipl, healthcare, compliance, china] -last_updated: 2026-04-20 ---- - -## Definition -Patient Privacy Protection is the governance of sensitive medical and health information across collection, processing, storage, sharing, and marketing reuse. - -## Core Principles -- Treat medical and health information as sensitive personal information -- Use separate consent and minimum-necessary collection -- De-identify patient cases before publication -- Never repurpose EMR or prescription data for marketing without authorization - -## Related Concepts -- [[HealthcareMarketingCompliance]] -- [[Identity Governance]] -- [[InternetHealthcareCompliance]] diff --git a/wiki/concepts/Pattern-Key.md b/wiki/concepts/Pattern-Key.md deleted file mode 100644 index 34840ca3..00000000 --- a/wiki/concepts/Pattern-Key.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: "Pattern-Key" -type: concept -tags: [openclaw, memory, agent] -last_updated: 2026-04-17 ---- - -## Definition -Pattern-Key（模式键）是 Self-Improving Skill 中用于追踪同一类型问题生命周期的检索键，帮助 Agent 区分一次性错误和系统性重复。 - -## Usage -在 LRN 记录的 Metadata 中使用： -```markdown -### Metadata -- Pattern-Key: cron.telegram-delivery -- Recurrence-Count: 2 -- See Also: LRN-20260325-001 -``` - -## Detection Logic -| Recurrence-Count | 含义 | 处理方式 | -|-----------------|------|---------| -| 1 | 一次性错误 | 记录并解决 | -| 2+ | 系统性重复 | 需要系统性修复 | - -## Example -- `cron.daily-self-review`：出现9次，持续优化领域 -- `cron.telegram-delivery`：出现2次，第二次解决 - -## Core Insight -Pattern-Key 重复本身就是一个信号——第一次记了，第二次就该解决了。 - -## Related -- [[Self-Improving Skill]] -- [[每日复盘机制]] -- [[双层记忆架构]] -- [[OpenClaw]] \ No newline at end of file diff --git a/wiki/concepts/Pay-as-you-go.md b/wiki/concepts/Pay-as-you-go.md deleted file mode 100644 index 149998b5..00000000 --- a/wiki/concepts/Pay-as-you-go.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: Pay-as-you-go -type: concept -tags: [Cloud, Cost-Optimization, Business-Model] -sources: [The-Myths-and-Misconceptions-About-Cloud-Computing-LinkedIn.md] -last_updated: 2025-03-02 ---- - -## Definition -按需付费（Pay-as-you-go）是一种基于实际使用量计费的商业模式，用户根据资源消耗而非固定订阅支付费用。 - -## Core Features -- 弹性计费：根据实际使用量收费 -- 无需大额前期投资：降低资本支出 -- 资源弹性扩展：根据业务需求动态调整 -- 成本透明：按使用量精确计费 - -## Cost Optimization Strategies -- 预留实例（Reserved Instances）：长期使用可享折扣 -- 自动扩展（Auto-scaling）：根据负载自动调整资源 -- 无服务器计算（Serverless Computing）：仅按实际计算时间计费 - -## Key Claims -- 云计算采用按需付费模式，允许企业按需扩展资源 -- 成本优化策略如预留实例、自动扩展和无服务器计算有助于降低费用 -- 消除本地硬件采购、维护和升级需求通常可带来显著成本节省 - -## Connections -- [[CAPEX-to-OPEX]] ← implements ← [[Pay-as-you-go]]：按需付费是 CAPEX 到 OPEX 转型的实现方式 -- [[Auto-scaling]] ← supports ← [[Pay-as-you-go]]：自动扩展优化按需付费成本 -- [[Serverless-Computing]] ← extends ← [[Pay-as-you-go]]：无服务器是最细粒度的按需付费 diff --git a/wiki/concepts/Payment-Rail.md b/wiki/concepts/Payment-Rail.md deleted file mode 100644 index cd87f0c8..00000000 --- a/wiki/concepts/Payment-Rail.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: "Payment Rail" -type: concept -tags: [finance, payments, operations] -sources: [accounts-payable-agent] -last_updated: 2026-04-20 ---- - -## Definition -Payment Rail 是支付从发送方到接收方所经过的结算通道或网络，例如 ACH、Wire、Crypto、Stablecoin 或支付 API。 - -## Core Principles -- 不同 rail 适合不同金额、时效与成本要求 -- rail 选择应基于收款方类型、地区、费用和结算速度 -- rail 故障时应优先尝试替代通道 -- 付款系统应支持可追踪的 rail 级别记录 - -## Related Entities -- [[Accounts Payable Agent]] -- [[The Agency]] diff --git a/wiki/concepts/Period-Authenticity-Report.md b/wiki/concepts/Period-Authenticity-Report.md deleted file mode 100644 index 2d66659f..00000000 --- a/wiki/concepts/Period-Authenticity-Report.md +++ /dev/null @@ -1,59 +0,0 @@ ---- -title: "Period Authenticity Report" -type: concept -tags: [history, worldbuilding, validation] -last_updated: 2026-04-20 ---- - -## Definition -时期真实性报告是 Academic Historian 提供的标准化验证文档，用于评估虚构设定与特定历史时期的一致性。 - -## Report Structure -``` -PERIOD AUTHENTICITY REPORT -========================== -Setting: [Time period, region, specific context] -Confidence Level: [Well-documented / Scholarly consensus / Debated / Speculative] - -Material Culture: -- Diet: [What people actually ate, class differences] -- Clothing: [Materials, styles, social markers] -- Architecture: [Building materials, styles, what survives vs. what's lost] -- Technology: [What existed, what didn't, what was regional] -- Currency/Trade: [Economic system, trade routes, commodities] - -Social Structure: -- Power: [Who held it, how it was legitimized] -- Class/Caste: [Social stratification, mobility] -- Gender roles: [With acknowledgment of regional variation] -- Religion/Belief: [Practiced religion vs. official doctrine] -- Law: [Formal and customary legal systems] - -Anachronism Flags: -- [Specific anachronism]: [Why it's wrong, what would be accurate] - -Common Myths About This Period: -- [Myth]: [Reality, with source] - -Daily Life Texture: -- [Sensory details: sounds, smells, rhythms of daily life] -``` - -## Key Principles -- Default requirement: Always name confidence level and source type -- Material conditions first: Economy, technology, agriculture constrain everything else -- Layer social structures on top of material base -- Distinguish well-documented facts, scholarly consensus, active debates, and speculation - -## Usage Context -- Worldbuilding validation for fiction, games, or creative projects -- Historical setting coherence checking -- Anachronism detection and correction - -## Related Concepts -- [[Historical Coherence Check]]：更简洁的声明级验证 -- [[Material Culture]]：物质文化是报告的核心关注点 -- [[Longue Durée]]：长时段分析方法论 - -## Source -Academic Historian Agent — The Agency 项目 diff --git a/wiki/concepts/Photography-Terminology.md b/wiki/concepts/Photography-Terminology.md deleted file mode 100644 index fbad31a8..00000000 --- a/wiki/concepts/Photography-Terminology.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: "Photography Terminology" -type: concept -tags: [photography, prompt-engineering, terminology] -date: 2026-04-20 ---- - -## Summary -专业摄影术语是在 AI 图像生成提示词中准确描述摄影技术要素的规范术语集。 - -## Definition -Photography Terminology 是专业摄影知识在 AI 提示词工程中的应用，包括相机设置、灯光技术、构图原则等专业术语的精确使用。 - -## Key Categories -六大类别： -1. **相机设置**：f/stop（光圈）、focal length（焦距）、shutter speed（快门速度）、ISO -2. **景深控制**：shallow depth of field（浅景深）、deep focus（深焦）、bokeh（散景）、aperture -3. **灯光方向**：front/side/back/top lighting、Rembrandt triangle、butterfly、split lighting -4. **灯光质量**：hard/soft light、diffused、specular、volumetric、dramatic -5. **构图术语**：rule of thirds、leading lines、framing、symmetry、negative space -6. **色彩术语**：color temperature、color grading、color palette、warm/cool tones - -## Correct Usage Examples -- ❌ "blurry background" → ✅ "shallow depth of field, f/1.8 bokeh" -- ❌ "bright light" → ✅ "soft golden hour side lighting with gentle shadow gradation" -- ❌ "close up" → ✅ "85mm focal length, eye-level perspective" - -## Connections -- [[Prompt Engineering]] ← applies ← Photography Terminology：提示词工程应用摄影术语 -- [[Prompt Structure Framework]] ← incorporates ← Photography Terminology：提示词结构框架整合摄影术语 -- [[Image Prompt Engineer]] ← masters ← Photography Terminology：Image Prompt Engineer 掌握该术语 \ No newline at end of file diff --git a/wiki/concepts/Pipeline-Coverage.md b/wiki/concepts/Pipeline-Coverage.md deleted file mode 100644 index f1f191cd..00000000 --- a/wiki/concepts/Pipeline-Coverage.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "Pipeline Coverage" -type: concept -tags: [sales, revenue-operations, metrics] -description: 管道覆盖率，开放加权管道与剩余配额的比率，用于评估管道是否足够达成目标 ---- - -Pipeline Coverage（管道覆盖率）是开放加权管道与剩余配额之间的比率，用于回答是否有足够的管道达成目标。 - -## 目标覆盖率 - -| 业务类型 | 目标覆盖率 | -|----------|----------| -| 成熟可预测业务 | 3x | -| 增长期或新市场 | 4-5x | -| 新销售代表（低胜率预期） | 5x+ | - -## 质量调整覆盖率 - -覆盖率本身不足。质量调整覆盖率根据交易健康评分、阶段时长和互动信号对管道进行折扣。 - -**核心原则**：500 万美元包含 20 个陈旧且资格不足的交易管道，价值低于 200 万美元包含 8 个活跃且充分合格的商机的管道。管道质量始终优于管道数量。 - -## 诊断规则 - -- 30+ 天未更新的管道应被标记审查 -- 单一联系人交易（大于 5 万美元）是高风险信号 -- 阶段和关闭日期不是预测方法论 - -## Related -- [[Pipeline Velocity]] -- [[Deal Health Scoring]] \ No newline at end of file diff --git a/wiki/concepts/Pipeline-Velocity.md b/wiki/concepts/Pipeline-Velocity.md deleted file mode 100644 index 98d174ea..00000000 --- a/wiki/concepts/Pipeline-Velocity.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "Pipeline Velocity" -type: concept -tags: [sales, revenue-operations, metrics] -description: 管道速度，衡量收入通过销售漏斗的速度，是收入运营中最重要的复合指标 ---- - -Pipeline Velocity（管道速度）是收入运营中最重要的复合指标，用于衡量收入通过销售漏斗的速度。 - -## 计算公式 - -**Pipeline Velocity = (Qualified Opportunities × Average Deal Size × Win Rate) / Sales Cycle Length** - -## 构成变量 - -| 变量 | 说明 | 诊断意义 | -|------|------|----------| -| Qualified Opportunities | 进入管道的合格商机数量 | 按来源、细分市场和销售代表追踪。入口下降会在 2-3 个季度后体现在收入上 | -| Average Deal Size | 平均交易规模 | 上升可能表示更好的目标定位或范围蔓延；下降可能表示折扣压力或市场变化 | -| Win Rate | 胜率 | 按阶段、代表、细分市场和交易规模追踪。最常用错的指标 | -| Sales Cycle Length | 销售周期长度 | 延长的周期通常是竞争压力、买方委员会扩大或资格缺口的早期症状 | - -## 诊断价值 - -- 管道速度是预测和销售辅导的支柱 -- 速度下降是最早期的预警信号 -- 必须按细分市场分段分析，混合平均会隐藏问题 - -## Related -- [[Pipeline Coverage]] -- [[Deal Health Scoring]] -- [[Forecast Accuracy]] \ No newline at end of file diff --git a/wiki/concepts/Pipeline.md b/wiki/concepts/Pipeline.md deleted file mode 100644 index 6dd290fd..00000000 --- a/wiki/concepts/Pipeline.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -id: pipeline -title: "Pipeline" -type: concept -tags: [Agent, Skill, 设计模式] -sources: [Google-5-Agent-Skill-design-patterns-2026-03-19] -last_updated: 2026-04-17 ---- - -## Summary -带硬性检查点的严格工作流 Agent Skill 设计模式，强制执行顺序工作流。 - -## Definition -Pipeline 模式通过实现明确的门控条件，强制执行严格的顺序工作流，并在关键节点设置硬性检查点。 - -## How It Works -1. **定义工作流**：指令本身定义工作流步骤 -2. **硬性检查点**：每个步骤有明确的前置条件 -3. **用户确认**：用户必须在进入下一步之前确认 -4. **防止绕过**：确保 agent 无法跳过复杂任务直接给出未验证的最终结果 - -## Example Workflow -文档流水线示例： -1. 解析和清点 -2. 生成文档字符串 -3. 组装文档 -4. 质量检查 - -每一步都有明确的前置条件，用户必须在进入下一步之前确认。 - -## Use Cases -- 复杂任务：无法承受跳过步骤或忽略指令的情况 -- 多阶段流程：需要严格顺序执行的任务 -- 质量保证：需要用户确认的检查点 - -## Related Concepts -- [[Agent-Skill-设计模式]] -- [[Reviewer]]：Pipeline 可以在最后包含 Reviewer 步骤来 double-check \ No newline at end of file diff --git a/wiki/concepts/PipelineReview.md b/wiki/concepts/PipelineReview.md deleted file mode 100644 index 4e26f1b8..00000000 --- a/wiki/concepts/PipelineReview.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: "Pipeline Review" -type: concept -tags: [sales, pipeline, coaching] -last_updated: 2026-04-20 ---- - -## Summary -- 定义：系统性审查销售 pipeline 的结构化流程，用于评估交易健康度和风险 -- 目标：将 pipeline 审查从审问式转变为 coaching 对话 - -## Key Questions -- "这交易什么时候关闭？" → "关于这笔交易我们不知道什么？" -- "最有可能降低风险的下一个步骤是什么？" - -## Review Cadence - -### Weekly 1:1 -- 活动进展 -- 障碍 -- 习惯 - -### Bi-weekly Pipeline Review -- 交易健康度 -- 资格差距 -- 风险 - -### Monthly/Quarterly Forecast -- 模式识别 -- 预测准确性 -- 资源分配 - -## Portfolio Patterns -- 交易阶段分布：开场强但收盘弱？ -- 特定阶段卡顿？ -- 回避特定类型对话（定价、执行访问、竞争替换）？ - -## Pipeline Quality vs Quantity -- $2M 无资格交易 < $800K 每个交易都有验证商业案例 + 已识别经济买家 - -## Connections -- [[Sales Coaching]]：通过 pipeline review 进行 coaching -- [[Sales Coach]]：实施 pipeline review 的 AI Agent -- [[Forecast Accuracy]]：pipeline review 支持预测准确性 \ No newline at end of file diff --git a/wiki/concepts/Plan-Mode.md b/wiki/concepts/Plan-Mode.md deleted file mode 100644 index c373d716..00000000 --- a/wiki/concepts/Plan-Mode.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: "Plan Mode" -type: concept -tags: [ai-coding, workflow] ---- - -## 定义 -OpenCode 的方案预览模式，禁用代码修改功能，仅展示 AI 实现的计划。 - -## 使用方式 -在 OpenCode TUI 中按 Tab 键切换到 Plan 模式。 - -## 作用 -- 预览 AI 生成的实现方案 -- 在实际修改前审查计划 -- 可添加更多细节或调整需求 -- 确认后再切换到 Build 模式执行 - -## 关联 -- [[Build Mode]] -- [[Vibe Coding]] -- [[OpenCode]] \ No newline at end of file diff --git a/wiki/concepts/Platform-Events.md b/wiki/concepts/Platform-Events.md deleted file mode 100644 index c13f961a..00000000 --- a/wiki/concepts/Platform-Events.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "Platform Events vs CDC" -type: concept -tags: [salesforce, integration, events] -sources: [specialized-salesforce-architect.md] -last_updated: 2026-04-20 ---- - -# Platform Events vs CDC - -Salesforce 事件驱动集成的两种模式对比。 - -## Platform Events - -| 特性 | 说明 | -|-----|-----| -| 自定义载荷 | 是 — 定义自己的 schema | -| 跨系统集成 | 首选 — 解耦生产者和消费者 | -| 字段级追踪 | 否 | -| 重放 | 72 小时窗口 | -| 容量 | 高容量标准（100K/天） | -| 使用场景 | "某事发生"（业务事件） | - -## Change Data Capture (CDC) - -| 特性 | 说明 | -|-----|-----| -| 自定义载荷 | 否 — 镜像 sObject 字段 | -| 跨系统集成 | 有限 — 仅 Salesforce 原生事件 | -| 字段级追踪 | 是 — 捕获字段变更 | -| 重放 | 3 天保留 | -| 容量 | 绑定到对象事务量 | -| 使用场景 | "某事变化"（数据同步） | - -## 选择指南 -- 需要跨系统集成 → Platform Events -- 只需要 Salesforce 内部变更追踪 → CDC - -## 来源 -[[Salesforce-Architect]] 智能体的架构设计指南 diff --git a/wiki/concepts/Playwright.md b/wiki/concepts/Playwright.md deleted file mode 100644 index 623799c3..00000000 --- a/wiki/concepts/Playwright.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: "Playwright" -type: concept -tags: [自动化, 浏览器, Playwright] -date: 2025-11-11 ---- - -## Definition -Playwright 是 Microsoft 开发的浏览器自动化工具，支持 Chromium、Firefox 和 WebKit，可模拟用户操作和渲染动态页面。 - -## Key Features -- 可模拟浏览器、支持无头模式、可靠性高 -- 支持滚动加载、视频图片加载 - -## Role -在电商数据采集系统中，Playwright 负责加载动态页面、渲染 JavaScript 内容，与 Scrapy 配合实现完整爬取。 - -## Connections -- [[Scrapy]] ← depends_on ← [[Playwright]] -- [[Playwright]] ← runs_in ← [[Docker]] diff --git a/wiki/concepts/Pod-中断预算.md b/wiki/concepts/Pod-中断预算.md deleted file mode 100644 index d5ce6b35..00000000 --- a/wiki/concepts/Pod-中断预算.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: "Pod 中断预算" -type: concept -tags: [Kubernetes, EKS, High-Availability] ---- - -## Description -Pod 中断预算（Pod Disruption Budget，PDB）是 Kubernetes 机制，确保在自愿中断（如节点维护、升级）期间仍维持最少的 Pod 副本数，保证服务的可用性。 - -## Use Case -在 EKS 中进行集群升级或节点维护时，PDB 确保应用始终保持最低服务水平。 - -## Related Concepts -- [[EKS 可靠性]] -- [[Pod 反亲和性]] - -## Related Entities -- [[EKS]] -- [[Kubernetes]] - -## Connections -- [[Pod 中断预算]] ← 实现 [[EKS 可靠性]] \ No newline at end of file diff --git a/wiki/concepts/Pod-反亲和性.md b/wiki/concepts/Pod-反亲和性.md deleted file mode 100644 index b12d0c45..00000000 --- a/wiki/concepts/Pod-反亲和性.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: "Pod 反亲和性" -type: concept -tags: [Kubernetes, EKS, High-Availability] ---- - -## Description -Pod 反亲和性（Pod Anti-Affinity）是一种 Kubernetes 调度策略，用于确保 Pod 不被调度到同一节点或同一可用区，从而提高应用的可用性和可靠性。 - -## Use Case -在 EKS 中部署关键应用时，使用 Pod 反亲和性确保应用 Pod 分布在不同的节点和可用区，避免单点故障。 - -## Related Concepts -- [[拓扑分布约束]]：Pod 反亲和性的更细粒度控制方式 -- [[HPA]] -- [[VPA]] - -## Related Entities -- [[EKS]] -- [[Kubernetes]] - -## Connections -- [[Pod 反亲和性]] ← 实现 [[EKS 可靠性]] \ No newline at end of file diff --git a/wiki/concepts/Policy-as-Code.md b/wiki/concepts/Policy-as-Code.md deleted file mode 100644 index cca8a487..00000000 --- a/wiki/concepts/Policy-as-Code.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: "Policy-as-Code" -type: concept -tags: [Security, Compliance, DevOps] -sources: [modern-itsm-driving-efficiency-security-resilience] -last_updated: 2026-04-16 ---- - -## Summary -Policy-as-Code（策略即代码）是将安全策略、合规规则定义为代码并通过自动化执行的实践。 - -## Definition -Policy-as-Code 是将安全策略和合规规则编写为代码，存储在版本控制系统中，并通过自动化工具执行和验证的实践。支持审计自动化和持续合规。 - -## Key Attributes -- **核心目的**：自动化安全策略执行、持续合规审计 -- **实现方式**：代码定义策略、自动化执行、持续验证 -- **工具**：OPA（Open Policy Agent）、Sentinel、Cloud Custodian - -## Connections -- [[DevSecOps]] ← 依赖 ← [[Policy-as-Code]] -- [[ITSM]] ← 集成 ← [[Policy-as-Code]] -- [[Zero Trust Architecture]] ← 实现 ← [[Policy-as-Code]] \ No newline at end of file diff --git a/wiki/concepts/Population-Stability-Index-PSI.md b/wiki/concepts/Population-Stability-Index-PSI.md deleted file mode 100644 index 010ede90..00000000 --- a/wiki/concepts/Population-Stability-Index-PSI.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "Population Stability Index (PSI)" -type: concept -tags: [ml-ops, model-monitoring, drift] -sources: [specialized-model-qa] -last_updated: 2026-04-20 ---- - -## Definition -Population Stability Index（PSI）用于衡量两个样本分布之间的变化程度，常见于模型监控与特征稳定性分析。 - -## Interpretation -- < 0.10：无显著偏移 -- 0.10–0.25：中等偏移，需要调查 -- ≥ 0.25：显著偏移，需要处理 - -## Use in Model QA -- 检测特征漂移 -- 识别训练集与生产集分布差异 -- 为复审与再训练提供量化证据 - -## Related Concepts -- [[Model Audit]] -- [[Calibration Testing]] -- [[Discrimination Metrics]] \ No newline at end of file diff --git a/wiki/concepts/Population-Stability-Index.md b/wiki/concepts/Population-Stability-Index.md deleted file mode 100644 index 97c0cb2e..00000000 --- a/wiki/concepts/Population-Stability-Index.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: "Population Stability Index (PSI)" -type: concept -tags: [ml-ops, model-metrics, feature-stability, statistical-analysis] -last_updated: 2026-04-20 ---- - -## Definition -Population Stability Index（PSI）是量化两个分布之间差异的统计指标，用于检测特征或模型输出在时间窗口上的分布偏移。 - -## Formula -``` -PSI = Σ ((Actual% - Expected%) * ln(Actual% / Expected%)) -``` - -使用 Laplace 平滑避免除零： -```python -exp_pct = (expected_counts + 1) / (expected_counts.sum() + bins) -act_pct = (actual_counts + 1) / (actual_counts.sum() + bins) -psi = np.sum((act_pct - exp_pct) * np.log(act_pct / exp_pct)) -``` - -## Interpretation Thresholds -| PSI Range | Status | Action | -|-----------|--------|--------| -| < 0.10 | 绿色 | 无显著偏移 | -| 0.10–0.25 | 琥珀色 | 中等偏移，建议调查 | -| ≥ 0.25 | 红色 | 显著偏移，需要行动 | - -## Use Cases -- **Feature Stability Monitoring**：监控输入特征在时间窗口上的稳定性 -- **Model Drift Detection**：检测模型输入输出分布是否发生显著变化 -- **Population Shift Detection**：识别开发样本与OOT样本之间的差异 - -## Applications -- 每月特征稳定性报告 -- 模型重新训练触发条件 -- 特征工程有效性评估 - -## Related Concepts -- [[Variable Stability Monitor]]：月度 PSI 监控工具 -- [[Model QA Specialist]]：使用 PSI 进行模型审计 -- [[ML Ops]]：PSI 是 MLOps 监控的核心指标 - -## References -- Source：[[model-qa-specialist]] diff --git a/wiki/concepts/Power-Analysis.md b/wiki/concepts/Power-Analysis.md deleted file mode 100644 index 7b015f40..00000000 --- a/wiki/concepts/Power-Analysis.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "Power Analysis" -type: concept -tags: [statistics, experimentation] -sources: [project-management-experiment-tracker] -last_updated: 2026-04-20 ---- - -## Definition -Power Analysis estimates the sample size needed to detect a meaningful effect with a desired probability of success. - -## Core Principles -- Specify minimum detectable effect -- Choose desired power level before launch -- Use realistic baseline rates and variance estimates -- Recompute when the experiment design changes - -## Related Concepts -- [[Hypothesis Testing]] -- [[Statistical Significance]] -- [[A/B Testing]] - -## Related Entities -- [[Experiment Tracker]] - diff --git a/wiki/concepts/Pre-Build-Idea-Validation.md b/wiki/concepts/Pre-Build-Idea-Validation.md deleted file mode 100644 index cd600677..00000000 --- a/wiki/concepts/Pre-Build-Idea-Validation.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -id: pre-build-idea-validation -title: "Pre-Build Idea Validation" -type: concept -tags: [ai-agent, mcp, validation] ---- - -## Definition -在编写代码前，通过扫描真实数据源验证项目创意是否已存在、竞争度如何的机制。 - -## Why It Matters -- 避免最昂贵的错误：解决已被解决的问题 -- 基于真实数据而非 LLM 猜测做决策 -- 帮助独立开发者在空白地带寻找机会 - -## Key Metrics -- **reality_signal**：竞争度评分（0-100） - - > 70：停止并讨论 - - 30-70：显示结果，建议细分角度 - - < 30：可继续构建 - -## Implementation -- MCP server：[[idea-reality-mcp]] -- 数据源：GitHub、Hacker News、npm、PyPI、Product Hunt - -## Related -- [[MVP]] — 最小可行产品概念 -- [[Market-Research]] — 市场研究相关概念 \ No newline at end of file diff --git a/wiki/concepts/Pre-Recording-Research.md b/wiki/concepts/Pre-Recording-Research.md deleted file mode 100644 index 524a4008..00000000 --- a/wiki/concepts/Pre-Recording-Research.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: "Pre-Recording Research" -type: concept -tags: [podcast, preparation, research] ---- - -## Definition -录制前的准备工作，包括嘉宾背景研究、话题深度挖掘、访谈问题设计等。这是播客制作中价值最高的环节。 - -## Key Activities -- 嘉宾背景研究：工作经历、近期观点、公开言论中的争议性内容 -- 话题趋势研究：相关领域的最新动态、常见误解、观众认知盲区 -- 访谈问题设计：从轻松建立 rapport 到深度有挑战性的递进式问题结构 - -## Value -深度研究能显著提升访谈质量，这是后期制作无法弥补的。 - -## Related Concepts -- [[Agent-Chain]] -- [[Show Notes]] - -## Related Sources -- [[podcast-production-pipeline]] \ No newline at end of file diff --git a/wiki/concepts/Predictive-Maintenance.md b/wiki/concepts/Predictive-Maintenance.md deleted file mode 100644 index f489f2a2..00000000 --- a/wiki/concepts/Predictive-Maintenance.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: "Predictive Maintenance" -type: concept -tags: [AI, maintenance, proactivity] -sources: [How-Agentic-AI-can-help-for-Cloud-DevOps] -last_updated: 2026-04-16 ---- - -## Summary -Predictive Maintenance（预测性维护）通过分析历史数据和模式，主动识别潜在问题并在故障发生前采取预防措施。 - -## Definition -利用机器学习分析历史 outage 和性能数据，预测未来可能发生的故障，并提前推荐补丁或扩缩容变更。 - -## Key Techniques -- **历史数据分析**：学习历史 outage 的模式 -- **趋势预测**：基于时间序列分析预测未来状态 -- **风险评分**：评估组件故障风险等级 -- **推荐系统**：生成预防性维护建议 - -## Connections -- [[Agentic AI]] ← implements ← [[Predictive Maintenance]]：Agentic AI 实现预测性维护 -- [[Self-Healing Systems]] ← complements ← [[Predictive Maintenance]]：预测性维护是自愈的主动式补充 diff --git a/wiki/concepts/Predictive-Modeling.md b/wiki/concepts/Predictive-Modeling.md deleted file mode 100644 index efabd8e0..00000000 --- a/wiki/concepts/Predictive-Modeling.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: "Predictive Modeling" -type: concept -tags: [prediction, modeling, forecasting] -sources: [raw/Agent/agency-agents/product/product-trend-researcher.md] -last_updated: 2026-04-20 ---- - -## Definition -预测建模是通过统计和数学方法，基于历史数据和模式预测未来结果的技术。 - -## Key Methods -- **Trend Lifecycle Mapping**：趋势生命周期映射（出现→增长→成熟→衰退） -- **Adoption Curve Analysis**：采用曲线分析（创新者→早期大众） -- **Cross-Correlation Studies**：多趋势交叉相关分析 -- **Scenario Planning**：基于不同假设的多情景规划 -- **Signal Strength Assessment**：信号强度评估 - -## Model Outputs -- 预测时间线（Timeline Predictions） -- 采用率预测（Adoption Rate Predictions） -- 置信区间（Confidence Intervals） -- 情景概率权重（Probability Weighting） - -## Analytics Reporter Applications -- **客户流失预测**：识别高流失风险客户 -- **需求预测**：预测产品需求量，优化库存 -- **增长预测**：基于趋势外推预测收入增长 - -## Related Concepts -- [[Customer Lifetime Value]] -- [[Statistical Significance Testing]] - -## Sources -- [[raw/Agent/agency-agents/product/product-trend-researcher.md]] -- [[support-analytics-reporter]] diff --git a/wiki/concepts/Preference-Learning.md b/wiki/concepts/Preference-Learning.md deleted file mode 100644 index 8bb41453..00000000 --- a/wiki/concepts/Preference-Learning.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: "Preference Learning" -type: concept -tags: [ai, personalization, machine-learning] -last_updated: 2026-04-17 ---- - -## Definition -AI Agent 通过与用户交互逐渐学习并记住用户偏好，用于持续优化内容筛选和推荐结果。 - -## How It Works -1. 初始交互：用户设定偏好规则（如"不包含表情包""喜欢技术类内容"） -2. 反馈收集：每次呈现结果后询问用户是否满意 -3. 规则更新：根据用户反馈调整偏好规则 -4. 持续优化：随着时间推移，筛选结果越来越符合用户需求 - -## Use Cases -- [[Daily Reddit Digest]]：学习用户感兴趣的子版块和内容类型 -- [[Custom Morning Brief]]：根据用户阅读习惯调整新闻优先级 -- 内容推荐系统：个性化推荐引擎的核心机制 - -## Connections -- [[Task Automation]] ← enables ← [[Preference Learning]] -- [[Context Memory]] ← stores ← [[Preference Learning]] -- [[Cron Jobs]] ← schedules ← [[Preference Learning]] - -## References -- 通过 Memory 目录存储用户偏好规则 -- 每次交互后更新规则，形成反馈循环 \ No newline at end of file diff --git a/wiki/concepts/Print-Mode.md b/wiki/concepts/Print-Mode.md deleted file mode 100644 index 0a0d88a9..00000000 --- a/wiki/concepts/Print-Mode.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: "Print Mode" -type: concept -tags: [Claude Code, 工具调用] ---- - -## Definition -Print Mode 是 Claude Code 的非交互执行模式，通过 stdin 管道传递任务文本，任务执行完成后自动退出。 - -## Usage -```bash -cat << 'TASK_END' | claude -p print \ - --dangerously-skip-permissions \ - --add-dir ~/.claude/skills/[技能名] \ - --add-dir [项目源码路径] \ - --max-turns 30 \ - 2>&1 -[任务描述] -TASK_END -``` - -## Key Parameters -- `-p print`：启用 Print Mode -- `--add-dir`：添加可访问目录，可多次使用 -- `--max-turns`：最大迭代次数，建议 20-30 -- `--permission-mode bypassPermissions`：跳过所有交互确认 - -## Advantages -- 适合绝大多数任务 -- 通过管道传递任务文本，避免 shell 转义问题 -- 任务完成自动退出，无需手动关闭 - -## Related -- [[TMUX 交互模式]] -- [[Claude Code 调用方法总结]] \ No newline at end of file diff --git a/wiki/concepts/Private-Cloud.md b/wiki/concepts/Private-Cloud.md deleted file mode 100644 index a5e6977b..00000000 --- a/wiki/concepts/Private-Cloud.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: "Private Cloud" -type: concept -tags: [Cloud, Deployment-Model] -sources: [Public-vs-Private-vs-Hybrid-Cloud-Differences-Explained] -last_updated: 2025-06-18 ---- - -## Summary -Private Cloud（私有云）是专属于单一组织的云计算部署模式，提供更高的安全性、控制力和定制化能力。 - -## Definition -私有云是专门为单一组织构建和运营的云计算环境，可部署在本地数据中心或由第三方托管。组织独享所有计算资源，不与其他用户共享。 - -## Key Characteristics -- 专用资源：不与其他组织共享 -- 高安全性：适合敏感工作负载 -- 高控制力：完全掌控基础设施和配置 -- 可定制：可根据组织需求定制 -- 合规性支持：更容易满足行业法规要求 -- 可内部管理或外包托管 - -## Advantages -- 专用环境确保数据隔离 -- 可定制安全协议和配置 -- 高可扩展性（不牺牲安全） -- 可靠的高性能 -- 灵活适应业务变化 -- 无资源竞争和延迟问题 - -## Limitations -- 成本较高（专用资源） -- 远程访问受限 -- 扩展性依赖物理资源 -- 需要内部技术专长 -- 可能资源利用率不足 - -## When to Use -- 高度监管行业（金融、医疗、政府） -- 处理敏感数据 -- 需要强安全控制的关键工作负载 -- 大型企业需要高级数据中心技术 -- 有充足预算投资高性能基础设施 - -## Connections -- [[Private-Cloud]] ← type_of ← [[Cloud-Adoption]] -- [[Private-Cloud]] ← opposed_by ← [[Public-Cloud]] -- [[Private-Cloud]] ← combines → [[Hybrid-Cloud]] diff --git a/wiki/concepts/Proactive-Recommendations.md b/wiki/concepts/Proactive-Recommendations.md deleted file mode 100644 index 11a2809d..00000000 --- a/wiki/concepts/Proactive-Recommendations.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "Proactive Recommendations" -type: concept -tags: [ai-agent, automation, task-automation] -sources: [custom-morning-brief] -last_updated: 2026-04-17 ---- - -## Summary -AI Agent 主动思考并推荐可以自主完成的任务，而非被动等待用户指令。 - -## Definition -AI Agent 基于上下文分析，主动推荐并执行对用户有价值 tasks 的能力。 - -## Why Powerful -- 将 AI 从被动工具转化为主动助手 -- 利用 AI 不间断运行的特点，在夜间也能产生价值 -- 减少用户早晨的认知负担 - -## Key Mechanism -1. Agent 分析用户的任务列表、日程、上下文 -2. 识别可以自动完成的任务 -3. 生成推荐并说明可以完成的原因 -4. 用户确认后执行 - -## Connection to Morning Brief -在 Custom Morning Brief 中，AI 推荐任务是最有价值的功能模块，让用户起床时发现工作已经完成。 - -## Connections -- [[Agentic AI]] ← enables ← [[Proactive Recommendations]] -- [[Morning Brief]] ← includes ← [[Proactive Recommendations]] -- [[Task Automation]] ← extends ← [[Proactive Recommendations]] \ No newline at end of file diff --git a/wiki/concepts/Process-Management.md b/wiki/concepts/Process-Management.md deleted file mode 100644 index 868d8412..00000000 --- a/wiki/concepts/Process-Management.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: Process Management -type: concept -tags: [system-administration, linux, process] -sources: - - These 6 Linux apps let you monitor system resources in style -last_updated: 2025-12-16 ---- - -## Definition -进程管理，指在操作系统中搜索、监控、终止进程，以及调整进程优先级等操作。 - -## Key Operations -- 进程搜索与过滤 -- 进程终止（正常终止 / 强制杀死） -- 进程优先级调整（Nice 值） -- 信号发送（SIGTERM、SIGKILL 等） -- 查看进程资源占用 - -## Tools Supporting Process Management -- [[Btop++]]：支持搜索、终止、信号发送、Nice 值调整 -- [[Htop]]：支持搜索、终止（F9）、优先级调整（F7/F8） -- [[Glances]]：支持浏览、快速终止（'k'） -- [[Mission Center]]：支持终止、强制终止 -- [[Stacer]]：支持进程审查与终止 -- [[Bottom]]：不支持交互式进程管理（纯监控） - -## Connections -- [[System Resource Monitoring]] ← 上位概念 ← [[Process Management]] -- [[Btop++]] ← 工具 → [[Process Management]] -- [[Htop]] ← 工具 → [[Process Management]] -- [[Glances]] ← 工具 → [[Process Management]] -- [[Mission Center]] ← 工具 → [[Process Management]] -- [[Stacer]] ← 工具 → [[Process Management]] diff --git a/wiki/concepts/Process-Optimization.md b/wiki/concepts/Process-Optimization.md deleted file mode 100644 index fe869c86..00000000 --- a/wiki/concepts/Process-Optimization.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: "Process Optimization" -type: concept -tags: [operations, efficiency, project-management] -sources: [project-management-studio-operations] -last_updated: 2026-04-20 ---- - -## Definition -Process Optimization is the practice of identifying bottlenecks and redesigning workflows to improve efficiency, quality, and reliability. - -## Core Principles -- Standardize repeatable work -- Remove bottlenecks -- Measure outcomes -- Automate where possible - -## Related Entities -- [[Studio Operations]] -- [[Studio Producer]] diff --git a/wiki/concepts/Product-Backlog.md b/wiki/concepts/Product-Backlog.md deleted file mode 100644 index ca971574..00000000 --- a/wiki/concepts/Product-Backlog.md +++ /dev/null @@ -1,21 +0,0 @@ -# Product Backlog - -Product Backlog（产品待办列表）是一个存放待开发功能和需求的区域，高亮显示需求、收益和优先级。 - -## 核心特征 - -- 需求容器：存放所有待处理的功能请求 -- 优先级排序：基于价值、重要性和复杂度进行排序 -- 透明度：确保所有需求在同一标准下被审视 -- 持续演进：随着项目进展不断更新和调整 - -## 组成部分 - -- 新需求：通过 SMACs 提交 -- 评估工具：约 20 个问题的计算器，评估简洁性、成本和野心 -- 入池机制：评估后移入 Octane 作为特性 - -## 相关实践 - -- [[前置条件阶段]]：新团队加入前的准备流程 -- [[Sprint-规划]]：通常提前 6 个迭代规划 \ No newline at end of file diff --git a/wiki/concepts/Product-Requirements-Document.md b/wiki/concepts/Product-Requirements-Document.md deleted file mode 100644 index 5d67fc71..00000000 --- a/wiki/concepts/Product-Requirements-Document.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "Product Requirements Document (PRD)" -type: concept -tags: [product-management, documentation, deliverable] -sources: [product-manager.md] -last_updated: 2026-04-20 ---- - -## Definition -产品规格文档（PRD）是一份系统性定义产品功能需求的文档，涵盖问题陈述、目标与成功指标、用户故事、解决方案概述、技术考量、发布计划和附录。 - -## Structure -1. **Problem Statement**：具体用户痛点或商业机会 -2. **Goals & Success Metrics**：目标、指标、基线、目标值、测量窗口 -3. **Non-Goals**：明确本迭代不解决的问题 -4. **User Personas & Stories**：核心用户故事与验收标准 -5. **Solution Overview**：2-4 段解决方案叙事 -6. **Technical Considerations**：依赖、已知风险、开放问题 -7. **Launch Plan**：内部 alpha → 封闭 beta → GA 分阶段发布 -8. **Appendix**：研究录音、竞品分析、设计稿、仪表盘、支持票据 - -## Key Principles -- 先问题后方案 -- 所有功能想法都是假设，用证据验证 -- PRD 协作编写，工程和设计从一开始就参与 -- 开发前锁定范围并获得所有利益相关方书面签字 -- PRFAQ 练习：写发布邮件和怀疑用户会问的 FAQ - -## Connection -- [[Product Manager Agent]] ← produces ← [[Product Requirements Document (PRD)]] -- [[Discovery Process]] ← feeds_into ← [[Product Requirements Document (PRD)]] -- [[Opportunity Assessment]] ← precedes ← [[Product Requirements Document (PRD)]] diff --git a/wiki/concepts/Product.md b/wiki/concepts/Product.md deleted file mode 100644 index e0acd1ff..00000000 --- a/wiki/concepts/Product.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: "Product" -type: concept -tags: - - OpenText - - product-management -date: 2026-04-19 ---- - -## Definition -产品（Product）是具有独立 CI/CD 流水线或发布周期的软件分发。一个产品可能属于另一个母版产品，但如果该组件有自己的 CI/CD 流水线或发布周期，则应作为产品对待。 - -## Related Concepts -- [[Component]]：没有 CI/CD 流水线的库，可能属于某个产品 -- [[Master-Product]]：官方产品命名注册表中的产品定义 -- [[Product-Backlog]]：产品待办列表 - -## Related Entities -- [[Product-Hub-PHT]] - -## Product Attributes -- 业务单元（Business Unit） -- 业务线（Line of Business） -- 产品名称 -- 产品经理 -- 开发经理 -- 产品状态（活跃/维护模式/非活跃） - -## External Integrations -- PSMQ -- P2M -- ITLS -- Backstage \ No newline at end of file diff --git a/wiki/concepts/Program-Demand-Process.md b/wiki/concepts/Program-Demand-Process.md deleted file mode 100644 index 349fb961..00000000 --- a/wiki/concepts/Program-Demand-Process.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "Program Demand Process" -type: concept -tags: - - CTP - - Process - - Demand-Management -date: 2026-04-19 ---- - -## Summary -- 定义：从业务需求产生、优先级排序到最终交付迁移的端到端管理路径 -- 驱动因素：业务案例（如数据中心关闭）、高层管理人员战略优先级、产品组路线图 -- 关键环节：需求录入 → 优先级排序 → POC 决策 → Gate 审批 → 迁移至 Labs 或 SaaS - -## Related Concepts -- [[Proof-of-Concept-POC]] — 在需求处理流程中用于验证可行性的阶段 -- [[Gate-Process]] — 治理项目进度的关键决策点 -- [[Landing-Zone]] — 最终交付的目标云环境 - -## Connections -- [[Sergio]] — 流程讲解专家 -- [[Damian]] — 流程讲解专家 - ---- - -*最后更新: 2026-04-19* \ No newline at end of file diff --git a/wiki/concepts/Project-Thor.md b/wiki/concepts/Project-Thor.md deleted file mode 100644 index 5b1afea3..00000000 --- a/wiki/concepts/Project-Thor.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: "Project Thor" -type: concept -tags: [DevOps, Platform, OpenText] ---- - -## Summary -OpenText 云平台标准化项目，通过五大支柱框架实现工具链统一和供应链安全。 - -## Five Pillars -- 敏捷和正确的周期管理（Agile and Right Cycle Management） -- 产品和发布治理（Product and Release Governance） -- Developer Portal（基于 Backstage） -- Security as Governance（安全作为治理） -- Build Hub（构建中心） - -## Goal -标准化工具链，整合治理模型，推广 GitLab、Artifactory 等工具，提升开发者体验和供应链安全。 - -## Connections -- [[GitLab]] — 源代码托管 -- [[Artifactory]] — 制品仓库 -- [[OpenText]] — 所属公司 \ No newline at end of file diff --git a/wiki/concepts/Prometheus.md b/wiki/concepts/Prometheus.md deleted file mode 100644 index 59535f6b..00000000 --- a/wiki/concepts/Prometheus.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: "Prometheus" -type: concept -tags: [monitoring, prometheus, time-series, devops] -sources: [家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox] -last_updated: 2026-04-16 ---- - -## Definition -Prometheus 是开源的时序数据库和监控系统，采用拉取（Pull）模式采集指标，支持 PromQL 查询语言和告警规则引擎。 - -## Key Features -- **拉取模式**：主动从 exporters 拉取指标数据 -- **PromQL**：强大的时序数据查询语言 -- **告警规则**：支持定义告警条件和阈值 -- **多数据源**：可对接多种 exporters（node_exporter、cAdvisor、blackbox_exporter） -- **服务发现**：支持动态服务发现（Kubernetes、Consul 等） - -## Architecture -- **Prometheus Server**：采集、存储时序数据 -- **Exporters**：指标采集器（node_exporter、cAdvisor、blackbox_exporter） -- **Alertmanager**：告警分发和处理 -- **Pushgateway**：支持推送模式的网关（用于短期任务） - -## Common Metrics Types -- Counter：递增计数器 -- Gauge：当前值（可增可减） -- Histogram：直方图分布 -- Summary：分位数统计 - -## Connections -- [[Prometheus]] → scrapes → [[node_exporter]] -- [[Prometheus]] → scrapes → [[cAdvisor]] -- [[Prometheus]] → scrapes → [[Blackbox_exporter]] -- [[Prometheus]] → sends_alerts → [[Alertmanager]] -- [[Prometheus]] ← visualized_by → [[Grafana]] -- [[Prometheus]] ← core_component → [[监控可观测性]] \ No newline at end of file diff --git a/wiki/concepts/Prompt-Engineering.md b/wiki/concepts/Prompt-Engineering.md deleted file mode 100644 index ebc49722..00000000 --- a/wiki/concepts/Prompt-Engineering.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "Prompt Engineering" -type: concept -tags: - - AI - - Prompt-Engineering - - LLM -date: 2024-11-12 ---- - -## Summary -提示词工程（Prompt Engineering）是创建、设计和优化提示词以引导大语言模型（LLM）响应的过程，确保输出的准确性和相关性。 - -## Definition -Prompt Engineering（提示词工程）是指通过精心设计提示词来提升 AI 输出质量的技术，涵盖需求拆解、结构化表达、场景共情、迭代优化四个维度。 - -## Key Components -提示词由以下组件构成： -- **指令（Instructions）**：明确告诉模型要做什么 -- **上下文（Context）**：提供背景信息 -- **用户输入（User Input）**：具体问题或任务 -- **输出指示器（Output Indicator）**：提示模型输出格式 - -## Basic Techniques -- **One-shot Prompting**：提供一个示例 -- **Few-shot Prompting**：提供多个示例 -- **Chain of Thoughts**：提供逐步思考过程 - -## Connections -- [[LLM]] ← guides ← Prompt Engineering：提示词工程引导大语言模型 -- [[Generative AI]] ← uses ← Prompt Engineering：生成式 AI 应用提示词工程 -- [[Claude Skills]] ← relies_on ← Prompt Engineering：Claude Skills 基于提示词工程技术 \ No newline at end of file diff --git a/wiki/concepts/Prompt-Library.md b/wiki/concepts/Prompt-Library.md deleted file mode 100644 index b4798433..00000000 --- a/wiki/concepts/Prompt-Library.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: "Prompt Library" -type: concept -tags: [] ---- - -## Description -提示词库，提供现成提示词供用户参考和定制的资源集合。存在于不同平台上，用户可以从中寻找灵感或直接使用 готовые提示词。 - -## Value -- 显著减少提示词创建时间和精力 -- 为用户提供特定任务的现成解决方案 -- 帮助新手快速上手 AI 工具 - -## Related Concepts -- [[提示语设计]] - -## Related Sources -- [[never-write-another-prompt]] \ No newline at end of file diff --git a/wiki/concepts/Prompt-Structure-Framework.md b/wiki/concepts/Prompt-Structure-Framework.md deleted file mode 100644 index cc0fe18d..00000000 --- a/wiki/concepts/Prompt-Structure-Framework.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: "Prompt Structure Framework" -type: concept -tags: [prompt-engineering, ai-image-generation, framework] -date: 2026-04-20 ---- - -## Summary -提示词结构框架是一种将视觉概念分解为分层组件的提示词设计方法论，用于生成专业级 AI 摄影作品。 - -## Definition -Prompt Structure Framework 是 Image Prompt Engineer 使用的分层提示词结构，将提示词分解为核心组件：主体描述层、环境与设置层、灯光规格层、技术摄影层、风格与美学层。 - -## Key Components -五个分层组件： -1. **主体描述层**：主要焦点、属性、表情、姿态、材质、比例 -2. **环境与设置层**：位置类型、环境细节、背景处理、大气条件 -3. **灯光规格层**：光源、方向、质量、色温 -4. **技术摄影层**：相机视角、焦距、景深、曝光风格 -5. **风格与美学层**：摄影类型、时代风格、后期处理、参考摄影师 - -## Application Patterns -人像摄影模式： -``` -[Subject] | [Pose] | [Background] | [Lighting: key, fill, rim, hair light] | [Camera: 85mm f/1.4] | [Style] | [Color palette] | [Reference] -``` - -产品摄影模式： -``` -[Product] | [Surface] | [Lighting: softbox] | [Camera: angle] | [Hero shot/lifestyle] | [Brand aesthetic] | [Post-processing] -``` - -## Connections -- [[Prompt Engineering]] ← defines ← Prompt Structure Framework：提示词结构框架是提示词工程的具体应用 -- [[Image Prompt Engineer]] ← uses ← Prompt Structure Framework：Image Prompt Engineer 使用该框架 -- [[Photography Terminology]] ← integrates_with ← Prompt Structure Framework：摄影术语集成于该框架 \ No newline at end of file diff --git a/wiki/concepts/Proof-of-Concept-POC.md b/wiki/concepts/Proof-of-Concept-POC.md deleted file mode 100644 index 2eb5fea1..00000000 --- a/wiki/concepts/Proof-of-Concept-POC.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: "Proof of Concept (POC)" -type: concept -tags: - - CTP - - Validation - - Risk-Management -date: 2026-04-19 ---- - -## Summary -- 定义：概念验证，在正式迁移前用于证明架构可行性、测试复杂网络需求及验证迁移方法的实验性阶段 -- 核心目的：降低迁移风险，验证架构和技术可行性，让团队熟悉基于 Gruntwork 构建的新一代 Landing Zone -- 预期成果： - - 经过验证的解决方案设计 - - 准备就绪的 IaC 脚本（Terraform/Terragrunt） - - 明确的迁移时间表 - -## Success Criteria -- POC 的成功标准应在启动前明确定义 -- 测试活动需有效证明产品已具备进入生产环境迁移的条件 - -## Related Concepts -- [[Program-Demand-Process]] — POC 的前置流程 -- [[Gate-Process]] — POC 需要通过的审批关卡 -- [[Infrastructure-as-Code-IaC]] — POC 阶段需要准备的核心交付物 -- [[Landing-Zone]] — POC 熟悉的目标环境 - -## Connections -- [[PCG-Team]] — 协助产品组进行 POC 的核心团队 - ---- - -*最后更新: 2026-04-19* \ No newline at end of file diff --git a/wiki/concepts/Proposal-Strategy.md b/wiki/concepts/Proposal-Strategy.md deleted file mode 100644 index 285c15a8..00000000 --- a/wiki/concepts/Proposal-Strategy.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: "Proposal Strategy" -type: concept -tags: [Proposal, Sales, Strategy] -last_updated: 2026-04-20 ---- - -## Definition -提案策略（Proposal Strategy）是将 RFP 响应转化为说服性叙事的方法论，核心信念是"提案因清晰而赢，因通用而输"。它不仅仅是回答合规要求，而是构建一个统一的论点，说明为什么这个买家应该选择这个解决方案。 - -## Core Components -- [[Win Theme]] Development：开发 3-5 个制胜主题 -- [[Three-Act Proposal Narrative]]：三幕式提案叙事结构 -- [[Executive Summary]] Craft：执行摘要撰写 -- [[Competitive Positioning]]：竞争定位策略 -- Content Quality Standards：内容质量标准 - -## Key Principles -1. **Never write generic proposals**：如果买家名称、挑战和背景可以替换为另一个客户而不改变内容，提案就已经在失败 -2. **Win themes must be integrated**：制胜主题必须在执行摘要、解决方案、案例研究、定价中贯穿出现 -3. **No negative selling**：不要直接批评竞争对手，通过框架化优势创造有机对比 -4. **Compliance is floor, not ceiling**：合规是地板而非天花板，需在每个合规答案中添加战略背景 -5. **Pricing comes after value**：先建立 ROI 案例，再谈价格 - -## Deliverables -- Win Theme Matrix：制胜主题矩阵 -- Executive Summary Template：执行摘要模板 -- Proposal Architecture Blueprint：提案架构蓝图 -- Compliance Checklist + Strategic Overlay：合规清单与战略叠加 - -## Connections -- [[Proposal Strategy]] → uses → [[Win Theme]] -- [[Proposal Strategy]] → uses → [[Three-Act Proposal Narrative]] -- [[Proposal Strategy]] → uses → [[Executive Summary]] -- [[Proposal Strategy]] → uses → [[Competitive Positioning]] \ No newline at end of file diff --git a/wiki/concepts/Propp-叙事形态学.md b/wiki/concepts/Propp-叙事形态学.md deleted file mode 100644 index 4a1f5ead..00000000 --- a/wiki/concepts/Propp-叙事形态学.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: "Propp 叙事形态学" -type: concept -tags: [narrative-theory, story-structure, fairy-tale] ---- - -## 定义 -Vladimir Propp 提出的民间故事形态分析方法，识别出 31 种叙事功能（Functions），将故事结构分解为可重复的最小叙事单元。 - -## 核心概念 -- 叙事功能：故事中角色完成的固定动作，如「禁止」「违反」「 villainy 」「 departure 」等 -- 角色类型：Propp 识别出 7 种角色角色：英雄（Hero）、捐赠者（Donor）、帮助者（Helper）、 princess/golden object、派遣者（Dispatcher）、 villain（对手）、假冒英雄（False Hero） -- 叙事序列：功能按固定顺序出现，但并非所有功能都必然出现 - -## 应用领域 -- 民间故事与童话分析 -- Quest 游戏结构设计 -- 编剧三幕式结构前身 - -## 来源框架 -- [[Narratologist]] 使用此框架分析民间故事结构和 quest 叙事 - -## 相关概念 -- [[Campbell 英雄之旅]] -- [[Vogler 作家旅程]] -- [[三幕结构]] diff --git a/wiki/concepts/Public-Cloud.md b/wiki/concepts/Public-Cloud.md deleted file mode 100644 index ce9b4716..00000000 --- a/wiki/concepts/Public-Cloud.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: "Public Cloud" -type: concept -tags: [Cloud, Deployment-Model] -sources: [Public-vs-Private-vs-Hybrid-Cloud-Differences-Explained] -last_updated: 2025-06-18 ---- - -## Summary -Public Cloud（公有云）是由第三方提供商通过互联网共享交付的云计算模式，多个用户共享同一基础设施。 - -## Definition -公有云是由第三方服务提供商（如 AWS、Azure、Google Cloud）通过互联网向公众提供计算资源（服务器、存储、应用程序）的云计算部署模式。用户按需付费，无需前期资本投资。 - -## Key Characteristics -- 资源共享：多个租户共享同一基础设施 -- 高弹性：可根据需求快速扩展或收缩资源 -- 低成本：无前期投资，按使用量付费 -- 快速部署：可在几分钟内启动服务 -- 由提供商负责基础设施管理 - -## Advantages -- 无需资本投资 -- 可从任何有网络的地方访问 -- 技术敏捷性高 -- 专业管理和维护 -- 支持远程协作 -- 成本可预测（按需计费） -- 快速灾难恢复 - -## Limitations -- 安全性较低（共享环境） -- 对关键工作负载控制有限 -- 大规模使用可能导致成本上升 -- 供应商依赖风险 -- 合规性挑战 - -## When to Use -- 可预测的计算需求 -- 开发和测试环境 -- 应对峰值负载 -- 非敏感业务应用 - -## Connections -- [[Public-Cloud]] ← type_of ← [[Cloud-Adoption]] -- [[Public-Cloud]] ← opposed_by ← [[Private-Cloud]] -- [[Public-Cloud]] ← combines → [[Hybrid-Cloud]] -- [[Public-Cloud]] ← delivers ← [[IaaS]] -- [[Public-Cloud]] ← delivers ← [[PaaS]] -- [[Public-Cloud]] ← delivers ← [[SaaS]] diff --git a/wiki/concepts/Pull-Model.md b/wiki/concepts/Pull-Model.md deleted file mode 100644 index 7e89e52a..00000000 --- a/wiki/concepts/Pull-Model.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: "Pull Model" -type: concept -tags: [DevOps, GitOps, CD, 部署] -sources: [ctp-topic-33-an-introduction-to-gitops.md] -last_updated: 2026-04-19 ---- - -## Definition -Pull Model（拉取模型）是 GitOps 推荐的一种持续交付实现模式，GitOps Agent 持续监控 Git 仓库和目标系统的状态，自动将 Git 中的期望状态同步到实际运行环境。 - -## How It Works -1. GitOps Agent 安装在目标环境（如 Kubernetes 集群） -2. Agent 持续轮询 Git 仓库检测配置变化 -3. Agent 同时监控实际系统状态 -4. 当检测到差异时，自动将变更同步到目标系统 - -## Advantages -- 更安全：无需开放外部访问权限到集群 -- 更好的可见性：Agent 直接观察实际状态 -- 自我修复：自动纠正配置漂移 -- 简化网络架构：无需入站 webhook - -## Comparison with Push Model -| 特性 | Pull Model | Push Model | -|------|-----------|------------| -| 触发方式 | Agent 主动拉取 | CI/CD 流水线推送 | -| 部署位置 | Agent 运行在目标环境 | CI/CD 工具运行在外部 | -| 安全性 | 更高，无需开放入站端口 | 需要开放 webhook 端口 | -| 复杂度 | 较低（无外部依赖） | 较高（需要 CI/CD 集成） | - -## Related Concepts -- [[GitOps]] -- [[CI/CD 流水线]] -- [[Idempotent Operation]]（幂等操作） - -## Related Sources -- [[ctp-topic-33-an-introduction-to-gitops]] — GitOps 入门介绍 \ No newline at end of file diff --git a/wiki/concepts/Pull-Request-流程.md b/wiki/concepts/Pull-Request-流程.md deleted file mode 100644 index 2d19e503..00000000 --- a/wiki/concepts/Pull-Request-流程.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: "Pull Request 流程" -type: concept -tags: [workflow, collaboration] ---- - -## 定义 -从提交前准备到 PR 审核的完整协作流程。 - -## 流程阶段 -1. **提交前**：测试智能体、遵循模板、补充示例、定义指标、校对检查 -2. **提交 PR**：Fork 仓库、创建分支、完成修改、提交、推送、发起 PR -3. **PR 审核**：社区评审 → 迭代优化 → 通过审核 → 合并上线 - -## PR 模板要素 -- 智能体信息（名称、分类、专长） -- 创作动机 -- 测试情况 -- 检查清单 \ No newline at end of file diff --git a/wiki/concepts/Pumui-Consensus-Approval.md b/wiki/concepts/Pumui-Consensus-Approval.md deleted file mode 100644 index be9b6b55..00000000 --- a/wiki/concepts/Pumui-Consensus-Approval.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -title: "품의（共识审批）" -id: pumui-consensus-approval -type: concept -tags: [korea, business, decision-making, culture] -sources: [[specialized-korean-business-navigator]] -last_updated: 2026-04-20 ---- - -## Definition -품의（品夠）是韩国企业的集体决策机制，需要多方批准而非个人拍板。与西方"决策者拍板"模式相反，품의强调共识构建和责任分散。 - -## Core Process - -``` -소개（介绍）→ 미팅（会议）→ 내부검토（内部审查） -→ 품의서 작성（品夠서起草）→ 결재 라인（审批链） -→ 예산확인（预算确认）→ 계약（合同） -``` - -## Timeline by Company Type - -| 公司类型 | 决策周期 | -|---|---| -| SME（中小企业） | 6-10周 | -| Mid-cap（中型企业） | 8-12周 | -| Chaebol（财阀） | 12-16周 | - -西方模式：2-4周 - -## Key Documents - -- **품의서（品夠审批文件）**：由联系人撰写，供应商无法看到或影响其内容 - -## Critical Rules - -1. **绝对不能在首次会议推动决策时间线**——这表明不了解韩国文化 -2. **永远不要绕过联系人直接联系其上级**——这是关系终结行为 -3. **沉默（3-7天）不等于拒绝**——内部讨论正在进行中 - -## Nunchi Signals - -| 阶段 | 正面信号 | 需关注 | -|---|---|---| -|介绍 | 有受尊重的人引荐 | 无引荐冷启动响应率<5% | -|会议 | 邀请同事参加第二次会议 | 仅单人参加无扩展 | -|内部审查 | 要求参考案例 | 无反馈 | -|품의서 | 要求具体定价/范围/时间 | — | -|결재 | "상부에서 검토 중입니다"（正在上级审查）| 沉默≠拒绝 | - -## Related Concepts -- [[Nunchi（눈치）]] -- [[关系生命周期]] - -## Related Entities -- [[결재 라인]]（审批链） -- [[품의서]] \ No newline at end of file diff --git a/wiki/concepts/Purpose-Built-Database.md b/wiki/concepts/Purpose-Built-Database.md deleted file mode 100644 index 5870f951..00000000 --- a/wiki/concepts/Purpose-Built-Database.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: "Purpose-Built Database" -type: concept -tags: [database, AWS, architecture] -date: 2026-04-18 ---- - -## Definition -专用数据库（Purpose-Built Database）为特定用例优化的数据库架构。根据用例选择最佳工具，避免一刀切的数据库架构。 - -## Rationale -现代应用程序从传统的客户端-服务器模型演进，原因包括： -- 客户需求变化 -- 新设备类型多样化 -- 数据类型多样化 -- 经济因素 - -选择专用数据库需考虑： -- 应用规模 -- 用户数量 -- 访问模式 -- 使用高峰 -- 性能要求（延迟、可用性） - -## AWS Database Portfolio -| 数据库类型 | AWS 服务 | 适用场景 | -|------------|---------|----------| -| 关系型 | Aurora, RDS | 固定模式、事务处理 | -| 键值 | DynamoDB | 高扩展、低延迟 | -| 文档 | DocumentDB | JSON 文档、灵活模式 | -| 内存 | ElastiCache | 缓存、实时分析 | -| 图形 | Neptune | 欺诈检测、推荐 | -| 时序 | Timestream | IoT、监控数据 | -| 宽列 | Keyspaces | 大规模写入 | - -## Sources -- [[ctp-topic-51-architecting-with-aws-purpose-built-databases]] \ No newline at end of file diff --git a/wiki/concepts/Pydantic参数验证.md b/wiki/concepts/Pydantic参数验证.md deleted file mode 100644 index bc49159e..00000000 --- a/wiki/concepts/Pydantic参数验证.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -title: "Pydantic参数验证" -type: concept -tags: [python, validation, mcp] -date: 2026-04-20 ---- - -## Definition -在 Python MCP Server 中使用 Pydantic 为工具参数提供运行时类型验证、默认值和字段约束。 - -## Key Points -- 适合 Python FastMCP / MCP Server 实现 -- 将输入校验前置到工具边界 -- 让错误更可读、更可操作 - -## Connections -- [[MCP Builder]] -- [[MCP服务器]] diff --git a/wiki/concepts/QBR.md b/wiki/concepts/QBR.md deleted file mode 100644 index 29545745..00000000 --- a/wiki/concepts/QBR.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: "QBR (Quarterly Business Review)" -type: concept -tags: [sales, account-strategy, review] -date: 2026-04-20 ---- - -## Definition -QBR（Quarterly Business Review，季度业务回顾）是一种结构化的客户沟通机制，将前瞻性战略规划与回顾性状态报告结合。 - -## QBR vs EBR -| Aspect | QBR | EBR | -|--------|-----|-----| -| Focus | Forward-looking | Backward-looking | -| Value | Strategic planning | Status reporting | -| Outcome | Mutual action plan | Slide deck | - -## QBR Agenda Framework (60 minutes) -1. **Value Delivered** (15 min)：ROI recap with hard numbers -2. **Their Roadmap** (20 min)：Where is the business going? What challenges ahead? -3. **Product Alignment** (15 min)：How we evolve together -4. **Mutual Action Plan** (10 min)：Commitments, owners, next steps - -## Key Questions to Ask -- "What are the top three business priorities for the next two quarters?" -- "Where are you spending time on manual work that should be automated?" -- "Who else in the organization is trying to solve similar problems?" -- "What would make you confident enough to expand our partnership?" - -## Best Practices -- Open with quantified ROI data -- Close with mutual action plan -- Surface new stakeholders and validate org map - -## References -- [[Sales Account Strategist]] \ No newline at end of file diff --git a/wiki/concepts/QMD.md b/wiki/concepts/QMD.md deleted file mode 100644 index c8a8842c..00000000 --- a/wiki/concepts/QMD.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: "QMD" -type: concept -tags: [] ---- - -## 定义 -完全本地运行的 Markdown 搜索引擎（github.com/tobi/qmd），用于 Wiki 规模变大后的精准搜索。 - -## 使用场景 -- Wiki 页面数量达到几百个后，`index.md` 目录文件已不够用 -- AI 找东西开始变慢，需要更高效的搜索能力 -- 纯本地运行，不依赖外部服务 - -## 判断标准 -Wiki 到几百个页面之前，`index.md` 完全够用；等 AI 找东西开始变慢，再接入 QMD 也不迟。 - -## 关联 -- [[Obsidian]] -- [[Graph View]] \ No newline at end of file diff --git a/wiki/concepts/Quality-Gates.md b/wiki/concepts/Quality-Gates.md deleted file mode 100644 index 3a8176ae..00000000 --- a/wiki/concepts/Quality-Gates.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: "Quality Gates" -type: concept -tags: [multi-agent, quality, workflow] -last_updated: 2026-04-21 ---- - -## Definition -质量门控（Quality Gates）是多智能体工作流中的关键检查点，在进入下一阶段前对当前输出进行生产就绪评估。 - -## Core Principle -在关键节点设置质量门槛，只有满足所有标准才能继续推进。 - -## Quality Gate Points -在 Multi-Agent Workflow: Startup MVP 中设置了两个质量门控： - -### Gate 1: Week 2 中点评估 -- 评估当前进度是否可达成目标 -- 识别需要削减的范围 -- 识别会，影响 Launch 的技术债务 - -### Gate 2: Week 4 最终评估 -- 评估产品 Launch 就绪状态 -- 检查错误监控、数据库备份等运维就绪 -- 要求证据支持每个验收标准 -- 提供 GO / NO-GO 决策 - -## Decision Outcomes -- **GO**：满足所有标准，可以进入下一阶段 -- **NO-GO**：不满足标准，需要修复后重新评估 -- **NEEDS WORK**：默认决策，保守策略 - -## Related Concepts -- [[Reality Checker]]：质量门控的执行者 -- [[Sequential Handoffs]]：顺序交接模式 -- [[Parallel Work]]：并行工作模式 -- [[Context Passing]]：上下文传递 -- [[Multi-Agent Team]]：多智能体团队 diff --git a/wiki/concepts/Qwen2.5-Coder.md b/wiki/concepts/Qwen2.5-Coder.md deleted file mode 100644 index 6653eb04..00000000 --- a/wiki/concepts/Qwen2.5-Coder.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: "Qwen2.5-Coder" -type: concept -tags: [ai, llm, code-generation, qwen] ---- - -## Description -阿里通义千问（Qwen）系列的代码生成模型，2.5 版本。7B 参数版本大小约 4.5GB，适合本地运行。 - -## Key Capabilities -- 代码生成（Python、Shell、SQL 等） -- 代码理解与分析 -- Repo 级代码理解 -- 强大的 Tool usage 能力 -- 适合工程任务（DevOps 自动化、SQL Agent、Kubernetes 故障排查） - -## Model Variants -| 型号 | 参数 | 大小 | 推荐配置 | -|-----|------|------|----------| -| qwen2.5-coder:3b | 3B | ~2GB | 8GB RAM | -| qwen2.5-coder:7b | 7B | ~4.5GB | 16GB RAM | - -## Compared to Qwen2.5 -Qwen2.5-Coder 在工程任务上优于普通 Qwen2.5，特别适合： -- Tool usage -- Shell/Python/SQL 理解 -- 代码理解和生成 - -## Connections -- [[Ollama]] ← hosts ← [[Qwen2.5-Coder]] -- [[OpenClaw]] ← uses ← [[Qwen2.5-Coder]] \ No newline at end of file diff --git a/wiki/concepts/RAG.md b/wiki/concepts/RAG.md deleted file mode 100644 index 20461246..00000000 --- a/wiki/concepts/RAG.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "RAG" -type: concept -tags: [llm, rag, ai] -date: 2026-04-18 ---- - -## Description -检索增强生成（Retrieval-Augmented Generation），为 LLM 提供外部实时知识的机制，被誉为 LLM 的"随身图书馆助理"。 - -## Core Problem -LLM 只能回答训练数据截止时间之前的问题，对实时信息一无所知。LLM 在思考方面非常出色，但对当前情况却一无所知。 - -## Key Components -- **检索（Retrieval）**：从外部知识库（向量数据库、知识图谱、公司内部文档等）检索最相关的信息块 -- **增强生成（Augmented Generation）**：将检索到的内容作为上下文输入 LLM，指示其基于这些上下文生成答案 - -## Key Benefits -1. **知识更新与定制**：无需重新训练 LLM 即可获取最新信息 -2. **消除幻觉**：通过提供事实依据，极大降低 LLM 胡编乱造的风险 -3. **引用来源**：可提供信息来源链接或文档页码，增加可信度 - -## Related Technologies -- [[向量数据库]]：存储和检索知识的技术 -- [[NL2SQL]]：自然语言转 SQL，使 Agent 能直接查询数据库 - -## Connections -- 依赖 [[LLM]] 进行答案生成 -- 与 [[开源平替]] 结合实现私有化部署 -- 使用 [[语义搜索]] 提高检索精度 \ No newline at end of file diff --git a/wiki/concepts/RFM-Analysis.md b/wiki/concepts/RFM-Analysis.md deleted file mode 100644 index dc120253..00000000 --- a/wiki/concepts/RFM-Analysis.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: "RFM Analysis" -type: concept -tags: [] -last_updated: 2026-04-21 ---- - -## Definition -客户价值分析的经典方法，通过三个维度评估客户：Recency（最近购买时间）、Frequency（购买频率）、Monetary（消费金额）。 - -## Scoring Method -- R Score：最近购买距离当前天数，越小分数越高（1-5 分） -- F Score：购买次数排名分位数（1-5 分） -- M Score：消费总额分位数（1-5 分） -- RFM Score：三个分数组合形成 555-111 的客户评分 - -## Customer Segments -| RFM Score | Segment | Strategy | -|-----------|---------|----------| -| 555, 554, 544, 545, 454, 455, 445 | Champions | 奖励忠诚度，请求推荐，升级 | -| 543, 444, 435, 355, 354, 345, 344, 335 | Loyal Customers | 培育关系，推荐新产品，会员计划 | -| 553, 551, 552, 541, 542, 533, 532, 531, 452, 451 | Potential Loyalists | 升级优惠，交叉销售 | -| 512, 511, 422, 421, 412, 411, 311 | New Customers | 优化入职，早期互动 | -| 155, 154, 144, 214, 215, 115, 114 | At Risk | 再激活活动，特别优惠 | - -## Implementation -```python -# RFM Analysis Python Implementation -rfm = df.groupby('customer_id').agg({ - 'date': lambda x: (current_date - x.max()).days, # Recency - 'order_id': 'count', # Frequency - 'revenue': 'sum' # Monetary -}).rename(columns={ - 'date': 'recency', - 'order_id': 'frequency', - 'revenue': 'monetary' -}) -``` - -## Related Concepts -- [[Customer Lifetime Value]] -- [[Data-Driven Decision Making]] - -## Source -- [[support-analytics-reporter]] - diff --git a/wiki/concepts/RICE-Framework.md b/wiki/concepts/RICE-Framework.md deleted file mode 100644 index d4ea6337..00000000 --- a/wiki/concepts/RICE-Framework.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: "RICE Framework" -type: concept -tags: [prioritization, agile, product-management] -sources: [raw/Agent/agency-agents/product/product-sprint-prioritizer.md] -last_updated: 2026-04-20 ---- - -## Definition -数据驱动的功能优先排序框架，通过四个维度量化评估每个功能的潜在价值。 - -## Components -- **Reach（触达）**：单位时间内受影响的用户数量 -- **Impact（影响）**：对业务目标的贡献度（0.25-3 刻度） -- **Confidence（信心）**：估计的确定性（百分比） -- **Effort（工作量）**：开发所需时间（人月） - -## Formula -Score = (Reach × Impact × Confidence) ÷ Effort - -## Application -用于在多个候选功能之间进行客观比较，选择高价值低工作量的特性优先开发。 - -## Related Concepts -- [[MoSCoW Method]] -- [[Kano Model]] -- [[Team Velocity]] -- [[Sprint Planning]] - -## Source Reference -- [[Product Sprint Prioritizer]] diff --git a/wiki/concepts/RICE-Prioritization-Score.md b/wiki/concepts/RICE-Prioritization-Score.md deleted file mode 100644 index 38b8d0d3..00000000 --- a/wiki/concepts/RICE-Prioritization-Score.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: "RICE Prioritization Score" -type: concept -tags: [product-management, prioritization, metrics] -sources: [product-manager.md] -last_updated: 2026-04-20 ---- - -## Definition -RICE 是用于客观优先级排序的量化框架，通过四个维度计算分数：Reach（触达）、Impact（影响）、Confidence（信心）、Effort（努力）。 - -## Formula -**RICE Score = (R × I × C) ÷ E** - -| Factor | Scale | Description | -|--------|-------|-------------| -| Reach | 用户数/季度 | 多少人受影响 | -| Impact | 0.25, 0.5, 1, 2, 3 | 对指标的影响倍数 | -| Confidence | 百分比 | 估计的信心水平 | -| Effort | 人力月数 | 需要多少时间 | - -## Example Calculation -| Factor | Value | Notes | -|--------|-------|-------| -| Reach | 10,000 users/quarter | Source: analytics | -| Impact | 0.5 | half of 1x | -| Confidence | 80% | Based on: interviews | -| Effort | 4 person-months | M t-shirt | -| **RICE Score** | **100** | | - -## Use Case -- 跨多个机会客观排序 -- 支撑 build/defer/kill 决策对话 -- 替代直觉式优先级排序 - -## Limitation -- 估算性质，结果应作为讨论起点而非绝对值 -- 不捕捉战略重要性或风险 -- 需要定期重新评估 - -## Connection -- [[RICE Prioritization Score]] ← calculated_in ← [[Opportunity Assessment]] -- [[Roadmap (Now / Next / Later)]] ← ranks ← [[RICE Prioritization Score]] -- [[Product Backlog]] ← prioritized_by ← [[RICE Prioritization Score]] diff --git a/wiki/concepts/RICE评分.md b/wiki/concepts/RICE评分.md deleted file mode 100644 index a6fa5fce..00000000 --- a/wiki/concepts/RICE评分.md +++ /dev/null @@ -1,49 +0,0 @@ ---- -title: "RICE评分" -type: concept -tags: [Product Management, Prioritization Framework] -sources: [product-manager.md, product-feedback-synthesizer.md] -last_updated: 2026-04-20 ---- - -## Definition -RICE评分是一种产品功能优先级排序框架，通过量化四个维度计算优先级分数，用于跨机会客观排序，支撑 build/defer/kill 决策对话。 - -## Components -| Factor | Scale | Description | -|--------|-------|-------------| -| Reach | 用户数/季度 | 多少人受影响 | -| Impact | 0.25, 0.5, 1, 2, 3 | 对指标的影响倍数 | -| Confidence | 百分比 | 估计的信心水平 | -| Effort | 人力月数 | 需要多少时间 | - -## Formula -``` -RICE Score = (Reach × Impact × Confidence) ÷ Effort -``` - -## Example Calculation -| Factor | Value | Notes | -|--------|-------|-------| -| Reach | 10,000 users/quarter | Source: analytics | -| Impact | 0.5 | half of 1x | -| Confidence | 80% | Based on: interviews | -| Effort | 4 person-months | M t-shirt | -| **RICE Score** | **100** | | - -## Usage -- 由 [[Product Feedback Synthesizer]] 用于将用户反馈转化为数据驱动的优先级决策 -- 由 [[Product Manager Agent]] 用于 [[Opportunity Assessment]] 和 [[Roadmap (Now / Next / Later)]] 优先级排序 - -## Limitation -- 估算性质，结果应作为讨论起点而非绝对值 -- 不捕捉战略重要性或风险 -- 需要定期重新评估 - -## Connections -- [[Product Feedback Synthesizer]]：使用此框架进行反馈优先级排序 -- [[MoSCoW优先级]]：另一种优先级框架 -- [[Kano模型]]：满意度导向的功能分类模型 -- [[Opportunity Assessment]] ← calculated_in -- [[Roadmap (Now / Next / Later)]] ← ranks -- [[Product Backlog]] ← prioritized_by diff --git a/wiki/concepts/RPO.md b/wiki/concepts/RPO.md deleted file mode 100644 index 9e8d5b69..00000000 --- a/wiki/concepts/RPO.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "RPO (Recovery Point Objective)" -type: concept -tags: [灾难恢复, 数据保护, 指标] -sources: ["https://launchdarkly.com/blog/rto-vs-rpo/"] -last_updated: 2025-07-26 ---- - -## Definition -RPO（Recovery Point Objective，恢复点目标）是指可接受的最大数据丢失量，以时间度量。从最后一次有效备份到故障发生所经历的时间。 - -## Key Characteristics -- 衡量数据保护程度 -- 从故障时刻向后计算（倒计时） -- 与备份频率直接相关 -- 需要与 RTO 共同规划，不能只优化其中一个 - -## Tiered RPO Targets (from this source) -| Tier | Examples | RPO Target | -|------|----------|------------| -| Critical | Payment processing, user auth | < 1 minute | -| Important | Admin dashboards, reporting | < 15 minutes | -| Nice-to-have | Internal tools, dev environments | < 1 hour | - -## Example -如果数据库在下午3点崩溃，而最后一次备份是下午2点，则 RPO 为1小时。2点到3点之间的所有数据丢失。 - -## Connections -- [[RTO (Recovery Time Objective)]] ← 配对指标 → [[RPO (Recovery Point Objective)]] -- [[灾难恢复]] ← 应用领域 → [[RPO (Recovery Point Objective)]] -- [[持续交付]] ← 现代上下文 → [[RPO (Recovery Point Objective)]] -- [[Feature Flag]] ← 保护工具 → [[RPO (Recovery Point Objective)]] diff --git a/wiki/concepts/RRF-Reranking.md b/wiki/concepts/RRF-Reranking.md deleted file mode 100644 index 9c60d79b..00000000 --- a/wiki/concepts/RRF-Reranking.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: "RRF（Reranking）" -type: concept -tags: [] -sources: [https://github.com/zilliztech/memsearch] -last_updated: 2026-04-17 ---- - -## Definition -RRF（Reciprocal Rank Fusion，倒数排名融合）是一种将多路搜索结果合并排序的算法。 - -## Principle -对不同搜索方法的结果按排名倒数（1/(k+rank)）加权求和，得到综合排名。 - -## Use Case -- 合并语义搜索（向量嵌入）和关键词搜索（BM25）的结果，提升搜索质量 - -## Aliases -- RRF -- Reciprocal Rank Fusion \ No newline at end of file diff --git a/wiki/concepts/RSS.md b/wiki/concepts/RSS.md deleted file mode 100644 index 1dba8baa..00000000 --- a/wiki/concepts/RSS.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: "RSS" -type: concept -tags: [信息聚合, 订阅, 协议] -date: 2026-04-18 ---- - -## Definition -RSS（Really Simple Syndication）是一种信息聚合格式，允许用户订阅网站更新而无需重复访问网站。 - -## Usage -- 聚合多个信息源到单一阅读器 -- 实现内容订阅和推送 -- 用于构建自动化信息管道 - -## RSS Feed URL Format -- YouTube 频道：https://www.youtube.com/feeds/videos.xml?channel_id=CHANNEL_ID -- 通用格式：https://example.com/feed.xml - -## Related -- [[YouTube]]: 移除了网页端 RSS 订阅按钮 -- [[multi-source-tech-news-digest]]: 使用 RSS 作为数据源 \ No newline at end of file diff --git a/wiki/concepts/RTO.md b/wiki/concepts/RTO.md deleted file mode 100644 index b864b080..00000000 --- a/wiki/concepts/RTO.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: "RTO (Recovery Time Objective)" -type: concept -tags: [灾难恢复, 业务连续性, 指标] -sources: ["https://launchdarkly.com/blog/rto-vs-rpo/"] -last_updated: 2025-07-26 ---- - -## Definition -RTO（Recovery Time Objective，恢复时间目标）是指系统允许的最大停机时间。是从系统下线到恢复上线的最大可接受时间窗口。 - -## Key Characteristics -- 衡量恢复速度，而非数据丢失 -- 时钟从系统下线时刻开始计时 -- 与业务影响直接相关 -- 需要与 RPO 共同规划，不能只优化其中一个 - -## Tiered RTO Targets (from this source) -| Tier | Examples | RTO Target | -|------|----------|------------| -| Critical | Payment processing, user auth | < 5 minutes | -| Important | Admin dashboards, reporting | < 1 hour | -| Nice-to-have | Internal tools, dev environments | < 4 hours | - -## RDS vs Aurora RTO Comparison -| Database | RTO (AZ Failure) | -|----------|-----------------| -| Aurora | 30 秒 | -| RDS PostgreSQL | 2 分钟 | - -## Connections -- [[RPO (Recovery Point Objective)]] ← 配对指标 → [[RTO (Recovery Time Objective)]] -- [[灾难恢复]] ← 应用领域 → [[RTO (Recovery Time Objective)]] -- [[持续交付]] ← 现代上下文 → [[RTO (Recovery Time Objective)]] -- [[Feature Flag]] ← 降低工具 → [[RTO (Recovery Time Objective)]] diff --git a/wiki/concepts/Randomization.md b/wiki/concepts/Randomization.md deleted file mode 100644 index 554da9c6..00000000 --- a/wiki/concepts/Randomization.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "Randomization" -type: concept -tags: [statistics, experimentation] -sources: [project-management-experiment-tracker] -last_updated: 2026-04-20 ---- - -## Definition -Randomization is the assignment of units to experimental variants by chance to reduce bias and support causal inference. - -## Core Principles -- Randomly assign at the correct unit level -- Keep assignment stable during the experiment -- Avoid contamination between variants -- Validate balance across key segments - -## Related Concepts -- [[A/B Testing]] -- [[Hypothesis Testing]] - -## Related Entities -- [[Experiment Tracker]] - diff --git a/wiki/concepts/Rate-Optimization.md b/wiki/concepts/Rate-Optimization.md deleted file mode 100644 index 343eccc6..00000000 --- a/wiki/concepts/Rate-Optimization.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: "Rate Optimization" -type: concept -tags: [cloud, cost-management, AWS] -sources: [public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco] -last_updated: 2026-04-19 ---- - -## Summary -Rate Optimization（费率优化）是通过承诺使用获取折扣的云成本优化策略。 - -## Definition -费率优化基于承诺使用期限（1-3年）获取折扣，分为资源级承诺（更高折扣但有限制）和灵活承诺（标准折扣但更灵活）。 - -## AWS 费率优化工具 -- **Savings Plans**：EC2 Savings Plans、Compute Savings Plans -- **Reserved Instances**：RDS、ElastiCache、CloudFront 等服务预留 -- **Spot Instances**：最高可达 90% 折扣，适用于容错工作负载 - -## 费率优化工作流 -1. **预工作（Right Sizing）**：先完成资源配置优化 -2. **分析**：识别需要 24/7 运行的工作负载 -3. **沟通**：与财务团队分享详情 -4. **审批**：获取账户所有者批准 -5. **报告**：监控利用率 - -## 关键约束 -- 仅 FinOps 团队可以实施承诺计划 -- 所有承诺计划仅支持无预付款选项 -- 最低交易价值：每年 5,000 美元 - -## Connections -- [[FinOps]] ← enables ← [[Rate Optimization]]：FinOps 推动费率优化 -- [[Cost Optimization]] ← implements ← [[Rate Optimization]]：费率优化是成本优化的一部分 -- [[Workload Optimization]] ← combines_with ← [[Rate Optimization]]：与工作负载优化配合实现最大节省 -- [[Savings Plans]] ← is_type_of ← [[Rate Optimization]] -- [[Reserved Instances]] ← is_type_of ← [[Rate Optimization]] -- [[Spot Instances]] ← is_type_of ← [[Rate Optimization]] \ No newline at end of file diff --git a/wiki/concepts/Read-Only-Root-Filesystem.md b/wiki/concepts/Read-Only-Root-Filesystem.md deleted file mode 100644 index eb264999..00000000 --- a/wiki/concepts/Read-Only-Root-Filesystem.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: "Read Only Root Filesystem" -type: concept -tags: [Container, Security, Kubernetes] -last_updated: 2026-04-19 ---- - -## 定义 -只读根文件系统（Read-Only Root Filesystem）是一种容器安全配置，将容器的根文件系统设置为只读状态，防止未授权的文件创建和修改。 - -## 实现方式 -在 Kubernetes 中通过设置 `readOnlyRootFilesystem: true` 实现。 - -## 安全价值 -- 防止恶意攻击者写入恶意文件 -- 保护系统目录不被篡改 -- 限制容器内恶意软件的活动范围 -- 符合不可变基础设施最佳实践 - -## 相关资源 -- 来源：[[CTP Topic 49 Container Lifecycle Hardening Standards]] -- 相关概念：[[Container-Lifecycle-Hardening]] \ No newline at end of file diff --git a/wiki/concepts/Reality.md b/wiki/concepts/Reality.md deleted file mode 100644 index 536e3906..00000000 --- a/wiki/concepts/Reality.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -id: reality -title: Reality -type: concept -tags: [protocol, proxy, security] -sources: [] -last_updated: 2026-04-16 ---- - -## Summary -- 定义：无 TLS 特征的 TLS 伪装协议，由 V2Ray/Xray 开发 -- 作用：通过_REAL 协议头实现 TLS 指纹混淆，绕过 TLS 检测 - -## Key Facts -- 模拟真实 TLS 流量特征 -- 不需要真实的 TLS 证书 -- 可与 VLESS、VMESS 等协议组合使用 -- 提供更强的抗检测能力 diff --git a/wiki/concepts/Recovery-Assurance.md b/wiki/concepts/Recovery-Assurance.md deleted file mode 100644 index 40015602..00000000 --- a/wiki/concepts/Recovery-Assurance.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: "Recovery Assurance" -type: concept -tags: [dr, reliability, sre] ---- - -## Definition -恢复保障（Recovery Assurance）是一种从设计层面确保系统具备恢复能力的架构理念，与传统的灾难恢复（DR）不同，它强调主动式而非被动式响应。 - -## Key Differences from DR -- **DR（灾难恢复）**：被动响应，事件发生后尝试恢复 -- **Recovery Assurance**：主动设计，在设计阶段就考虑恢复能力 - -## Core Principles -1. **Design for Failure**：假设组件会故障，设计容错机制 -2. **Observability**：持续监控系统健康状态 -3. **Automation**：自动检测和恢复能力 -4. **Test-Driven**：通过测试验证恢复能力 - -## Related Metrics -- [[RTO]]（Recovery Time Objective）：恢复时间目标 -- [[RPO]]（Recovery Point Objective）：恢复点目标 - -## Related Concepts -- [[Self-Healing Systems]]：自愈系统 -- [[SRE]]：站点可靠性工程 -- [[Observability Engineering]]：可观测性工程 -- [[Chaos Engineering]]：混沌工程 \ No newline at end of file diff --git a/wiki/concepts/Recruitment-Operations.md b/wiki/concepts/Recruitment-Operations.md deleted file mode 100644 index 2799ec57..00000000 --- a/wiki/concepts/Recruitment-Operations.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: "Recruitment Operations" -type: concept -tags: [hr, recruiting, operations] -sources: [recruitment-specialist] -last_updated: 2026-04-20 ---- - -## Definition -Recruitment Operations 指围绕招聘目标进行的多渠道投放、流程设计、漏斗优化、预算分配与效果复盘。 - -## Core Principles -- 按岗位类型匹配渠道 -- 用数据衡量 ROI 与转化率 -- 通过漏斗找出瓶颈并迭代 -- 将重复流程标准化与自动化 - -## Related Entities -- [[Recruitment Specialist]] -- [[The Agency]] -- [[Boss Zhipin]] -- [[Liepin]] -- [[Maimai]] diff --git a/wiki/concepts/Recursive-Self-Optimizing-Generative-Systems.md b/wiki/concepts/Recursive-Self-Optimizing-Generative-Systems.md deleted file mode 100644 index 797e4ba4..00000000 --- a/wiki/concepts/Recursive-Self-Optimizing-Generative-Systems.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -title: "Recursive Self-Optimizing Generative Systems" -type: concept -tags: [] ---- - -## Definition -递归自优化生成系统（Recursive Self-Optimizing Generative Systems）是一种目标不是直接产生最优输出，而是通过迭代自修改构建稳定生成能力的系统。系统生成工件，根据理想目标优化它们，并使用优化后的工件更新自身的生成机制。 - -## Core Components -- **意图空间 (I)**：系统接收的输入意图集合 -- **提示空间 (P)**：生成的提示、程序或技能的空间 -- **生成器空间 (G)**：G ⊆ P^I，每个生成器 G: I → P -- **理想目标 (Ω)**：抽象的评估标准或理想目标 - -## System Dynamics -1. **生成**：P = G(I) -2. **优化**：P* = O(P, Ω) -3. **更新**：G' = M(G, P*) - -## Formalization -系统诱导生成器空间上的自映射： -``` -Φ: G → G -Φ(G) = M(G, O(G(I), Ω)) -``` - -迭代产生序列 {G_n}，其中 G_{n+1} = Φ(G_n)。 - -## Stable State -稳定生成能力定义为 Φ 的不动点 G*： -``` -G* ∈ G, Φ(G*) = G* -``` - -当 Φ 满足连续性或收缩性条件时： -``` -G* = lim(n→∞) Φ^n(G_0) -``` - -## Lambda Calculus Expression -使用 Y 不动点组合子表达自引用： -``` -STEP ≡ λG. (M G) ((O (G I)) Ω) -G* ≡ Y STEP -``` - -## Related Concepts -- [[Generator Space]] -- [[Optimization Operator]] -- [[Meta-Generative Operator]] -- [[Self-Map]] -- [[Fixed Point]] -- [[Y Combinator]] -- [[Vibe Coding]] -- [[Self-Improving]] \ No newline at end of file diff --git a/wiki/concepts/Reentrancy.md b/wiki/concepts/Reentrancy.md deleted file mode 100644 index 611d4dca..00000000 --- a/wiki/concepts/Reentrancy.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "Reentrancy" -type: concept -tags: [smart-contract, vulnerability, security] -sources: [blockchain-security-auditor] -last_updated: 2026-04-20 ---- - -## Definition -重入攻击（Reentrancy）是一种智能合约安全漏洞，攻击者通过在外部调用期间重新进入同一合约来操纵状态，导致同一笔资金被多次提取。 - -## Vulnerability Pattern -```solidity -// VULNERABLE: External call BEFORE state update -function withdraw() external { - uint256 amount = balances[msg.sender]; - (bool success,) = msg.sender.call{value: amount}(""); - balances[msg.sender] = 0; // State updated AFTER external call -} -``` - -## Attack Mechanism -1. 攻击者部署恶意合约 -2. 将资金存入目标合约 -3. 调用 withdraw() -4. 目标合约执行外部调用（发送 ETH） -5. 恶意合约的 receive() 在状态更新前被触发 -6. 重新调用 withdraw() -7. 由于状态未更新，攻击者可再次提取资金 - -## Mitigation -- **Checks-Effects-Interactions**：先更新状态，再执行外部调用 -- **ReentrancyGuard**：OpenZeppelin 提供的重入锁修饰符 -- **Pull Payment**：使用 PullPayment 模式替代直接发送 - -## Connections -- [[Smart Contract Vulnerability]] ← is_type_of ← [[Reentrancy]] -- [[Checks-Effects-Interactions]] ← prevents ← [[Reentrancy]] -- [[ReentrancyGuard]] ← prevents ← [[Reentrancy]] - diff --git a/wiki/concepts/Reference-Architecture.md b/wiki/concepts/Reference-Architecture.md deleted file mode 100644 index f5e0e56f..00000000 --- a/wiki/concepts/Reference-Architecture.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "Reference Architecture" -type: concept -tags: - - aws - - landing-zone - - infrastructure -sources: [ctp-topic-1-gruntwork-landing-zone-architecture] -last_updated: 2026-04-18 ---- - -## Summary -包含核心账户和工作负载账户的最佳实践起点，是云平台部署的参考标准。 - -## Definition -Reference Architecture（参考架构）是一套经过实战验证的最佳实践集合，作为云平台部署的起点，包含预定义的账户结构和基础设施组件。 - -## Key Components -- **核心账户**：Shared（共享）、Logs（日志）、Security（安全） -- **工作负载账户**：Prod（生产）、Stage（预发）、Dev（开发） - -## Connections -- [[Gruntwork-Landing-Zone]] ← implements ← [[Reference-Architecture]] -- [[AWS-Organizations]] ← manages ← [[Reference-Architecture]] -- [[Multi-Account-Strategy]] ← relies_on ← [[Reference-Architecture]] \ No newline at end of file diff --git a/wiki/concepts/Remote-SSH.md b/wiki/concepts/Remote-SSH.md deleted file mode 100644 index ff193add..00000000 --- a/wiki/concepts/Remote-SSH.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "Remote-SSH" -type: concept -tags: [remote-development, vscode-plugin] ---- - -## 定义 -Remote-SSH 是 VS Code/Trae 的远程开发插件，允许开发者通过 SSH 协议连接到远程服务器，在远程主机上直接进行开发、调试和运行代码。 - -## 工作原理 -1. 本地运行 Trae/VS Code 客户端 -2. 通过 SSH 连接到远程服务器 -3. 在远程服务器上安装 VS Code Server（Trae Server） -4. 所有代码操作在远程服务器执行，本地仅显示 UI - -## 核心功能 -- 远程文件夹浏览和编辑 -- 远程终端访问 -- 远程调试功能 -- 插件安装在远程服务器 - -## 应用场景 -- 服务器端开发 -- 跨平台开发（本地 Windows，远程 Linux） -- 容器内开发（通过 Remote-Containers） -- 高性能开发（利用远程服务器算力） - -## 优点 -- 无需在本地配置复杂开发环境 -- 利用远程服务器资源进行编译和测试 -- 代码始终保存在远程服务器，安全性高 - -## 关联工具 -- [[Trae]]：支持 Remote-SSH 的 AI 增强编辑器 -- [[Docker]]：远程服务器上的容器化环境 -- [[SSH]]：远程连接协议 - -## 连接关系 -- [[Remote-SSH]] ← connects_to ← [[SSH]] -- [[Remote-SSH]] ← runs_on ← [[Ubuntu]] \ No newline at end of file diff --git a/wiki/concepts/Renovate-Bot.md b/wiki/concepts/Renovate-Bot.md deleted file mode 100644 index a03d966b..00000000 --- a/wiki/concepts/Renovate-Bot.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "Renovate Bot" -type: concept -tags: [DevOps, CI/CD, Dependency-Update] -date: 2026-04-14 ---- - -## Definition -开源依赖自动化更新工具，通过扫描代码并自动提交 Pull Request 来保持依赖项处于最新状态。适用于 Docker 镜像、Maven 依赖、Terraform 模块、Kubernetes Helm Charts 等多种依赖类型。 - -## Aliases -- Renovate -- Renovate Bot - -## Key Features -- Dependency Dashboard：在一个 GitHub Issue 中列出所有待更新的项，提供全局视角 -- Managers：支持多种技术栈的插件机制（terraform、dockerfile、maven 等） -- Rate Limiting：限制每小时或同时开启的 PR 数量 -- 自动语义版本判断：基于 Semantic Versioning 规则判断更新级别 - -## Connections -- [[Dependency Management]]：自动化管理目标 -- [[GitOps]]：依赖更新是 GitOps 流程的一部分 -- [[Terraform]]：可管理 Terraform 模块依赖 -- [[Terragrunt]]：可管理 Terragrunt 配置依赖 \ No newline at end of file diff --git a/wiki/concepts/Resource-Allocation.md b/wiki/concepts/Resource-Allocation.md deleted file mode 100644 index 4c434485..00000000 --- a/wiki/concepts/Resource-Allocation.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: "Resource Allocation" -type: concept -tags: [operations, project-management] -sources: [project-management-studio-operations, project-management-studio-producer] -last_updated: 2026-04-20 ---- - -## Definition -Resource Allocation is the practice of distributing people, tools, time, and budget across priorities so work can be completed efficiently and with appropriate service quality. - -## Core Principles -- Match resources to the highest-value work -- Balance short-term delivery with long-term capacity -- Track utilization and constraints -- Reallocate proactively when bottlenecks emerge - -## Related Entities -- [[Studio Operations]] -- [[Studio Producer]] -- [[Project Shepherd]] diff --git a/wiki/concepts/Responsive-Search-Ads-RSA.md b/wiki/concepts/Responsive-Search-Ads-RSA.md deleted file mode 100644 index edf29f45..00000000 --- a/wiki/concepts/Responsive-Search-Ads-RSA.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: "Responsive Search Ads (RSA)" -type: concept -tags: [Google Ads, PPC, Advertising] ---- - -## 定义 -响应式搜索广告（Responsive Search Ads，RSA）是 Google Ads 的一种高级搜索广告格式，允许广告主输入最多 15 个标题和 4 个描述，Google 算法会自动测试不同组合以找到最佳表现组合。 - -## 关键特征 -- 最多 15 个标题字段 -- 最多 4 个描述字段 -- 算法自动组合测试 -- 机器学习优化展示 - -## 架构策略 -- 品牌类标题 -- 利益类标题 -- 功能类标题 -- CTA 类标题 -- 社会证明类标题 - -## 优化要点 -- 确保每个标题可以与任何其他标题组合 -- 包含关键词 -- 差异化信息传递 -- 明确行动号召 - -## 相关概念 -- [[Ad Strength]] -- [[Paid Media Ad Creative Strategist]] diff --git a/wiki/concepts/Reviewer.md b/wiki/concepts/Reviewer.md deleted file mode 100644 index e832bdbd..00000000 --- a/wiki/concepts/Reviewer.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -id: reviewer -title: "Reviewer" -type: concept -tags: [Agent, Skill, 设计模式] -sources: [Google-5-Agent-Skill-design-patterns-2026-03-19] -last_updated: 2026-04-17 ---- - -## Summary -把检查清单和检查逻辑分开的 Agent Skill 设计模式，实现不同专项审计。 - -## Definition -Reviewer 模式把"检查什么"和"怎么检查"完全分开，审查标准存放在 references 目录，指令保持静态但动态加载特定审查标准。 - -## Components -- **SKILL.md**：保持静态的指令 -- **references/review-checklist.md**：可替换的审查标准（Python 风格检查、OWASP 安全检查等） - -## Workflow -1. 加载静态指令 -2. 动态加载审查标准 -3. 按严重程度分组输出结构化结果 - -## Advantages -- 审查标准可替换：同一 skill 基础设施，换个清单就是完全不同的专项审计 -- 避免 system prompt 膨胀：规则外置，按需加载 - -## Related Concepts -- [[Agent-Skill-设计模式]] -- [[Pipeline]]：可在最后包含 Reviewer 步骤来 double-check \ No newline at end of file diff --git a/wiki/concepts/Right-Sizing.md b/wiki/concepts/Right-Sizing.md deleted file mode 100644 index cdcbd703..00000000 --- a/wiki/concepts/Right-Sizing.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: "Right Sizing" -type: concept -tags: [cloud, cost-management, AWS, EC2] -sources: [public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco] -last_updated: 2026-04-19 ---- - -## Summary -Right Sizing（正确调整规格）是识别正确的资源规格以匹配工作负载性能和容量需求的过程。 - -## Definition -通过分析实际 CPU、内存、网络使用数据，推荐合适的实例规格，避免资源浪费。 - -## Key Techniques -- **EC2 Right Sizing Recommendation**：捕获 CPU、内存、网络数据提供推荐 -- **实例调度**：为非生产环境配置按业务时间开关机，可节省 60% 成本 -- **闲置资源清理**：识别和删除空闲负载均衡器、未关联弹性 IP、低利用率 EBS 卷 - -## Connections -- [[Cost Optimization]] ← implements ← [[Right Sizing]]：Right Sizing 是成本优化的核心实践 -- [[Workload Optimization]] ← includes ← [[Right Sizing]]：Right Sizing 属于工作负载优化范畴 -- [[Spot Instances]] ← complements ← [[Right Sizing]]：Right Sizing 与 Spot 实例配合使用效果最佳 \ No newline at end of file diff --git a/wiki/concepts/Risk-Management.md b/wiki/concepts/Risk-Management.md deleted file mode 100644 index ab0aca2a..00000000 --- a/wiki/concepts/Risk-Management.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "Risk Management" -type: concept -tags: [security, devops] -sources: [what-is-devsecops-best-practices-benefits-and-tools] -last_updated: 2026-04-20 ---- - -## Definition -风险管理是识别、评估和缓解安全威胁的过程。在 DevSecOps 中，风险管理是优先事项，通过识别威胁和漏洞，组织可以实施控制措施来降低安全事件的风险并减少数据泄露的影响。 - -## Core Practices -- **风险识别**：识别系统和应用中的潜在威胁 -- **风险评估**：评估威胁的可能性和影响 -- **风险缓解**：实施控制措施降低风险 -- **持续监控**：持续监控风险状态 - -## DevSecOps Integration -- 在 SDLC 早期进行风险评估 -- 将风险评估集成到 CI/CD 流水线 -- 自动化风险扫描和报告 -- 定期更新风险矩阵 - -## Connections -- [[DevSecOps]] ← requires ← [[Risk Management]] -- [[Compliance-Enforcement]] ← depends_on ← [[Risk Management]] -- [[Policy-as-Code]] ← enforces ← [[Risk Management]] \ No newline at end of file diff --git a/wiki/concepts/Roadmap-Now-Next-Later.md b/wiki/concepts/Roadmap-Now-Next-Later.md deleted file mode 100644 index 0648abc1..00000000 --- a/wiki/concepts/Roadmap-Now-Next-Later.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: "Roadmap (Now / Next / Later)" -type: concept -tags: [product-management, planning, roadmap] -sources: [product-manager.md] -last_updated: 2026-04-20 ---- - -## Definition -产品路线图是按时间维度（当前季度/下个 1-2 季度/3-6 个月）组织的产品组合视图，通过 Now/Next/Later 三层结构管理产品赌注。 - -## Three Horizons -| Horizon | Timeframe | Commitment | Confidence | -|---------|-----------|------------|------------| -| Now | 当前季度 | 完全对齐，工程、设计、PM 已达成一致 | 高 | -| Next | 下个 1-2 季度 | 方向承诺，需要 scoping 后才能开发 | 中 | -| Later | 3-6 个月 | 战略赌注，未排期，有信号才推进 | 低 | - -## Now Section -包含：initiative、user problem、success metric、owner、status、ETA - -## Next Section -包含：initiative、hypothesis、expected outcome、confidence、blocker - -## Later Section -包含：initiative、strategic hypothesis、signal needed to advance - -## Explicit Not-Building List -公开说明不构建什么及原因，防止重复请求并建立信任。 - -## North Star Metric -路线图必须定义北极星指标——最好地捕捉用户是否获得价值和业务是否健康的单一指标。 - -## Connection -- [[Product Manager Agent]] ← owns ← [[Roadmap (Now / Next / Later)]] -- [[Opportunity Assessment]] ← informs ← [[Roadmap (Now / Next / Later)]] -- [[RICE Prioritization Score]] ← ranks ← [[Roadmap (Now / Next / Later)]] diff --git a/wiki/concepts/Rollback-Mechanism.md b/wiki/concepts/Rollback-Mechanism.md deleted file mode 100644 index fb47e50c..00000000 --- a/wiki/concepts/Rollback-Mechanism.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "Rollback Mechanism" -type: concept -tags: [rollback, memory, qa, recovery] -last_updated: 2026-04-21 ---- - -## Definition -Rollback Mechanism 是指 agent 将工作状态回退到最后检查点以修复问题的机制。在 QA 失败场景下，无需人工描述问题，agent 直接调用 rollback 恢复已知良好状态，然后针对具体问题修复。 - -## Mechanism -1. Agent 调用 `rollback` MCP 工具 -2. 指定回退到的检查点（时间戳或版本） -3. 系统恢复至该检查点的状态 -4. Agent 在恢复状态下针对具体问题进行修复 - -## Use Case -QA 失败时 Reality Checker 指出 API 设计问题，Backend Architect： -1. 召回 Reality Checker 的反馈 -2. 召回自己的上一个 API spec -3. Rollback 至该版本 -4. 针对具体问题修复并重新存储 - -## Connections -- [[MCP Memory Server]]：支撑 rollback 操作的服务器 -- [[Reality Checker]]：触发 rollback 的审查方 -- [[Memory Tagging]]：checkpoint 的标记方式 diff --git a/wiki/concepts/Round-Robin-策略.md b/wiki/concepts/Round-Robin-策略.md deleted file mode 100644 index 9d97cc1c..00000000 --- a/wiki/concepts/Round-Robin-策略.md +++ /dev/null @@ -1,16 +0,0 @@ ---- -title: "Round Robin 策略" -type: concept -tags: [AI Agent, Task Scheduling] ---- - -## Definition -任务调度算法，轮转分配任务以平衡不同类型/年龄段内容的工作流策略。 - -## Related To -- [[autonomous-game-dev-pipeline]] — 使用此策略的源案例 -- [[Game Developer Agent]] — 使用此策略的 Agent - -## Aliases -- 轮转调度 -- 轮询策略 \ No newline at end of file diff --git a/wiki/concepts/Route-53-Private-Hosted-Zone.md b/wiki/concepts/Route-53-Private-Hosted-Zone.md deleted file mode 100644 index 9b5052ed..00000000 --- a/wiki/concepts/Route-53-Private-Hosted-Zone.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "Route 53 Private Hosted Zone" -type: concept -tags: - - AWS - - DNS - - Networking ---- - -## Definition -Route 53 Private Hosted Zone 是 AWS 提供的私有托管区域，仅对指定的 VPC 可见，用于管理内部网络域名。 - -## Characteristics -- **私有性**：仅在指定的 VPC 内解析，不暴露到公网 -- **VPC 关联**：一个 Private Hosted Zone 可以关联到多个 VPC -- **解析机制**：在关联的 VPC 内自动解析记录的域名 - -## Use Cases -- 管理内部服务域名（如 `internal.example.com`） -- 配合 Private Resolver 实现混合云 DNS 解析 -- Landing Zone 基础架构的核心组件 - -## Connections -- [[Route-53]] ← manages ← [[Route-53-Private-Hosted-Zone]] -- [[Route-53-Resolver-Endpoint]] ← integrates_with ← [[Route-53-Private-Hosted-Zone]] \ No newline at end of file diff --git a/wiki/concepts/Route-53-Resolver-Endpoint.md b/wiki/concepts/Route-53-Resolver-Endpoint.md deleted file mode 100644 index a4dd8a90..00000000 --- a/wiki/concepts/Route-53-Resolver-Endpoint.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: "Route 53 Resolver Endpoint" -type: concept -tags: - - AWS - - DNS - - Networking ---- - -## Definition -Route 53 Resolver Endpoint 包括入站（Inbound）和出站（Outbound）终端节点，用于在 AWS VPC 与本地网络或其他云环境之间转发 DNS 查询。 - -## Types - -### Inbound Endpoint -- 允许本地网络向 Route 53 Resolver 发送 DNS 查询 -- 用于本地环境解析 AWS 内部域名 - -### Outbound Endpoint -- 允许 VPC 内的资源向本地 DNS 服务器发送查询 -- 通过出站规则配置转发条件，将特定域名的查询转发到指定的 DNS 服务器（如 AD 域控制器） - -## Use Cases -- 混合云 DNS 解析 -- 跨区域 DNS 故障转移 -- 就近解析全球化服务（如 Office 365） - -## Configuration Example -- 在出站规则中配置多个区域的 AD 域控制器 IP -- 确保即使某个区域发生故障，DNS 解析仍保持弹性 - -## Connections -- [[Route-53]] ← provides ← [[Route-53-Resolver-Endpoint]] -- [[Route-53-Resolver-Endpoint]] ← forwards_to ← [[Active-Directory]] \ No newline at end of file diff --git a/wiki/concepts/S3-Intelligent-Tiering.md b/wiki/concepts/S3-Intelligent-Tiering.md deleted file mode 100644 index d2773f08..00000000 --- a/wiki/concepts/S3-Intelligent-Tiering.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: "S3 Intelligent Tiering" -type: concept -tags: [AWS, S3, Storage, Cost-Optimization] -sources: [] -last_updated: 2026-04-19 ---- - -## Definition -S3 Intelligent Tiering（S3 智能分层）是 AWS S3 的一种存储类，可自动根据对象访问模式在不同的存储层之间移动数据，无需用户干预即可实现成本优化。 - -## Key Features -- **自动监控**：自动监控访问模式，识别不频繁访问的数据 -- **无转换费用**：在不同存储层之间移动时无需支付转换费用 -- **两层监控**：30 天无访问移至 Infrequent Access，90 天移至 Archive 或 Deep Archive -- **支持所有对象大小**：适合任何大小的对象 -- **无检索费用**：从任何层检索数据无需支付费用 - -## Pricing Model -- 存储费用根据层级不同： - - Frequent Access：标准 S3 费率 - - Infrequent Access：比标准层低约 40% - - Archive Instant Access：比标准层低约 70% - - Deep Archive：比标准层低约 95% -- 监控费用：每 1,000 对象 $0.015/month - -## Use Cases -- 日志文件归档（访问后 30 天内不访问） -- 数据湖中的冷数据 -- 合规性保留数据 -- 备份文件的长期存储 - -## Connections -- [[Lifecycle-Policy]] → implements → [[S3-Intelligent-Tiering]] -- [[S3-Standard]] ← compared_to ← [[S3-Intelligent-Tiering]] -- [[Glacier]] ← compared_to ← [[S3-Intelligent-Tiering]] \ No newline at end of file diff --git a/wiki/concepts/SAM.md b/wiki/concepts/SAM.md deleted file mode 100644 index d260a88b..00000000 --- a/wiki/concepts/SAM.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: "SAM 模型" -type: concept -tags: [instructional-design, rapid-iteration] -sources: [] -last_updated: 2026-04-20 ---- - -## Definition -Successive Approximation Model（持续逼近模型），一种快速迭代的课程设计方法，适用于需要缩短上线时间的场景。 - -## Process -原型→评审→修订循环，直到达到目标质量。 - -## Use Cases -- 时间紧迫的培训项目 -- 需要快速验证的试运行课程 - -## Related Concepts -- [[ADDIE 模型]]：完整系统化版本 diff --git a/wiki/concepts/SAML.md b/wiki/concepts/SAML.md deleted file mode 100644 index c5f90b71..00000000 --- a/wiki/concepts/SAML.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: "SAML" -type: concept -tags: [] ---- - -## Definition -Security Assertion Markup Language，安全断言标记语言。基于 XML 的标准，用于在身份提供商和服务提供商之间交换身份验证和授权数据。 - -## Use Cases -- 单点登录（SSO） -- 多因素认证（MFA）集成 -- 跨域身份验证 - -## Related Entities -- [[AppStream-2.0]] -- [[AWS-Workspaces]] - -## Related Concepts -- [[BYOD]] \ No newline at end of file diff --git a/wiki/concepts/SAST.md b/wiki/concepts/SAST.md deleted file mode 100644 index 40c29cbd..00000000 --- a/wiki/concepts/SAST.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: "SAST（静态应用安全测试）" -type: concept -tags: [安全, 测试, 代码分析] -sources: [what-is-devsecops-best-practices-benefits-and-tools] -last_updated: 2026-04-16 ---- - -## Definition -SAST（Static Application Security Testing）是一种静态代码分析技术，在不运行应用程序的情况下分析源代码以识别安全漏洞。 - -## Characteristics -- 在开发早期（编码阶段）使用 -- 无需执行代码 -- 可检测 SQL 注入、跨站脚本、缓冲区溢出等常见漏洞 -- 集成到 IDE 和 CI/CD 流水线 - -## Tools -- SonarQube -- Checkmarx -- Fortify - -## Connections -- [[DevSecOps]] ← uses ← [[SAST]] -- [[CI-CD-流水线]] ← integrates ← [[SAST]] -- [[SDLC]] ← embeds ← [[SAST]] \ No newline at end of file diff --git a/wiki/concepts/SCA.md b/wiki/concepts/SCA.md deleted file mode 100644 index 4def6235..00000000 --- a/wiki/concepts/SCA.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: "SCA（软件成分分析）" -type: concept -tags: [安全, 依赖, 开源] -sources: [what-is-devsecops-best-practices-benefits-and-tools] -last_updated: 2026-04-16 ---- - -## Definition -SCA（Software Composition Analysis）专注于分析应用程序使用的第三方组件（库和框架），识别已知安全漏洞和许可证合规问题。 - -## Characteristics -- 在开发早期（计划/设计阶段）使用 -- 检测开源依赖中的已知漏洞 -- 验证许可证合规性 -- 常用工具：Snyk、OWASP Dependency Check - -## Connections -- [[DevSecOps]] ← uses ← [[SCA]] -- [[CI-CD-流水线]] ← integrates ← [[SCA]] -- [[SDLC]] ← embeds ← [[SCA]] \ No newline at end of file diff --git a/wiki/concepts/SCRM.md b/wiki/concepts/SCRM.md deleted file mode 100644 index f3a2735c..00000000 --- a/wiki/concepts/SCRM.md +++ /dev/null @@ -1,52 +0,0 @@ ---- -title: "SCRM" -type: concept -tags: [CRM, 客户关系管理, 私域运营, 微信生态] -sources: [[raw/Agent/agency-agents/marketing/marketing-private-domain-operator.md]] -date: 2026-04-21 ---- - -## Definition -Social CRM（社交客户关系管理），传统 CRM 的社交化升级版，核心是通过社交平台（微信、企业微信等）实现客户的直接连接、标签化管理、自动化触达和生命周期价值最大化。 - -## Core Components - -### Channel QR Code Configuration -- 渠道活码：自动分配员工、发送欢迎消息、自动打标签 -- 员工池管理：按区域/业务线分组，支持轮询分配 -- 渠道追踪：追踪每个获客渠道的转化效果 - -### Tag System -多维度标签体系： -- **客户来源**：包裹卡、直播、门店、SMS、推荐等 -- **消费层级**：高客单(>500)、中客单(200-500)、低客单(<200) -- **生命周期阶段**：新客、活跃、休眠、流失预警、已流失 -- **兴趣偏好**：美妆、护肤、母婴、健康等 - -自动打标规则： -- 完成首购 → 添加「新客」标签 -- 30 天无互动 → 添加「休眠客户」标签 -- 累计消费 > 2000 → 添加「高价值客户」「VIP候选」标签 - -### Customer Group Configuration -- 欢迎福利群：新人专享，200 人上限 -- VIP 会员群：累计消费 > 1000 或 tagged VIP，100 人上限 -- 超级用户群：高互动、高消费核心用户 - -## WeCom Integration -企业微信 SCRM 配置核心要素： -- 渠道码配置（包裹卡、直播、门店等多渠道） -- 标签系统设计（来源、层级、生命周期、兴趣） -- 自动化工作流（欢迎消息、催付、复购提醒、休眠唤醒） -- 社群 SOP（每日内容安排、每周活动、关键触点自动化） - -## Related Concepts -- [[私域运营]] -- [[用户生命周期管理]] -- [[社群分层运营]] -- [[用户LTV]] -- [[SOP自动化]] - -## Related Entities -- [[WeCom-Learning]] -- [[Marketing Private Domain Operator]] \ No newline at end of file diff --git a/wiki/concepts/SD-WAN.md b/wiki/concepts/SD-WAN.md deleted file mode 100644 index 1cce4ffa..00000000 --- a/wiki/concepts/SD-WAN.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "SD-WAN" -type: concept -tags: - - networking - - wan ---- - -## Aliases -- SD-WAN -- Software-Defined Wide Area Network -- 软件定义广域网 - -## Description -软件定义广域网（SD-WAN）是一种通过软件控制层对物理网络进行抽象的技术，实现动态路径选择和负载均衡。在企业云架构中，SD-WAN 通常作为 Overlay Network（叠加网络）部署在 AWS 等公有云上，解决静态路由的局限性。 - -## Use Cases -- 多分支机构网络互联 -- 动态路径选择和流量调度 -- 替代传统 MPLS 专线 -- Silver Peak 等 SD-WAN 方案集成 - -## Related Concepts -- [[Hub-and-Spoke]] -- [[Overlay Network]] -- [[Transit Gateway]] - -## Related Entities -- [[AWS]] - -## Sources -- [[ctp-topic-18-wide-area-networking-in-aws-cloud]] \ No newline at end of file diff --git a/wiki/concepts/SDL-Security-Development-Lifecycle.md b/wiki/concepts/SDL-Security-Development-Lifecycle.md deleted file mode 100644 index 3f61b162..00000000 --- a/wiki/concepts/SDL-Security-Development-Lifecycle.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: "SDL (Security Development Lifecycle)" -type: concept -tags: - - Security - - Development - - SDLC ---- - -## Definition -SDL（Security Development Lifecycle，软件安全开发生命周期）是将安全实践集成到软件开发流程中的系统化方法。 - -## Micro Focus 13 个安全轨道 -Micro Focus 将供应链安全作为 SDL 的第五大支柱，共 13 个安全轨道： -1. 威胁建模 -2. 安全需求 -3. 安全设计 -4. 安全实现 -5. 供应链安全（新增） -6. 安全测试 -7. 代码审计 -8. 渗透测试 -9. 安全部署 -10. 安全运营 -11. 事件响应 -12. 安全培训 -13. 合规与审计 - -## Integration Points -- 需求阶段：安全需求定义 -- 设计阶段：威胁建模、安全架构评审 -- 开发阶段：安全编码规范、SAST -- 测试阶段：SCA、DAST -- 部署阶段：安全配置审计 -- 运营阶段：漏洞管理、事件响应 - -## Related -- [[Supply Chain Security]]：供应链安全作为 SDL 第五大支柱 -- [[SAST]]：静态应用安全测试 -- [[SCA]]：软件成分分析 -- [[DevSecOps]]：开发安全运营一体化 \ No newline at end of file diff --git a/wiki/concepts/SDLC.md b/wiki/concepts/SDLC.md deleted file mode 100644 index 20a0aaa6..00000000 --- a/wiki/concepts/SDLC.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "SDLC（软件开发生命周期）" -type: concept -tags: [软件开发, 流程, 安全] -sources: [what-is-devsecops-best-practices-benefits-and-tools] -last_updated: 2026-04-16 ---- - -## Definition -SDLC（Software Development Life Cycle）是开发高质量软件的系统性、结构化流程，包括需求分析、计划、架构设计、软件开发、测试和部署六个阶段。 - -## Stages -1. **需求分析**：收集和分析业务需求 -2. **计划**：制定项目计划和时间表 -3. **架构设计**：确定系统架构和技术选型 -4. **软件开发**：编写代码和构建功能 -5. **测试**：验证功能和安全性 -6. **部署**：发布到生产环境 - -## DevSecOps Integration -在传统开发中，安全测试在 SDLC 之外进行。DevSecOps 将安全集成到每个阶段，实现： -- 编码阶段：SAST 静态分析 -- 构建阶段：SCA 依赖检查 -- 测试阶段：IAST/DAST 动态测试 -- 部署阶段：安全配置验证 - -## Connections -- [[DevSecOps]] ← integrates_with ← [[SDLC]] -- [[CI-CD-流水线]] ← automates ← [[SDLC]] -- [[敏捷实践]] ← adapts ← [[SDLC]] \ No newline at end of file diff --git a/wiki/concepts/SHAP-Analysis.md b/wiki/concepts/SHAP-Analysis.md deleted file mode 100644 index 0b9b7f09..00000000 --- a/wiki/concepts/SHAP-Analysis.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "SHAP Analysis" -type: concept -tags: [interpretability, explainability, ml-ops] -sources: [specialized-model-qa] -last_updated: 2026-04-20 ---- - -## Definition -SHAP（SHapley Additive exPlanations）是一种基于博弈论的模型可解释性方法，用于分解单个预测中每个特征的贡献。 - -## Outputs -- 全局解释：summary / beeswarm / bar plot -- 局部解释：waterfall / force plot -- 交互分析：SHAP interaction values - -## Use in Model QA -- 解释预测驱动因素 -- 检查特征贡献是否稳定 -- 识别异常依赖或潜在偏差 - -## Related Concepts -- [[Partial Dependence Plots]] -- [[Model Audit]] \ No newline at end of file diff --git a/wiki/concepts/SLA.md b/wiki/concepts/SLA.md deleted file mode 100644 index 90e8dae9..00000000 --- a/wiki/concepts/SLA.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -id: sla -title: "SLA（服务等级协议）" -type: concept -tags: [sre, reliability, contract] -last_updated: 2026-04-19 ---- - -## Definition -SLA（Service Level Agreement，服务等级协议）是客户级别的正式协议，定义了服务提供者对客户的承诺。 - -## Key Characteristics -- **具有法律约束力**：违反可能涉及经济赔偿 -- **比 SLO 更宽松**：SLO 是团队内部目标，SLA 是对客户的承诺 -- **基于 SLO**：SLA 通常基于内部 SLO 制定 - -## Relationship -- [[SLA（服务等级协议）]] ← based_on ← [[SLO（服务等级目标）]] -- [[SLO（服务等级目标）]] ← measures ← [[SLI（服务等级指标）]] - -## Example -- SLO: 99.9% 可用性（内部目标） -- SLA: 99.5% 可用性（对客户承诺，更宽松） - -## References -- [[CTP Topic 41 NFR's and Error Budgets]] — SLI/SLO/SLA 体系详解 -- [[SRE]] — 站点可靠性工程实践 \ No newline at end of file diff --git a/wiki/concepts/SLI.md b/wiki/concepts/SLI.md deleted file mode 100644 index 653a23d8..00000000 --- a/wiki/concepts/SLI.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -id: sli -title: "SLI（服务等级指标）" -type: concept -tags: [sre, reliability, metrics] -last_updated: 2026-04-19 ---- - -## Definition -SLI（Service Level Indicator，服务等级指标）是可靠性的可量化度量指标，用于衡量系统健康状态。 - -## Common SLIs -- **可用性**：成功请求占总请求的比例 -- **延迟**：请求响应时间（如 P99 延迟） -- **错误率**：失败请求占总请求的比例 -- **吞吐量**：每秒处理的请求数（QPS） - -## Usage -SLI 被 [[SLO（服务等级目标）]] 引用，用于测量服务是否达到预期可靠性水平。 - -## Relationship -- [[SLI（服务等级指标）]] ← measures ← [[SLO（服务等级目标）]] -- [[SLO（服务等级目标）]] ← derives ← [[Error Budget（错误预算）]] -- [[SLA（服务等级协议）]] ← based_on ← [[SLO（服务等级目标）]] - -## References -- [[CTP Topic 41 NFR's and Error Budgets]] — SLI/SLO/SLA 体系详解 -- [[SRE]] — 站点可靠性工程实践 \ No newline at end of file diff --git a/wiki/concepts/SLO.md b/wiki/concepts/SLO.md deleted file mode 100644 index 9788e476..00000000 --- a/wiki/concepts/SLO.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -id: slo -title: "SLO（服务等级目标）" -type: concept -tags: [sre, reliability, metrics] -last_updated: 2026-04-19 ---- - -## Definition -SLO（Service Level Objective，服务等级目标）定义了服务应该达到的性能/可靠性目标，是团队努力实现的具体指标。 - -## Common SLOs -- **可用性目标**：99.9%（三个九）、99.99%（四个九） -- **延迟目标**：P99 响应时间 < 200ms -- **错误目标**：错误率 < 0.1% - -## Relationship with Error Budget -SLO 与 Error Budget 直接关联： -``` -Error Budget = 1 - 可用性 SLO -``` - -例如：99.9% SLO → 0.1% Error Budget - -## Hierarchy -- [[SLI（服务等级指标）]] → measures → SLO -- SLO → derives → [[Error Budget（错误预算）]] -- SLO → satisfies → [[SLA（服务等级协议）]] - -## References -- [[CTP Topic 41 NFR's and Error Budgets]] — SLO 与 Error Budget 关系详解 -- [[SRE]] — 站点可靠性工程实践 \ No newline at end of file diff --git a/wiki/concepts/SMACs.md b/wiki/concepts/SMACs.md deleted file mode 100644 index 5ea0c88c..00000000 --- a/wiki/concepts/SMACs.md +++ /dev/null @@ -1,20 +0,0 @@ -# SMACs - -SMACs（Service Management Access）是一个需求提交的标准化入口，用于启动计时器和确保需求被追踪。 - -## 核心特征 - -- 标准化提交：所有新需求必须通过 SMACs 提交 -- 计时启动：提交后开始计时 -- 追踪保证：确保需求被完整记录 - -## 使用方式 - -- 提交新需求 -- 追踪需求状态 -- 关联评审会议 - -## 替代方案 - -- 邮件或聊天可作为初始联系方式 -- SMACs 是最可靠的追踪方式 \ No newline at end of file diff --git a/wiki/concepts/SMTP.md b/wiki/concepts/SMTP.md deleted file mode 100644 index 1bfd59d8..00000000 --- a/wiki/concepts/SMTP.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: "SMTP" -type: concept -tags: - - email - - protocol - - networking ---- - -## Aliases -- SMTP -- Simple Mail Transfer Protocol -- 简单邮件传输协议 - -## Description -用于发送和转发邮件的标准互联网协议。SMTP 是电子邮件发送的基础协议，大多数邮件服务器都支持 SMTP 接口。 - -## How It Works -1. MUA（邮件用户代理）通过 SMTP 将邮件提交给 MSA（邮件提交代理） -2. MSA 将邮件传递给 MDA（邮件投递代理） -3. MDA 将邮件投递到收件人邮件服务器 -4. 收件人通过 POP3/IMAP 获取邮件 - -## Port Numbers -- 25：标准 SMTP（非加密） -- 465：SMTPS（SMTP over TLS） -- 587：Mail Submission（邮件提交端口） -- 2525：备选端口 - -## AWS SES Integration -- SES 提供 SMTP 端点，支持标准 SMTP 认证 -- IAM 用户凭证转换为 SMTP 用户名和密码 -- 支持通过 VPC 终端节点私有访问 - -## Related Concepts -- [[AWS SES]] -- [[DKIM]] -- [[SPF]] -- [[DMARC]] - -## Sources -- [[ctp-topic-12-using-ses-smtp-service-terraform-module]] \ No newline at end of file diff --git a/wiki/concepts/SOCKS5代理.md b/wiki/concepts/SOCKS5代理.md deleted file mode 100644 index 4bc7568e..00000000 --- a/wiki/concepts/SOCKS5代理.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: SOCKS5代理 -type: concept -tags: [网络代理, 协议, 隐私] ---- - -## Definition -SOCKS5 是一种网络代理协议，属于 SOCKS 协议的第五版。它支持 TCP 和 UDP 连接，提供认证功能，能够在客户端和服务器之间建立传输隧道，隐匿用户的真实 IP 地址和地理位置。 - -## Key Features -- 支持 TCP 和 UDP 协议 -- 支持用户认证 -- 可隐匿真实 IP -- 支持多种应用层协议 -- 比 HTTP 代理更底层，兼容性更好 - -## Use Cases -- 指纹浏览器配合代理配置 -- 网络隐私保护 -- 跨境访问海外服务 -- 账号防封（通过切换 IP） - -## Configuration in Fingerprint Browser -1. 在系统网络设置中配置本机代理 -2. 获取代理的主机地址和端口 -3. 在指纹浏览器中选择 SOCKS5 代理类型 -4. 填入主机和端口，验证连接 - -## Related Entities -- [[AdsPower]] -- [[IP纯净度]] - -## Related Concepts -- [[代理配置]] -- [[HTTP代理]] -- [[VPN]] \ No newline at end of file diff --git a/wiki/concepts/SOP自动化.md b/wiki/concepts/SOP自动化.md deleted file mode 100644 index 19b1bc9f..00000000 --- a/wiki/concepts/SOP自动化.md +++ /dev/null @@ -1,105 +0,0 @@ ---- -title: "SOP自动化" -type: concept -tags: [运营自动化, 工作流, 私域运营, 效率提升] -sources: [[raw/Agent/agency-agents/marketing/marketing-private-domain-operator.md]] -date: 2026-04-21 ---- - -## Definition -SOP 自动化是将标准化作业流程（Standard Operating Procedure）通过系统配置实现自动触发、自动执行、自动记录的运营方法。核心价值是降低人工重复劳动、保证执行一致性、实现规模化运营。 - -## Core Automation Flows - -### 新客激活自动化 -```python -lifecycle_automation = { - "new_customer_activation": { - "trigger": "添加企业微信好友", - "flows": [ - {"delay": "0min", "action": "发送欢迎消息 + 新人礼包"}, - {"delay": "30min", "action": "推送产品使用指南（小程序）"}, - {"delay": "24h", "action": "邀请加入福利群"}, - {"delay": "48h", "action": "发送首购专属优惠券（30元无门槛）"}, - {"delay": "72h", "condition": "无购买", "action": "1v1 私聊需求诊断"}, - {"delay": "7d", "condition": "仍无购买", "action": "发送限时试用样品 offer"}, - ] - } -} -``` - -### 复购提醒自动化 -```python -lifecycle_automation = { - "repurchase_reminder": { - "trigger": "距上次购买 N 天（基于产品消费周期）", - "flows": [ - {"delay": "cycle-7d", "action": "推送产品效果调研"}, - {"delay": "cycle-3d", "action": "发送复购offer（回头客专属价）"}, - {"delay": "cycle", "action": "1v1 补货提醒 + 推荐升级产品"}, - ] - } -} -``` - -### 休眠唤醒自动化 -```python -lifecycle_automation = { - "dormant_reactivation": { - "trigger": "30 天无互动且无购买", - "flows": [ - {"delay": "30d", "action": "定向朋友圈（仅对休眠客户可见）"}, - {"delay": "45d", "action": "发送专属回场优惠券（20元无门槛）"}, - {"delay": "60d", "action": "1v1 关怀消息（非促销，真诚问候）"}, - {"delay": "90d", "condition": "仍无响应", "action": "降级处理，减少触达频率"}, - ] - } -} -``` - -### 流失预警自动化 -```python -lifecycle_automation = { - "churn_early_warning": { - "trigger": "流失概率模型分数 > 0.7", - "features": [ - "最近30天消息打开次数", - "距上次购买天数", - "社群互动频率变化", - "朋友圈互动下降率", - "退群/静音行为", - ], - "action": "触发人工干预——高级顾问进行 1v1 跟进" - } -} -``` - -## WeCom Mass Messaging Limits -自动化触达必须遵守平台限制： -- 客户群发消息：每月不超过 4 次 -- 朋友圈发布：每天不超过 1 条 -- 敏感行业（金融、医疗、教育）需合规审查 - -## SOP Dashboard SQL -```sql --- 社群转化漏斗 -SELECT - group_type AS group_type, - COUNT(DISTINCT member_id) AS group_members, - COUNT(DISTINCT CASE WHEN has_clicked_product = 1 THEN member_id END) AS product_clickers, - COUNT(DISTINCT CASE WHEN has_ordered = 1 THEN member_id END) AS purchasers, - ROUND(COUNT(DISTINCT CASE WHEN has_ordered = 1 THEN member_id END) - * 100.0 / COUNT(DISTINCT member_id), 2) AS group_conversion_rate -FROM scrm_group_conversion -WHERE stat_date BETWEEN '{start_date}' AND '{end_date}' -GROUP BY group_type; -``` - -## Related Concepts -- [[私域运营]] -- [[用户生命周期管理]] -- [[社群分层运营]] -- [[SCRM]] - -## Related Entities -- [[Marketing Private Domain Operator]] \ No newline at end of file diff --git a/wiki/concepts/SOUL.md b/wiki/concepts/SOUL.md deleted file mode 100644 index 7554272e..00000000 --- a/wiki/concepts/SOUL.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "SOUL.md" -type: concept -tags: [OpenClaw, Agent] ---- - -## 定义 -SOUL.md 是 OpenClaw workspace 中的叙事性角色设定文档（人物小传），定义 Agent 的性格、说话风格、价值观和行为模式。 - -## 职责 -- 定义 Agent 的自我叙事（"我是什么样的存在"） -- 规定沟通风格（口语化/专业/轻松） -- 阐明价值观和边界 -- 包含有趣的细节（如偏好、习惯） - -## 与 AGENTS.md 的区别 -- AGENTS.md：偏向**功能性**——这个 Agent 做什么、怎么做、优先级是什么 -- SOUL.md：偏向**人格性**——这个 Agent 是谁、有什么个性、说话什么风格 - -## 典型结构 -```markdown -# SOUL -我是一个有点话痨但极其靠谱的 AI 助理。 - -## 说话风格 -- 口语化但不失准确 -- 会主动问清楚模糊的需求 - -## 价值观 -- 诚实第一：不确定的事情直说不确定 -- 效率优先：能一句话说清楚的事，不用三句话 -``` - -## 来源 -- [[万字讲透OpenClaw🦞从"能用"到"真好用"的分水岭：Workspace 深度解析]] - -## 相关 -- [[AGENTS.md]]：岗位说明书 -- [[IDENTITY.md]]：结构化身份元数据（与 SOUL.md 互补） -- [[USER.md]]：用户画像（与 SOUL.md 配合形成"人机关系共识"） \ No newline at end of file diff --git a/wiki/concepts/SPI-Features.md b/wiki/concepts/SPI-Features.md deleted file mode 100644 index 9ce5886e..00000000 --- a/wiki/concepts/SPI-Features.md +++ /dev/null @@ -1,17 +0,0 @@ ---- -title: "SPI Features" -type: concept -tags: - - Network-Security - - Firewall ---- - -## Definition -SPI（Stateful Packet Inspection）是一种状态包检查防火墙功能，能够追踪活跃连接的状态，基于连接状态做出过滤决策，而非仅依赖静态规则。 - -## Application -在 AWS Landing Zone 网络隔离场景中，Checkpoint 防火墙启用 SPI 功能，默认拒绝（default deny）策略，仅允许必需的服务和网络段进入 Landing Zone。 - -## Related Concepts -- [[Network-Segregation]] -- [[Checkpoint-Firewall]] \ No newline at end of file diff --git a/wiki/concepts/SPIN-Selling.md b/wiki/concepts/SPIN-Selling.md deleted file mode 100644 index 92429517..00000000 --- a/wiki/concepts/SPIN-Selling.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: "SPIN Selling" -type: concept -tags: [sales, methodology, discovery] ---- - -## 定义 -Neil Rackham 提出的四步提问销售方法论，通过特定问题序列帮助销售员深入了解买家情况并建立紧迫感。 - -## 核心要素 - -### Situation Questions（情境问题） -- 目的：建立上下文 -- 使用限制：最多 2-3 个，可通过研究预先了解 -- 示例： - - "请介绍一下您的团队目前如何处理[流程]。" - - "您目前使用什么工具来完成[功能]。" - -### Problem Questions（问题问题） -- 目的：揭示不满 -- 示例： - - "这个流程哪里会出问题？" - - "当[场景]发生时会发生什么？" - - "目前最让人沮丧的是什么？" - -### Implication Questions（暗示性问题）— **交易达成关键** -- 目的：扩大痛苦，激活损失厌恶 -- 关键洞察：买家为避免损失比获取收益更努力 -- 示例： - - "当那个环节出问题后，对[相关团队/指标]的间接影响是什么？" - - "这如何影响您实现[战略目标]的能力？" - - "如果这种情况持续 6-12 个月，这会给您带来多大成本？" - -### Need-Payoff Questions（需求回报问题） -- 目的：让买家自己描述价值 -- 示例： - - "如果能解决这个问题，您的团队会获得什么？" - - "这会如何改变您实现[目标]的能力？" - -## 关联实体 -- [[Neil Rackham]]：方法论创始人 -- [[Sales Discovery Coach]] \ No newline at end of file diff --git a/wiki/concepts/SQL-View.md b/wiki/concepts/SQL-View.md deleted file mode 100644 index fe544c06..00000000 --- a/wiki/concepts/SQL-View.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "SQL View" -type: concept -tags: [数据库, SQL, 数据预处理] ---- - -## Definition -预处理的数据库视图（View），通过 SQL 查询定义，用于解析 JSON 字段、计算派生指标、聚合数据，使 BI 工具能直接使用数值字段。 - -## Common Use Cases -- 解析 JSON 字段：如 `JSON_EXTRACT(prodct_rating, '$.rating') AS rating` -- 计算派生指标：如 `(final_price * sold) AS total_gmv` -- 数据聚合：如按类目汇总销量、销售额 - -## Example -```sql -CREATE OR REPLACE VIEW view_products_cleaned AS -SELECT - id, - title, - category, - final_price, - sold, - JSON_EXTRACT(prodct_rating, '$.rating') AS rating, - JSON_EXTRACT(prodct_rating, '$.count') AS rating_count, - (final_price * sold) AS total_gmv -FROM products; -``` - -## Related Concepts -- [[Apache-Superset]]：使用 SQL View 作为数据集 -- [[JSON-字段解析]]：从 JSON 数据中提取值 \ No newline at end of file diff --git a/wiki/concepts/SRE-provided-AMIs.md b/wiki/concepts/SRE-provided-AMIs.md deleted file mode 100644 index 487e74e0..00000000 --- a/wiki/concepts/SRE-provided-AMIs.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: "SRE-provided AMIs" -type: concept -tags: - - aws - - ami - - automation -sources: [ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs] -last_updated: 2026-04-18 ---- - -## Definition -SRE 团队预先构建的 Amazon Machine Images，内置用于自动加入域的 PowerShell 和 Shell 脚本。 - -## Use Cases -- Windows 实例自动域加入 -- Linux 实例 DNS 动态更新 -- 自动化用户权限分配 -- 自动清理旧 AD 对象 - -## Provider -SRE 团队 - -## Related -- [[Gruntwork-Landing-Zone]] -- [[Domain-Join]] \ No newline at end of file diff --git a/wiki/concepts/SRE.md b/wiki/concepts/SRE.md deleted file mode 100644 index 015ef490..00000000 --- a/wiki/concepts/SRE.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "SRE" -type: concept -tags: [sre, devops, reliability] ---- - -## Definition -SRE（Site Reliability Engineering，站点可靠性工程）是一种将软件工程方法应用于运维问题的实践，旨在创建高度可靠和可扩展的系统。 - -## Core Practices -- **SLI/SLO/SLA**：服务水平指标/目标/协议 -- **错误预算**：允许的故障配额，用于平衡创新与稳定性 -- **Postmortem（事后分析）**：不追究责任的故障复盘，提取学习教训 -- **Toil Reduction**：减少重复性手工运维工作 - -## Key Metrics -- **MTTR**（Mean Time To Recovery）：平均恢复时间 -- **MTTF**（Mean Time To Failure）：平均故障间隔时间 -- **可用性目标**：通常为 99.9%（三个九）到 99.99%（四个九） - -## Related Entities -- [[AI SRE]] — 使用 AI 自动化 SRE 任务的工具 - -## Related Concepts -- [[DevOps]] — 结合开发与运营实现持续软件交付的方法论 -- [[混沌工程]] — 主动测试系统韧性的实践方法 -- [[无责复盘]] — 不追究个人责任，聚焦问题本质的失败分析方法 \ No newline at end of file diff --git a/wiki/concepts/SSH-Integration-Patterns.md b/wiki/concepts/SSH-Integration-Patterns.md deleted file mode 100644 index e67f16d0..00000000 --- a/wiki/concepts/SSH-Integration-Patterns.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: "SSH Integration Patterns" -type: concept -tags: [ssh, integration, network, streaming] ---- - -## 定义 -SSH 集成模式（SSH Integration Patterns）是终端仿真器与 SSH 服务端建立连接并数据传输的技术模式。 - -## 核心模式 - -### I/O 桥接 -- 将 SSH 流桥接到终端模拟器的输入/输出 -- 处理字节流双向传输 -- 支持加密数据传输 - -### 连接状态管理 -- 连接建立中状态 -- 已连接状态 -- 断开连接状态 -- 重连场景处理 - -### 错误处理 -- 连接错误显示 -- 认证失败提示 -- 网络问题指示 - -## 技术栈 -- SwiftNIO SSH：Swift 原生 SSH 实现 -- NMSSH：Objective-C SSH 库 -- libssh2：C 语言底层库 - -## 最佳实践 -1. 使用非阻塞 I/O -2. 实现连接超时 -3. 支持断线重连 -4. 显示连接状态 -5. 正确处理 SSH 事件 - -## 相关概念 -- [[Terminal Emulation]]：终端仿真 -- [[SwiftTerm]]：Swift 终端库 \ No newline at end of file diff --git a/wiki/concepts/SSH.md b/wiki/concepts/SSH.md deleted file mode 100644 index d52a7b51..00000000 --- a/wiki/concepts/SSH.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: "SSH" -type: concept -tags: [security, networking, remote-access] -date: 2026-04-16 ---- - -## Definition -SSH（Secure Shell，安全外壳）是一种加密网络协议，用于安全地远程登录计算机系统、执行命令和传输文件。 - -## Key Properties -- 默认端口：22 -- 加密传输（RSA、ECDSA、Ed25519 等算法） -- 支持密码认证和公钥认证 -- 支持端口转发、隧道功能 - -## Commands -```bash -ssh user@hostname # 远程登录 -scp file user@host:/path # 安全复制 -sftp user@host # 安全文件传输 -ssh-keygen -t ed25519 # 生成密钥 -``` - -## Security Best Practices -- 禁用密码认证，使用密钥登录 -- 更改默认端口 -- 使用防火墙限制访问来源 -- 启用 Fail2Ban 防止暴力破解 -- 定期更新 SSH 版本 - -## Connections -- [[OpenSSH]] ← implements ← [[SSH]] -- [[UFW]] ← controls_access ← [[SSH]] \ No newline at end of file diff --git a/wiki/concepts/SSM-Access.md b/wiki/concepts/SSM-Access.md deleted file mode 100644 index 14684a30..00000000 --- a/wiki/concepts/SSM-Access.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: "SSM Access" -type: concept -tags: - - AWS - - Security - - Remote-Access ---- - -## Definition -SSM Access（AWS Systems Manager Access）是一种通过 AWS Systems Manager 实现安全远程访问的方案，用户通过扮演 IAM 角色获得目标 EC2 实例的 SSM agent 访问权限，无需 VPN 即可实现安全连接。 - -## Application -替代传统 VPN，通过浏览器会话或 AWS CLI 访问 AWS 环境内的 EC2 实例。优势包括：双因素认证、安全连接位于 AWS 网络内、成本低、部署快。 - -## Related Concepts -- [[AWS-Landing-Zone]] -- [[Zero-Trust-Access]] - -## Related Entities -- [[AWS]] \ No newline at end of file diff --git a/wiki/concepts/STLC.md b/wiki/concepts/STLC.md deleted file mode 100644 index eaeae963..00000000 --- a/wiki/concepts/STLC.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: "STLC" -type: concept -tags: [Security, Development-Lifecycle, Micro-Focus] -last_updated: 2026-04-19 ---- - -## Definition -STLC（Security Development Life Cycle，安全开发生命周期）是 Micro Focus 产品开发的基础框架，包含 13 个安全与隐私轨道。Product Privacy Framework 是 STLC 中 13 个安全与隐私轨道之一。 - -## Components -- 13 个安全与隐私轨道 -- Product Privacy Framework（产品隐私框架）是其中之一 -- SDL（Security Development Lifecycle）第五大支柱 - -## Related Concepts -- [[Product Privacy Framework]] -- [[Security Development Lifecycle]] -- [[PII]] - -## Related Entities -- [[Micro Focus]] -- [[Shlomi Ben-Hur]] \ No newline at end of file diff --git a/wiki/concepts/SaaS.md b/wiki/concepts/SaaS.md deleted file mode 100644 index 85fe3abd..00000000 --- a/wiki/concepts/SaaS.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: "SaaS (Software as a Service)" -type: concept -tags: [Cloud, Service-Model] -sources: [Cloud-Maturity-Model-A-Detailed-Guide-For-Cloud-Adoption] -last_updated: 2025-02-28 ---- - -## Summary -SaaS（软件即服务）是以订阅方式通过互联网提供软件应用的云计算服务模型。 - -## Definition -SaaS 使客户无需在本地安装和维护软件，而是通过订阅方式在线使用应用程序。 - -## Example Providers -- Salesforce -- Microsoft 365 -- Google Workspace - -## Connections -- [[SaaS]] ← part_of ← [[Cloud-Maturity-Model]] -- [[SaaS]] ← type_of ← [[Cloud-Service-Models]] diff --git a/wiki/concepts/SalesCoaching.md b/wiki/concepts/SalesCoaching.md deleted file mode 100644 index 73cba783..00000000 --- a/wiki/concepts/SalesCoaching.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -title: "Sales Coaching" -type: concept -tags: [sales, coaching, methodology] -last_updated: 2026-04-20 ---- - -## Summary -- 定义：通过结构化提问和行为反馈提升销售代表技能的专业方法 -- 目标：实现可观察的、可重复的行为改变 -- 核心原则：coaching 技能而非态度，管理意愿而非行为 - -## Key Components - -### Socratic 方法 -- Ask before telling：先问再做，而不是直接告知答案 -- "What would you do differently if you could replay that moment?" -- 作用：引导销售代表自己发现问题而非被动接受指令 - -### 区分技能差距 vs 意愿差距 -- **技能差距（Skill Gap）**：销售代表不知道如何做 → 通过 coaching 修复 -- **意愿差距（Will Gap）**：销售代表知道如何做但不去做 → 通过管理修复 -- 关键：不要混淆两者，否则 coaching 无效 - -### 每次 Coaching 的最低要求 -- 至少产出一个具体的、可行为的、可操作的收获 -- 不是"改进发现"，而是"在下次对话中至少提出三个跟进问题后再展示方案" - -## Coaching 形式 - -### Call Coaching -- 回顾通话录音 -- 识别具体行为模式 -- 提供具体的行为反馈而非模糊建议 - -### Pipeline Review -- 每周 1:1：活动、障碍、习惯 -- 双周 pipeline：交易健康、资格差距、风险 -- 月度/季度：模式识别、准确性、资源分配 - -### Deal Prep -- 目标是什么 -- 买家需要听到什么 -- 我们的诉求是什么 -- 三个最可能的反对意见及处理方案 - -## Connections -- [[Sales Coach]]：实施 Sales Coaching 的 AI Agent -- [[Sales Discovery Coach]]：专注于发现阶段的 coaching -- [[MEDDPICC]]：资格认证框架 - -## Related Concepts -- [[Pipeline Review]]：pipeline 审查流程 -- [[Forecast Accuracy]]：预测准确性 -- [[Deal Strategy]]：交易策略 -- [[MEDDPICC]]：销售资格认证框架 \ No newline at end of file diff --git a/wiki/concepts/Sandler-Pain-Funnel.md b/wiki/concepts/Sandler-Pain-Funnel.md deleted file mode 100644 index 46055f3f..00000000 --- a/wiki/concepts/Sandler-Pain-Funnel.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: "Sandler Pain Funnel" -type: concept -tags: [sales, methodology, discovery] ---- - -## 定义 -Sandler 销售系统中的痛点漏斗，从表面症状逐步深入到业务影响到个人/情感 stakes。 - -## 三层漏斗结构 - -### Level 1 — Surface Pain（表面痛点） -技术/功能层面的问题症状 -- "跟我说说那个。" -- "能举个例子吗？" -- "这种情况持续多久了？" - -### Level 2 — Business Impact（业务影响） -可量化的业务成本 -- "这给公司造成了多大损失？" -- "这如何影响[收入/效率/风险]？" -- "你们尝试过什么解决方案吗？为什么没成功？" - -### Level 3 — Personal/Emotional Stakes（个人/情感风险） -**大多数销售员从未到达这一层** -- "这对您和您的团队的日常有什么影响？" -- "如果这个问题不解决，会发生什么？" -- "如果这个问题一直不解决，对您个人有什么影响？" - -## 关键洞察 -- 购买决定是情绪化的决定，需要理性论证 -- VP 告诉你"我们需要更好的报表"的背后是"我 Q3 要向董事会汇报，我不信任我的数据" -- 第二层才是驱动紧迫感的真正原因 - -## 关联实体 -- [[Sales Discovery Coach]] \ No newline at end of file diff --git a/wiki/concepts/Scrapy.md b/wiki/concepts/Scrapy.md deleted file mode 100644 index e0e8a979..00000000 --- a/wiki/concepts/Scrapy.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: "Scrapy" -type: concept -tags: [爬虫, Python, Scrapy] -date: 2025-11-11 ---- - -## Definition -Scrapy 是一个用 Python 编写的快速高级网页爬虫框架，用于从网站中提取结构化数据。 - -## Key Features -- 轻量高效、插件生态丰富、可 Docker 化部署 -- 对 JS 渲染页面支持弱，需要配合 Splash 或 Playwright - -## Role -在电商数据采集系统中，Scrapy 负责结构化抓取、分页调度、下载媒体，输出 JSON 或 CSV 文件供 n8n 消费。 - -## Connections -- [[Scrapy]] ← depends_on ← [[Playwright]] -- [[n8n]] ← orchestrates ← [[Scrapy]] diff --git a/wiki/concepts/Screen-Reader-Testing.md b/wiki/concepts/Screen-Reader-Testing.md deleted file mode 100644 index 53eb95a1..00000000 --- a/wiki/concepts/Screen-Reader-Testing.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: "Screen Reader Testing" -description: 使用屏幕阅读器验证网页内容可访问性的测试方法 -tags: [accessibility, testing, assistive-technology] ---- - -## Definition -Screen Reader Testing 是使用屏幕阅读器软件（如 VoiceOver、NVDA、JAWS）验证网页内容是否对视力障碍用户可访问的测试方法。 - -## 主要屏幕阅读器 -| 软件 | 平台 | 特点 | -|------|------|------| -| VoiceOver | macOS/iOS | Apple 设备内置，免费 | -| NVDA | Windows | 开源免费，社区活跃 | -| JAWS | Windows | 商业软件，功能全面 | -| TalkBack | Android | Android 内置 | -| VoiceOver | Safari (iOS) | 移动端测试 | - -## 测试协议 -### 导航测试 -- Heading Structure（标题层级） -- Landmark Regions（地标区域） -- Skip Links（跳转链接） -- Tab Order（Tab 顺序） -- Focus Visibility（焦点可见性） - -### 组件测试 -- Buttons（按钮角色和标签） -- Links（链接描述） -- Forms（表单标签和错误提示） -- Modals（焦点陷阱） -- Custom Widgets（自定义组件 ARIA） - -### 动态内容测试 -- Live Regions（实时区域） -- Loading States（加载状态） -- Error Messages（错误消息） -- Toast/Notifications（通知） - -## Key Findings Format -| 组件 | 屏幕阅读器行为 | 预期行为 | 状态 | -|------|--------------|---------|------| -| Name | 实际宣布内容 | 应该宣布的内容 | PASS/FAIL | - -## Related Concepts -- [[WCAG 2.2]] -- [[Keyboard Navigation Audit]] -- [[ARIA Patterns]] - -## Source -- [[Accessibility Auditor]] \ No newline at end of file diff --git a/wiki/concepts/Search-Term-Analysis.md b/wiki/concepts/Search-Term-Analysis.md deleted file mode 100644 index 4bd96e94..00000000 --- a/wiki/concepts/Search-Term-Analysis.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "Search Term Analysis" -type: concept -tags: [Paid Media, Search Advertising, Data Analysis] ---- - -## Definition -大规模搜索词报告挖掘、模式识别、N-gram 分析和查询意图聚类的技术过程，是付费搜索优化的核心数据分析活动。 - -## Core Components -- **Pattern Identification**：识别搜索词中的重复模式 -- **N-gram Analysis**：分析连续 N 个词的组合频率 -- **Query Clustering**：按意图或主题对查询进行分组 -- **Trend Analysis**：查询随时间的趋势变化 - -## Application -付费搜索广告账户中，用于识别高价值查询、发现新关键词机会、定位浪费支出。是 Search Query Analyst 智能体的核心能力之一。 - -## Related Concepts -- [[Negative Keyword Architecture]] -- [[Intent Classification]] -- [[Waste Identification]] - -## Related Entities -- [[Search Query Analyst]] \ No newline at end of file diff --git a/wiki/concepts/Seasonal-Calendar.md b/wiki/concepts/Seasonal-Calendar.md deleted file mode 100644 index 4429f90f..00000000 --- a/wiki/concepts/Seasonal-Calendar.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: "Seasonal Calendar" -type: concept -tags: [market-timing, france, freelance] -date: 2026-04-20 ---- - -## Summary -法国 IT 咨询市场的季节性规律，影响需求波动和议价能力。 - -## Monthly Breakdown -| Period | Market Dynamic | Strategy | -|--------|---------------|----------| -| **January** | 预算重启，新项目启动 | 最佳提案时机，ESN 积极招人 | -| **February-March** | 活跃招聘，高需求 | 议价能力峰值，争取更高 TJM | -| **April-June** | 稳定状态，部分预算审查 | 适合续约谈判提价 | -| **July-August** | 夏季放缓，团队缩编 | 减少机会，用于技能提升和行政 | -| **September** | 返校季 — 第二个高峰季 | 强烈需求重启，适合新平台发布 | -| **October-November** | 年终预算消耗 | ESN 需要填补剩余预算，可谈 | -| **December** | 放缓 holiday planning | 为 1 月 Pipeline 建设 | - -## Connections -- [[French Consulting Market Navigator]] ← market_timing diff --git a/wiki/concepts/Second-Brain.md b/wiki/concepts/Second-Brain.md deleted file mode 100644 index 43a23c15..00000000 --- a/wiki/concepts/Second-Brain.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "Second Brain" -type: concept -tags: [] ---- - -## Definition -通过 AI Agent 实现的个人知识管理系统，通过即时通讯（Telegram/Discord/iMessage）零摩擦捕获信息，OpenClaw 永久存储，Next.js 搜索界面检索。 - -## Core Principles -- 捕获如发短信般简单 -- 检索如搜索般便捷 -- 无需文件夹、无需标签、只需文本 - -## Related Entities -- [[OpenClaw]] -- [[Next.js]] -- [[Telegram]] -- [[Discord]] - -## Related Concepts -- [[Memory System]] -- [[信息黑洞]] -- [[LLM Wiki]] - -## Related Sources -- [[second-brain]] \ No newline at end of file diff --git a/wiki/concepts/Secrets-Management.md b/wiki/concepts/Secrets-Management.md deleted file mode 100644 index 34a1b6cc..00000000 --- a/wiki/concepts/Secrets-Management.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: "Secrets Management" -type: concept -tags: [security, devops, best-practices] -sources: [ctp-topic-37-secrets-certificates-management, ctp-topic-62-aws-secrets-manager] -last_updated: 2026-04-19 ---- - -## Summary -密钥管理是企业管理数字认证凭证（密码、API Token、加密密钥、证书）的系统性方法，确保应用服务、特权账户和 IT 生态系统中敏感信息的安全存储、访问控制和自动轮换。 - -## Definition -管理数字认证凭证、密钥、密码、API 和 Token 等敏感信息的工具和方法，涵盖存储、访问控制、轮换、审计全生命周期。 - -## Core Components -- **密钥存储**：集中化安全存储敏感信息 -- **访问控制**：基于身份的细粒度权限管理 -- **自动轮换**：定时自动更新密钥降低泄露风险 -- **审计日志**：记录所有访问和操作行为 - -## Implementation Patterns -- **托管服务**：AWS Secrets Manager、Azure Key Vault、GCP Secret Manager -- **自托管方案**：HashiCorp Vault（支持动态密钥、证书签名） -- **特权访问管理**：CyberArk PAM、Micro Focus PAM - -## Best Practices -- 避免明文存储密钥 -- 实施最小权限原则 -- 启用自动轮换 -- 集中化密钥管理 -- 集成 CI/CD 流程 - -## Connections -- [[Secrets Management]] ← 应用于 ← [[CI/CD]] -- [[AWS Secrets Manager]] ← 实现 ← [[Secrets Management]] -- [[HashiCorp Vault]] ← 实现 ← [[Secrets Management]] -- [[Zero-Trust-Architecture]] ← 要求 ← [[Secrets Management]] \ No newline at end of file diff --git a/wiki/concepts/Secure-Boot.md b/wiki/concepts/Secure-Boot.md deleted file mode 100644 index ce96f6ee..00000000 --- a/wiki/concepts/Secure-Boot.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "Secure Boot" -type: concept -tags: [security, boot, uefi, firmware] -date: 2026-04-16 ---- - -## Aliases -- Secure Boot -- 安全启动 - -## Definition -Secure Boot 是 UEFI 标准的安全特性，通过数字签名验证引导加载程序，防止恶意软件在系统启动阶段注入。在安装 Ubuntu 等第三方操作系统时，通常需要关闭以避免驱动兼容性问题。 - -## Key Properties -- 功能：验证引导加载程序数字签名 -- 保护阶段：操作系统启动前 -- 可关闭：大多数 BIOS/UEFI 允许禁用 -- 微软件签名：使用 PK/KEK/DB 数据库 - -## Use Cases -- Windows 安全启动（默认开启） -- 阻止 bootkit 攻击 -- Ubuntu/NixOS 等 Linux 发行版安装（建议关闭） - -## Recommendations -- HP ZBook 安装 Ubuntu：建议关闭 Secure Boot 以避免第三方驱动兼容性问题 -- 安装完成后可根据需要重新开启 - -## Connections -- [[Secure Boot]] ← part_of ← [[UEFI]] -- [[Secure Boot]] ← conflicts_with ← [[Ubuntu]] \ No newline at end of file diff --git a/wiki/concepts/Secure-Coding.md b/wiki/concepts/Secure-Coding.md deleted file mode 100644 index e42b3847..00000000 --- a/wiki/concepts/Secure-Coding.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: "Secure Coding" -type: concept -tags: [security, development] -sources: [what-is-devsecops-best-practices-benefits-and-tools] -last_updated: 2026-04-20 ---- - -## Definition -安全编码（Secure Coding）是编写代码时遵循安全最佳实践的实践，旨在防止安全漏洞。它是 DevSecOps 的核心组成部分，通过在编码阶段就嵌入安全检查来实现"安全左移"。 - -## Key Principles -- **输入验证**：验证所有用户输入 -- **输出编码**：正确编码输出防止 XSS -- **参数化查询**：使用参数化查询防止 SQL 注入 -- **最小权限**：遵循最小权限原则 -- **安全存储**：安全存储敏感信息 - -## Best Practices -- 遵循 OWASP 安全编码指南 -- 使用安全库和框架 -- 代码审查包含安全检查 -- 自动化安全测试集成到 IDE - -## Connections -- [[DevSecOps]] ← implements ← [[Secure Coding]] -- [[SAST]] ← validates ← [[Secure Coding]] -- [[OWASP]] ← defines ← [[Secure Coding]] \ No newline at end of file diff --git a/wiki/concepts/Security-Group-Policy.md b/wiki/concepts/Security-Group-Policy.md deleted file mode 100644 index 36d7d463..00000000 --- a/wiki/concepts/Security-Group-Policy.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "Security Group Policy" -type: concept -tags: [AWS, Security, Firewall, Policy] -sources: [] -last_updated: 2026-04-19 ---- - -## Summary -Security Group Policy 是 Firewall Manager 中用于管理跨账户安全组规则的策略类型。 - -## Definition -在 Firewall Manager 环境中，Security Group Policy 定义了安全组的创建、更新和清理规则，支持三种类型： - -## Policy Types - -### 1. Common Security Group（通用安全组） -- 附加基线安全组到资源 -- 允许产品团队添加额外规则 -- 确保所有账户拥有基础安全保护 - -### 2. Audit and Enforcement（审计与强制） -- 检测并拒绝过度宽松的规则 -- 支持手动修复或自动修复 -- 提供合规性仪表板视图 - -### 3. Unused Security Group Cleanup（清理未使用） -- 识别和删除冗余安全组 -- 简化安全管理 -- 减少攻击面 - -## Key Features - -- 支持 AWS Organizations 组织单位（OU）级别应用 -- 通过 Prefix List 共享规则 -- 使用 RAM 实现跨账号资源共享 - -## Related Concepts -- [[Security Group]] -- [[AWS Firewall Manager]] \ No newline at end of file diff --git a/wiki/concepts/Self-Healing-Systems.md b/wiki/concepts/Self-Healing-Systems.md deleted file mode 100644 index 9a5749bc..00000000 --- a/wiki/concepts/Self-Healing-Systems.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "Self-Healing Systems" -type: concept -tags: [automation, resilience, fault-tolerance] -sources: [How-Agentic-AI-can-help-for-Cloud-DevOps] -last_updated: 2026-04-16 ---- - -## Summary -Self-Healing Systems（自愈系统）是指能够主动检测异常并自动修复问题的系统，无需人工干预即可恢复正常运行状态。 - -## Definition -具备自动检测、诊断和修复故障能力的系统，能够在问题发生时自动恢复服务。 - -## Key Mechanisms -- **异常检测**：持续监控关键指标，检测偏离正常模式的行为 -- **自动诊断**：分析日志和指标，确定故障根本原因 -- **自动修复**：执行预定义或 AI 生成的修复脚本 -- **扩缩容**：根据负载自动调整资源分配 - -## Connections -- [[Agentic AI]] ← enables ← [[Self-Healing Systems]]：Agentic AI 实现自愈能力 -- [[Kubernetes]] ← hosts ← [[Self-Healing Systems]]：K8s 提供自愈机制（Pod 重启、节点替换） -- [[混沌工程]] ← tests ← [[Self-Healing Systems]]：混沌工程验证自愈系统有效性 diff --git a/wiki/concepts/Self-Improving-Skill.md b/wiki/concepts/Self-Improving-Skill.md deleted file mode 100644 index b254cd9c..00000000 --- a/wiki/concepts/Self-Improving-Skill.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: "Self-Improving Skill" -type: concept -tags: [openclaw, memory, agent] -last_updated: 2026-04-17 ---- - -## Definition -Self-Improving Skill（自改进技能）是 OpenClaw 中的一种结构化经验记录系统，使 AI Agent 能够在每次遇到问题、做出决策、或发现值得记住的东西时自动记录学习内容，实现持续改进。 - -## Structure -```markdown -## [LRN-YYYYMMDD-NNN] type - -**Logged**: YYYY-MM-DDTHH:MM:SS+08:00 -**Priority**: high|medium|low -**Status**: pending|resolved -**Area**: config|workflow|correction - -### Summary -一句话描述学到了什么 - -### Details -具体发生了什么、问题出在哪 - -### Suggested Action -以后遇到类似情况该怎么做 - -### Metadata -- Pattern-Key: xxx -- Recurrence-Count: N -- See Also: LRN-YYYYMMDD-NNN -``` - -## Key Fields -- **Pattern-Key**：经验检索键，用于追踪同一类型问题的生命周期 -- **Recurrence-Count**：重复次数，区分一次性错误和系统性重复 -- **Suggested Action**：具体可执行的改进建议，而非抽象的注意事项 - -## Use Cases -- 记录 AI Agent 犯过的错误及修复方法 -- 记录工作流优化发现 -- 记录配置技巧和环境差异 - -## Related -- [[双层记忆架构]] -- [[每日复盘机制]] -- [[Pattern-Key]] \ No newline at end of file diff --git a/wiki/concepts/Self-Map.md b/wiki/concepts/Self-Map.md deleted file mode 100644 index 156e164a..00000000 --- a/wiki/concepts/Self-Map.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: "Self-Map" -type: concept -tags: [] ---- - -## Definition -自映射，记作 Φ: G → G，定义为 Φ(G) = M(G, O(G(I), Ω))。这是生成器空间上的单步更新函数。 - -## Context -自映射定义了递归自优化系统的单次迭代：给定当前生成器 G，执行生成→优化→更新三个步骤，返回新的生成器 G'。迭代应用自映射产生生成器序列 {G_n}。 - -## Formula -``` -P = G(I) # 生成 -P* = O(P, Ω) # 优化 -G' = M(G, P*) # 更新 -Φ(G) = G' # 自映射 -``` - -## Related Concepts -- [[Generator Space]] -- [[Meta-Generative Operator]] -- [[Optimization Operator]] -- [[Fixed Point]] -- [[Recursive Self-Optimizing Generative Systems]] \ No newline at end of file diff --git a/wiki/concepts/Self-Serve-Migration.md b/wiki/concepts/Self-Serve-Migration.md deleted file mode 100644 index 52e2c127..00000000 --- a/wiki/concepts/Self-Serve-Migration.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: "Self-Serve Migration" -type: concept -tags: - - DevOps - - Migration - - GitHub - - GitLab -date-added: 2026-04-19 ---- - -## Definition -Self-Serve Migration（自服务迁移）是一种迁移模式，在这种模式下，各团队自行定义需求、规划迁移方案并执行管道转换，而非由中央团队统一执行。在 OpenText 的 GitHub 到 GitLab 迁移中采用此模式。 - -## Characteristics -- 各团队自行定义在 GitHub 中拥有的资产 -- 各团队规划如何移动代码和转换 CI/CD 管道 -- Build Hub 团队仅在需要时提供协助 -- 权限通过 PHT（Product Hub platform）进行自服务管理 - -## Related Concepts -- [[CI/CD-流水线]] -- [[GitOps]] - -## Related Entities -- [[GitHub-Enterprise]] -- [[GitLab]] -- [[Build-Hub]] -- [[OpenText]] - -## Connections -- [[Self-Serve-Migration]] → enabled_by → [[GitLab]] -- [[Build-Hub]] ← supports ← [[Self-Serve-Migration]] \ No newline at end of file diff --git a/wiki/concepts/Semantic-Index.md b/wiki/concepts/Semantic-Index.md deleted file mode 100644 index b49be66d..00000000 --- a/wiki/concepts/Semantic-Index.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: "Semantic Index" -type: concept -tags: [index, code-intelligence, navigation] -last_updated: 2026-04-20 ---- - -## Definition -Semantic Index（语义索引）是存储代码符号定义、引用关系和悬停文档的持久化数据结构，支持快速代码导航和文档查询。 - -## Navigation Index Format (nav.index.jsonl) -```jsonl -{"symId":"sym:AppController","def":{"uri":"file:///src/app.php","l":10,"c":6},"refs":[ - {"uri":"file:///src/routes.php","l":5,"c":10} -],"hover":{"contents":{"kind":"markdown","value":"```php\nclass AppController extends BaseController\n```"}}} -``` - -## Index Schema -| Field | Description | -|-------|-------------| -| symId | 符号唯一标识符，格式：`sym:` | -| def | 定义位置（文件 URI + 行号 + 列号） | -| refs | 引用位置数组 | -| hover | 悬停文档内容（Markdown 格式） | - -## Storage Backends -- **JSONL**：流式写入，适合大规模索引 -- **SQLite**：支持快速随机访问和复杂查询 -- **LSIF**：Language Server Index Format，用于预计算数据导入/导出 - -## Performance Requirements -- 定义查找：<20ms（缓存），<60ms（未缓存） -- 支持 100k+ 符号规模 -- 增量更新，不重建整个索引 - -## Connections -- [[graphd]] ← 维护 ← [[Semantic Index]] -- [[LSIF (Language Server Index Format)]] ← 导入/导出 ← [[Semantic Index]] diff --git a/wiki/concepts/Sentiment-Early-Warning-System.md b/wiki/concepts/Sentiment-Early-Warning-System.md deleted file mode 100644 index dcca1ebb..00000000 --- a/wiki/concepts/Sentiment-Early-Warning-System.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: "Sentiment Early Warning System" -type: concept -tags: [weibo, monitoring, crisis, risk-management] -last_updated: 2026-04-21 ---- - -## Definition -情感预警系统是品牌在微博平台建立实时监控、识别和应对负面情绪的体系，目的是在危机升级前及时干预。 - -## Severity Classification -| Level | Name | Criteria | Response Time | Response Team | -|-------|------|----------|---------------|--------------| -| Blue | 监控 | 负面提及 < 100 | 4小时内 | 运营团队 | -| Yellow | 预警 | 负面提及 100-500 | 2小时内 | 运营+公关 | -| Orange | 严重 | 负面提及 > 500 或 KOL 介入 | 1小时内 | 管理层+公关 | -| Red | 危机 | 进入热搜或主流媒体报道 | 30分钟内 | CEO+法务+公关 | - -## Golden 4-Hour Response Rule -1. **Detection（检测）**：识别负面情绪信号 -2. **Assessment（评估）**：判断严重程度和扩散范围 -3. **Respond（响应）**：选择策略并执行 -4. **Track（追踪）**：监控效果并调整 - -## Response Strategy Selection -- **直接回应**：坦诚面对，真诚道歉 -- **间接引导**：通过第三方叙事转移焦点 -- **战略沉默**：在评估阶段选择不立即回应 - -## Comment Section Management -- 置顶关键回复 -- 识别并处理水军评论 -- 引导粉丝正向响应 - -## Post-Incident Review -- 事件时间线还原 -- 传播路径分析 -- 响应效果评估 -- 改进建议输出 - -## Connections -- [[Marketing Weibo Strategist]] → operates → [[Sentiment Early Warning System]] -- [[Trending Topic Operations]] ← monitors ← [[Sentiment Early Warning System]] \ No newline at end of file diff --git a/wiki/concepts/Sequential-Handoffs.md b/wiki/concepts/Sequential-Handoffs.md deleted file mode 100644 index 0b257ede..00000000 --- a/wiki/concepts/Sequential-Handoffs.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: "Sequential Handoffs" -type: concept -tags: [multi-agent, workflow, coordination] -last_updated: 2026-04-21 ---- - -## Definition -顺序交接（Sequential Handoffs）是一种多智能体工作流模式，其中每个智能体的输出直接作为下一个智能体的输入，按顺序依次传递。 - -## Core Principle -每个智能体的完整输出（而非摘要）成为下一个智能体的输入，确保信息完整性和上下文连贯性。 - -## Workflow Pattern -``` -Agent A → [完整输出] → Agent B → [完整输出] → Agent C -``` - -## Key Rules -- **不摘要，只复制粘贴**：不要总结上一智能体的输出，直接使用完整输出 -- **保持完整性**：确保所有上下文、细节、证据都传递给下一个智能体 -- **按顺序执行**：必须等待前一个智能体完成后才能启动下一个 - -## Example -在 Multi-Agent Workflow: Startup MVP 中： -1. Sprint Prioritizer 完成冲刺计划 -2. 完整计划直接传给 Backend Architect -3. Backend Architect 完整输出传给 Frontend Developer - -## Advantages -- 最大化信息保留 -- 减少上下文丢失 -- 便于追溯和审计 - -## Disadvantages -- 可能增加处理时间 -- 需要更多上下文窗口 -- 顺序执行无法并行加速 - -## Related Concepts -- [[Parallel Work]]：并行工作模式 -- [[Quality Gates]]：质量门控 -- [[Context Passing]]：上下文传递 -- [[Multi-Agent Team]]：多智能体团队 diff --git a/wiki/concepts/Sequential-Thinking.md b/wiki/concepts/Sequential-Thinking.md deleted file mode 100644 index 30d527fc..00000000 --- a/wiki/concepts/Sequential-Thinking.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: "Sequential Thinking" -type: concept -tags: [ai, thinking, mcp] -date: 2026-04-17 ---- - -## Definition -Sequential Thinking 是 MCP 工具之一，支持逻辑推理与分步执行任务，优化 AI 模型的思考与响应过程。 - -## Features -- 逻辑推理分步拆解任务 -- 能够提升 AI 沟通效率 -- 可与其他 MCP 工具相互调用、协同工作 - -## Use Cases -- 复杂任务的系统思考 -- AI 决策质量提升 -- 多工具协同工作场景 - -## Connections -- 作为 MCP 工具与 [[MCP]] 协议配合使用 -- 适用于 [[Agentic AI]] 应用场景 diff --git a/wiki/concepts/Server-Side-Tagging.md b/wiki/concepts/Server-Side-Tagging.md deleted file mode 100644 index ebd02665..00000000 --- a/wiki/concepts/Server-Side-Tagging.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: "Server-Side Tagging" -type: concept -tags: [Tracking, Measurement, GTM, Privacy] ---- - -## Definition -服务端标记是一种将追踪标签从客户端（浏览器）转移到服务器端执行的追踪架构，通过 GTM Server-Side Container 实现第一方数据收集、Cookie 管理和数据富化。 - -## Core Components -- **GTM Server-Side Container**：部署在云函数或服务器上的标记容器 -- **First-Party Data Collection**：使用第一方域名收集数据，避免第三方 Cookie 限制 -- **Cookie Management**：服务端 Cookie 管理，提升数据持久性 -- **Server-Side Enrichment**：在服务端添加额外参数后再发送给第三方平台 - -## Benefits -- 提升数据准确性：绕过广告拦截器 -- 增强隐私合规：更好的同意模式控制 -- 改善页面性能：减少客户端 JavaScript 负担 -- 数据控制：数据先经过服务端处理再发送 - -## Use Cases -- 跨域追踪 -- 转化去重（CAPI 与 Pixel 事件匹配） -- 增强型转化实施 -- 数据脱敏处理 - -## Related Concepts -- [[GTM]]：Google Tag Manager，标签管理平台 -- [[Conversion Tracking]]：转化追踪 -- [[Consent Mode]]：同意模式，隐私合规机制 - -## Related Entities -- [[Paid Media Tracking & Measurement Specialist]]：服务端标记实施专家 \ No newline at end of file diff --git a/wiki/concepts/Serverless-Application-Model.md b/wiki/concepts/Serverless-Application-Model.md deleted file mode 100644 index 4728cc57..00000000 --- a/wiki/concepts/Serverless-Application-Model.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: "Serverless Application Model" -type: concept -tags: - - AWS - - Serverless - - IaC - - SAM -date: 2024-09-03 ---- - -## Definition -Serverless Application Model（无服务器应用模型，SAM）是 AWS 提供的开源框架，用于简化无服务器应用的本地开发和部署。基于 CloudFormation，扩展了声明无服务器资源的简化的语法。 - -## Key Features -- SAM CLI： - - `sam init`：初始化项目 - - `sam build`：本地构建 - - `sam local`：本地运行和调试 - - `sam deploy`：部署到 AWS -- 模板简化：相比 CloudFormation 更简洁的语法 -- 本地测试：支持本地调用 Lambda 和 Step Functions - -## SAM Template Structure -```yaml -AWSTemplateFormatVersion: '2010-09-09' -Transform: AWS::Serverless-2016-08-09 -Resources: - MyFunction: - Type: AWS::Serverless::Function - Properties: - Handler: index.handler - Runtime: nodejs18.x - Events: - Api: - Type: Api - Properties: - Path: /hello - Method: get -``` - -## Common Use Cases -- Lambda 函数部署 -- API Gateway 集成 -- Step Functions 工作流 -- 事件驱动架构 - -## Aliases -- AWS SAM -- SAM -- Serverless Application Model \ No newline at end of file diff --git a/wiki/concepts/Serverless-Computing.md b/wiki/concepts/Serverless-Computing.md deleted file mode 100644 index 6c77c205..00000000 --- a/wiki/concepts/Serverless-Computing.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: Serverless Computing -type: concept -tags: [Cloud, Serverless, FaaS] -sources: [The-Myths-and-Misconceptions-About-Cloud-Computing-LinkedIn.md] -last_updated: 2025-03-02 ---- - -## Definition -无服务器计算（Serverless Computing）是一种云计算执行模型，开发者无需管理服务器即可运行代码，按实际执行时间计费。 - -## Core Features -- 无服务器管理：无需配置、维护或扩展服务器 -- 细粒度计费：仅按实际计算时间计费 -- 事件驱动：响应事件自动触发执行 -- 弹性扩展：自动处理任意规模的请求 - -## Key Claims -- 无服务器计算是降低云成本的关键策略之一 -- 开发者无需管理底层基础设施即可运行代码 - -## Connections -- [[Pay-as-you-go]] ← finest_grain ← [[Serverless-Computing]]：无服务器是最细粒度的按需付费 -- [[PaaS]] ← evolves_to ← [[Serverless-Computing]]：无服务器是 PaaS 的演进方向 -- [[Cloud-Native]] ← uses ← [[Serverless-Computing]]：云原生应用常用无服务器架构 diff --git a/wiki/concepts/Service-Catalog.md b/wiki/concepts/Service-Catalog.md deleted file mode 100644 index 34ea0971..00000000 --- a/wiki/concepts/Service-Catalog.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -id: Service-Catalog -title: "Service Catalog" -type: concept -tags: - - DevOps - - IaC - - Terraform - - Landing-Zone -last_updated: 2026-04-19 ---- - -## Aliases -- Service Catalog -- 服务目录 - -## Summary -- **定义**：封装业务需求的基础设施模块分组，提供服务级别抽象 -- **用途**：跨团队、跨账户复用基础设施配置，实现独立发布周期 -- **云迁移价值**：通过分层抽象实现基础设施即服务模式 - -## Key Details -- **分层结构**： - - Terraform Service Catalog：全局共享，供所有产品团队使用 - - Product Team Service Catalog：团队内部复用 - - Account-level Module：单账户使用 -- **Service vs Module**： - - Service：业务需求封装，部署一组 Module - - Module：技术需求实现，单一功能单元 - - 层级越高，配置选项越少（类似面向对象抽象） -- **版本化管理**： - - 使用语义化版本（major.minor.patch） - - Terragrunt targeting 特定版本而非 master 分支 - - 避免意外变更引入生产环境 - -## Key Components -- **main.tf**：定义模块引用和依赖关系 -- **terragrunt.hcl**：目标版本和输入变量配置 -- **outputs**：跨服务依赖值传递 - -## Connections -- [[Terraform]] ← uses ← [[Service-Catalog]] -- [[TerraGrunt]] ← references ← [[Service-Catalog]] -- [[Module]] ← contained_by ← [[Service-Catalog]] -- [[Landing-Zone]] ← managed_by ← [[Service-Catalog]] \ No newline at end of file diff --git a/wiki/concepts/Service-Control-Policies.md b/wiki/concepts/Service-Control-Policies.md deleted file mode 100644 index 38f4e9dd..00000000 --- a/wiki/concepts/Service-Control-Policies.md +++ /dev/null @@ -1,52 +0,0 @@ ---- -id: service-control-policies -title: "Service Control Policies (SCPs)" -type: concept -tags: - - AWS - - Policy - - Governance -last_updated: 2026-04-18 ---- - -## Summary -AWS Organizations 的策略类型之一，用于集中管理组织内所有账户的最大可用权限。 - -## Definition -Service Control Policies (SCPs) 是 AWS Organizations 的一种策略类型，用于设置组织内所有账户的最大权限边界。它们不允许授予权限，而是限制可用的权限范围。 - -## Key Attributes -- **类型**：组织策略 -- **作用域**：组织单元（OU）或单个账户 -- **效果**：Allow（允许）或 Deny（拒绝） -- **优先级**：仅拒绝（Deny）策略优先于 Allow 策略 - -## Use Cases -- 实施标签规范，阻止创建不带标签的 EC2 实例 -- 限制特定区域的资源部署 -- 防止删除关键资源（如 CloudTrail、VPC Flow Logs） - -## Examples -```json -{ - "Version": "2012-10-17", - "Statement": [ - { - "Effect": "Deny", - "Action": [ - "ec2:RunInstances" - ], - "Resource": ["arn:aws:ec2:*:*:instance/*"], - "Condition": { - "StringEquals": { - "aws:RequestTag/CostCenter": "absent" - } - } - } - ] -} -``` - -## Related Concepts -- [[Multi-Account Strategy]]：SCPs 是多账号策略的一部分 -- [[Gruntwork Landing Zone]]：Gruntwork Landing Zone 使用 SCPs 实施治理 \ No newline at end of file diff --git a/wiki/concepts/Shared-Responsibility-Model.md b/wiki/concepts/Shared-Responsibility-Model.md deleted file mode 100644 index 2e2087ea..00000000 --- a/wiki/concepts/Shared-Responsibility-Model.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: "Shared Responsibility Model" -type: concept -tags: [Cloud, Security, Governance] -sources: [Public-vs-Private-vs-Hybrid-Cloud-Differences-Explained] -last_updated: 2025-06-18 ---- - -## Summary -Shared Responsibility Model（共享责任模型）是一种明确云服务提供商与客户之间安全和管理职责分工的框架。 - -## Definition -共享责任模型定义了云服务提供商和客户在云环境中的各自职责。无论选择哪种云部署模式（公有云、私有云或混合云），客户仍需对某些方面承担最终责任。该模型强调虽然云服务商负责基础设施运营，但客户仍需管理访问权限、数据安全和灾难恢复。 - -## Responsibilities Matrix - -### 云服务商负责 -- 基础设施运营和维护 -- 物理服务器安全 -- 服务器硬件维护 -- 底层虚拟化层 -- 网络基础设施 - -### 客户负责 -- 身份和访问管理（IAM） -- 数据分类和保护 -- 应用程序安全 -- 加密策略和实施 -- 灾难恢复计划 -- 合规性管理 -- 终端用户安全 - -## Key Takeaways -- 选择云模式不免除客户的安全责任 -- 数据泄露往往发生在客户管理的层面 -- 明确的职责划分是安全云采用的基础 -- 客户必须了解并实施适当的安全控制 - -## Connections -- [[Shared-Responsibility-Model]] ← applies_to ← [[Public-Cloud]] -- [[Shared-Responsibility-Model]] ← applies_to ← [[Private-Cloud]] -- [[Shared-Responsibility-Model]] ← applies_to ← [[Hybrid-Cloud]] -- [[Shared-Responsibility-Model]] ← requires ← [[Cloud-Security]] -- [[Shared-Responsibility-Model]] ← part_of ← [[Cloud-Governance]] diff --git a/wiki/concepts/Shell.md b/wiki/concepts/Shell.md deleted file mode 100644 index 25536379..00000000 --- a/wiki/concepts/Shell.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: "Shell" -type: concept -tags: [linux, shell] -sources: ["raw/Home Office/Linux 运维必会的 150 个命令.md"] -last_updated: 2026-04-16 ---- - -## Definition -Shell（命令解释器）是 Linux 系统的用户界面，负责解释和执行用户输入的命令。它作为用户与内核之间的桥梁，将用户的命令转换为系统调用。 - -## Common Types -- **Bash**：最常用的 Shell，Linux 默认 -- **Zsh**：功能强大的增强版 Shell -- **Fish**：用户友好的交互式 Shell - -## Related Commands -- help：查看内置命令帮助 -- type：判断命令是否为内置命令 -- alias：设置命令别名 -- unalias：取消命令别名 \ No newline at end of file diff --git a/wiki/concepts/Shift-Right.md b/wiki/concepts/Shift-Right.md deleted file mode 100644 index 2014db83..00000000 --- a/wiki/concepts/Shift-Right.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: "Shift Right" -type: concept -tags: [devops, security, testing] -sources: [what-is-devsecops-best-practices-benefits-and-tools] -last_updated: 2026-04-20 ---- - -## Definition -"Shift Right" 强调在应用发布后持续进行安全监控和测试。即使开发阶段进行了全面的安全测试，某些漏洞可能只有在上线后被用户使用时才会被发现。 - -## Core Principles -- **持续监控**：上线后持续监控系统安全状态 -- **生产环境测试**：在真实环境中发现测试环境无法覆盖的漏洞 -- **快速响应**：发现漏洞后快速修复并发布补丁 -- **用户反馈**：利用用户报告识别潜在安全问题 - -## Relationship with Shift Left -- Shift Left：在开发早期阶段融入安全测试 -- Shift Right：在发布后持续安全监控 -- 两者结合实现全生命周期安全保障 - -## Connections -- [[DevSecOps]] ← requires ← [[Shift Right]] -- [[监控可观测性]] ← enables ← [[Shift Right]] -- [[Shift Left]] ← complements ← [[Shift Right]] \ No newline at end of file diff --git a/wiki/concepts/Show-Notes.md b/wiki/concepts/Show-Notes.md deleted file mode 100644 index 9ae829c2..00000000 --- a/wiki/concepts/Show-Notes.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: "Show Notes" -type: concept -tags: [podcast, content, metadata] ---- - -## Definition -带有时间戳的节目笔记，帮助听众快速定位感兴趣的内容段落。通常在录制完成后由 AI 根据 transcript 自动生成。 - -## Key Components -- 时间戳：每个主题切换点的精确时间标记 -- 一句话摘要：每个时间戳对应的内容概述 -- 相关链接：节目中提到的工具、书籍、文章、人物等资源链接 - -## Value -- 听众留存工具：帮助听众快速找到感兴趣的内容 -- SEO 优化：搜索引擎可索引的文本内容 -- 大多数播客制作者因繁琐而跳过，自动化价值高 - -## Related Concepts -- [[Pre-Recording Research]] -- [[Agent-Chain]] -- [[Social Media Kit]] - -## Related Sources -- [[podcast-production-pipeline]] \ No newline at end of file diff --git a/wiki/concepts/SkillToolset.md b/wiki/concepts/SkillToolset.md deleted file mode 100644 index f0091c8c..00000000 --- a/wiki/concepts/SkillToolset.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -id: skill-toolset -title: "SkillToolset" -type: concept -tags: [Agent, ADK, 工具集] -sources: [Google-5-Agent-Skill-design-patterns-2026-03-19] -last_updated: 2026-04-17 ---- - -## Summary -ADK（Agent Development Kit）提供的 skill 工具集，支持按需加载和动态组合不同的 skill 模式。 - -## Definition -SkillToolset 是 Google ADK 中的组件，提供一组标准化的 skill 加载和组合机制，支持渐进式披露、动态加载和模式复用。 - -## Components -- **动态加载器**：根据运行时上下文按需加载 skill -- **模式组合器**：支持多种模式（Tool Wrapper、Generator、Reviewer、Inversion、Pipeline）自由组合 -- **上下文管理器**：管理 skill 生命周期和 token 消耗优化 - -## Related Concepts -- [[渐进式披露]]：SkillToolset 实现的核心优化策略 -- [[Tool Wrapper]]、[[Generator]]、[[Reviewer]]、[[Inversion]]、[[Pipeline]]：可组合的 5 种模式 \ No newline at end of file diff --git a/wiki/concepts/Smart-City.md b/wiki/concepts/Smart-City.md deleted file mode 100644 index 2192b81b..00000000 --- a/wiki/concepts/Smart-City.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: "Smart City" -type: concept -tags: [government, urban-infrastructure, data-platform] -last_updated: 2026-04-20 ---- - -## Definition -Smart City 指将城市运行、公共服务、交通、社区治理和应急联动等能力数字化、平台化和智能化的城市治理模式。 - -## Core Dimensions -- 城市运行中心 / IOC -- 城市级数据平台与感知网络 -- 智能交通、智慧社区、应急指挥 -- 可视化大屏、联动闭环与指标体系 - -## Related Concepts -- [[Digital Government]] -- [[Government Procurement]] -- [[Technical Discovery]] -- [[Proof of Concept (POC)]] -- [[Solution Architecture (SA)]] - -## Related Entities -- [[Government Digital Presales Consultant]] -- [[The Agency]] diff --git a/wiki/concepts/Social-Identity-Theory.md b/wiki/concepts/Social-Identity-Theory.md deleted file mode 100644 index 645a9fbe..00000000 --- a/wiki/concepts/Social-Identity-Theory.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: "Social Identity Theory" -type: concept -tags: [social-psychology, group-psychology, tajfel] -sources: [] -last_updated: 2026-04-20 ---- - -# Social Identity Theory - -## Aliases -- 社会认同理论 -- Social Identity Approach -- SIT - -## Summary -Henri Tajfel 和 John Turner 提出的社会心理学理论，解释个体如何通过群体成员身份形成自我概念，以及群体间偏见和歧视的心理根源。 - -## Core Concepts - -### 社会认同（Social Identity） -个体自我概念的一部分，来源于群体成员身份： -- **内群体（In-group）**：个体所属并产生认同感的群体 -- **外群体（Out-group）**：被感知为与内群体不同或对立的群体 - -### 心理机制 -- **社会分类（Social Categorization）**：将世界分为群体类别 -- **社会认同（Social Identification）**：接受群体规范并内化为自我概念 -- **社会比较（Social Comparison）**：通过与外群体比较提升自尊 - -### 内群体偏差（In-Group Bias） -- 给予内群体成员更多资源或正面评价 -- 倾向于以负面方式描述外群体 - -### 现实冲突理论（Realistic Conflict Theory）** -群体间偏见的另一机制：当群体间存在真实资源竞争时，偏见加剧。 - -## Applications -- [[Academic Psychologist Agent]] 理解群体动力学 -- 分析群体情境中的角色行为 -- 评估群体对个体决策的影响 - -## Connections -- [[Academic Psychologist Agent]] ← 分析框架 ← [[Social Identity Theory]] -- [[Henri Tajfel]] ← 创始人 ← [[Social Identity Theory]] -- [[Groupthink]] ← 相关概念 ← [[Social Identity Theory]] diff --git a/wiki/concepts/Social-Media-Analytics.md b/wiki/concepts/Social-Media-Analytics.md deleted file mode 100644 index 21ff2499..00000000 --- a/wiki/concepts/Social-Media-Analytics.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "Social Media Analytics" -type: concept -tags: [marketing, analytics, performance] ---- - -## Definition -跨平台绩效分析和归因建模方法论，通过数据驱动的洞察优化社交媒体策略和投资回报率。 - -## Analytics Framework -- **Platform Analytics**: 各平台原生分析工具审查 -- **Cross-Platform Dashboards**: 统一报告覆盖触达、参与度和转化 -- **A/B Testing**: 内容格式、时间和消息优化 -- **Competitive Benchmarking**: 份额和表现 vs 行业同行 - -## Key Metrics -- LinkedIn Engagement Rate: 3%+ (公司页面), 5%+ (个人品牌) -- Cross-Platform Reach: 20% 月度增长 -- Content Performance: 50%+ 达到基准 -- Campaign ROI: 3x+ 回报 - -## Related Concepts -- [[Cross-Platform Strategy]] -- [[B2B Social Selling]] - -## Source -- [[Social Media Strategist]] \ No newline at end of file diff --git a/wiki/concepts/Social-Media-Kit.md b/wiki/concepts/Social-Media-Kit.md deleted file mode 100644 index 6daf5343..00000000 --- a/wiki/concepts/Social-Media-Kit.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "Social Media Kit" -type: concept -tags: [podcast, social-media, automation] ---- - -## Definition -为每集播客生成的多平台宣传素材包，包括 X/Twitter、LinkedIn、Instagram 等平台的定制内容。 - -## Key Components -- X/Twitter：3 条推文（一句引用、一个关键洞察、一个讨论问题） -- LinkedIn：1 篇专业风格长文（100-150 字） -- Instagram：1 条带表情和话题标签的图文caption -- 高光时刻列表：3 个最有趣的瞬间及时间戳 - -## Value -- 节省最多重复性时间：每集都需要宣传，结构固定适合自动化 -- 一次制作多次分发：同一素材适配不同平台风格 -- 提升播客曝光率和听众增长 - -## Related Concepts -- [[Agent-Chain]] -- [[Show Notes]] -- [[内容矩阵]] - -## Related Sources -- [[podcast-production-pipeline]] \ No newline at end of file diff --git a/wiki/concepts/Socket-Activation.md b/wiki/concepts/Socket-Activation.md deleted file mode 100644 index 9636726e..00000000 --- a/wiki/concepts/Socket-Activation.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: "Socket Activation" -type: concept -tags: [systemd, activation, optimization] -date: 2026-04-16 ---- - -## Definition -Socket Activation（套接字激活）是 systemd 的一种按需启动机制，只有当客户端首次请求连接时，服务才会被启动。与传统的开机自启相比，可以减少系统资源占用。 - -## Mechanism -1. systemd 创建监听套接字 -2. 客户端发起连接请求 -3. systemd 接收连接并启动服务进程 -4. 连接传递给已启动的服务 - -## Use Cases -- SSH（ssh.socket） -- D-Bus 系统消息总线 -- 打印服务（cups.socket） - -## Advantages -- 减少内存占用 -- 按需启动，节能 -- 简化服务依赖管理 - -## Comparison with Traditional Mode -| 特性 | Socket Activation | 传统开机自启 | -|------|------------------|-------------| -| 启动时机 | 按需启动 | 开机启动 | -| 资源占用 | 低 | 常驻内存 | -| 响应速度 | 首次延迟 | 即时响应 | - -## Example -```bash -# 启用 socket 激活（默认） -sudo systemctl enable ssh.socket - -# 切换回传统模式 -sudo systemctl disable ssh.socket -sudo systemctl enable ssh.service -``` - -## Connections -- [[systemd]] ← implements ← [[Socket Activation]] -- [[SSH]] ← uses ← [[Socket Activation]] \ No newline at end of file diff --git a/wiki/concepts/Solution-Architecture-SA.md b/wiki/concepts/Solution-Architecture-SA.md deleted file mode 100644 index 01c03705..00000000 --- a/wiki/concepts/Solution-Architecture-SA.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -id: solution-architecture-sa -title: "Solution Architecture (SA)" -type: concept -tags: - - Technical-Architecture - - Cloud-Architecture ---- - -## Definition -方案架构（Solution Architecture，SA）是架构体系的中间层，专注于特定项目或服务的优化实施，确保系统组件间的高效协作。 - -## Position in Architecture Hierarchy -- **企业架构（Enterprise Architecture, EA）**：高层，负责将业务目标转化为技术原则和标准 -- **方案架构（Solution Architecture, SA）**：中间层，负责特定项目或服务的优化实施 -- **技术架构（Technical Architecture, TA）**：底层，负责具体基础设施的设计和实施治理 - -## Responsibilities -- 负责中间件与服务优化 -- 确保系统组件间的高效协作 -- 特定项目或服务的架构设计 - -## Related Concepts -- [[Enterprise-Architecture-EA]] -- [[Technical-Architecture-TA]] - ---- - -*最后更新: 2026-04-19* \ No newline at end of file diff --git a/wiki/concepts/Spatial-AI-Operations.md b/wiki/concepts/Spatial-AI-Operations.md deleted file mode 100644 index ad2b8ea8..00000000 --- a/wiki/concepts/Spatial-AI-Operations.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "Spatial AI Operations (SpatialAIOps)" -type: concept -tags: [ai-ops, spatial-computing, product-category] -date: 2026-03-05 ---- - -## Definition -Spatial AI Operations（空间人工智能运维）是由 Nexus Spatial 创建的新产品类别，将 AI agent 工作流编排和监控从扁平 2D 仪表盘扩展到沉浸式 3D 空间。 - -## Core Principles -- 空间感知：AI 操作如同" inhabiting your infrastructure" -- 可视化深度：3D node graphs 替代扁平拓扑 -- 协作临场感：团队成员共享 3D 空间进行实时协作 - -## Category Creation -不同于现有"AI observability dashboard"（LangSmith、Langflow），SpatialAIOps 定义了新品类： -- AI-focused + Spatial-first -- 竞品要么是空间但非 AI，要么是 AI 但非空间 - -## Related Concepts -- [[Multi-Agent Orchestration]]：核心技术 -- [[2D-First Spatial-Second]]：产品策略 -- [[Progressive Disclosure]]：用户体验原则 - -## Related Entities -- [[Nexus Spatial]]：品类定义产品 diff --git a/wiki/concepts/Spatial-Computing.md b/wiki/concepts/Spatial-Computing.md deleted file mode 100644 index 56222e01..00000000 --- a/wiki/concepts/Spatial-Computing.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: "Spatial Computing" -type: concept -tags: [xr, spatial-computing, computing-paradigm] -date: 2026-04-20 ---- - -## Definition -空间计算是一种计算范式，通过将数字内容与物理空间无缝融合，使用户能够与计算机生成的环境进行自然交互。 - -## Core Attributes -- 空间感知与映射 -- 自然用户交互 -- 数字与物理融合 -- 沉浸式体验 - -## Related Concepts -- [[WebXR]]：技术实现 -- [[Immersive-Cockpit]]：应用场景 -- [[Motion Sickness Threshold]]：设计约束 - -## Related Entities -- [[Vision Pro]]：Apple 空间计算设备 -- [[Meta Quest]]：Meta VR 设备 -- [[HoloLens]]：Microsoft AR 设备 - -## Application -XR 应用开发、空间界面设计、沉浸式培训、数字孪生 \ No newline at end of file diff --git a/wiki/concepts/Spatial-Controls.md b/wiki/concepts/Spatial-Controls.md deleted file mode 100644 index f5aab7e5..00000000 --- a/wiki/concepts/Spatial-Controls.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: "Spatial Controls" -type: concept -tags: [xr, spatial-computing, ux] -date: 2026-04-20 ---- - -## Definition -空间控件，3D 环境中的人体工程学操作界面，包括操纵杆、杠杆、油门等手交互控件。 - -## Core Attributes -- 3D 网格构建 -- 输入约束机制 -- 自然交互反馈 - -## Related Concepts -- [[Immersive Cockpit]]：应用场景 -- [[Multi-Input UX]]：多模态输入方式 - -## Application -XR 座舱控制、游戏手柄、虚拟现实操纵界面 \ No newline at end of file diff --git a/wiki/concepts/Spatial-Widgets.md b/wiki/concepts/Spatial-Widgets.md deleted file mode 100644 index b4b93a09..00000000 --- a/wiki/concepts/Spatial-Widgets.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "Spatial Widgets" -type: concept -tags: [visionOS, widgets, spatial-computing, ui] ---- - -## 定义 -visionOS 26 的小组件系统，能够集成到 3D 空间中，可吸附到墙壁和桌子并持久放置。 - -## 核心特性 -- 3D 空间集成 -- 表面吸附（墙壁、桌子） -- 持久放置 -- 实时更新 - -## 应用场景 -- 信息展示 -- 快捷操作 -- 实时数据 -- 状态监控 - -## 相关实体 -- [[visionOS]] -- [[visionOS Spatial Engineer]] \ No newline at end of file diff --git a/wiki/concepts/Spend-Limit.md b/wiki/concepts/Spend-Limit.md deleted file mode 100644 index 0393506f..00000000 --- a/wiki/concepts/Spend-Limit.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: "Spend Limit" -type: concept -tags: [finance, risk, governance] -sources: [accounts-payable-agent] -last_updated: 2026-04-20 ---- - -## Definition -Spend Limit 是允许智能体或系统在无需额外批准的情况下执行的最大支出额度。 - -## Core Principles -- 超过阈值的支付必须升级审批 -- 阈值应与角色权限、风险和业务场景匹配 -- 限额策略应明确、可审计、可调整 -- 支出限额应与防重机制一起使用 - -## Related Entities -- [[Accounts Payable Agent]] -- [[The Agency]] diff --git a/wiki/concepts/Spot-Interruption.md b/wiki/concepts/Spot-Interruption.md deleted file mode 100644 index 5859611e..00000000 --- a/wiki/concepts/Spot-Interruption.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: "Spot Interruption" -type: concept -tags: [AWS, EC2, Cost-Optimization, High-Availability] -sources: [] -last_updated: 2026-04-19 ---- - -## Definition -Spot Interruption 是 AWS EC2 Spot 实例的中断处理机制，Karpenter 原生集成 EventBridge 和 SQS 实现自动处理。 - -## Mechanism -- **通知来源**：EventBridge 发送 Spot 中断、实例重平衡、健康事件、实例状态变更通知 -- **处理方式**：Karpenter 监听 SQS 队列，自动将工作负载迁移到其他实例 -- **无需额外组件**：Karpenter 原生支持，与 Node Termination Handler 不同 - -## Benefits -- 降低 Spot 实例使用成本（可达 90% 折扣） -- 自动处理中断，提高工作负载可用性 -- 简化架构，无需额外管理组件 - -## Related Concepts -- [[Karpenter]]：原生支持 Spot 中断处理 -- [[EventBridge]]：AWS 事件总线服务 -- [[SQS]]：AWS 简单队列服务 - -## Aliases -- Spot Interruption Handling -- Spot Instance Interruption \ No newline at end of file diff --git a/wiki/concepts/Sprint-Health-Snapshot.md b/wiki/concepts/Sprint-Health-Snapshot.md deleted file mode 100644 index 52bda989..00000000 --- a/wiki/concepts/Sprint-Health-Snapshot.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: "Sprint Health Snapshot" -type: concept -tags: [product-management, agile, sprint] -sources: [product-manager.md] -last_updated: 2026-04-20 ---- - -## Definition -冲刺健康快照是追踪单个冲刺状态的定期文档，记录承诺 vs 交付、阻塞、范围变更和进入下个冲刺的风险。 - -## Structure -1. **Committed vs Delivered**：故事、点数、状态、阻塞 -2. **Velocity**：承诺 pts / 交付 pts（完成率）+ 3 周期滚动平均 -3. **Blockers & Actions**：阻塞表（阻塞、影响、负责人、解决 ETA） -4. **Scope Changes This Sprint**：变更请求表（请求、来源、决策、理由） -5. **Risks Entering Next Sprint**：进入下个冲刺的风险 - -## Key Metrics -| Metric | Description | -|--------|-------------| -| Velocity | 承诺 vs 交付完成率 | -| Blocker Age | 阻塞存在时间（>24h 是 PM 失败） | -| Scope Creep | 未经追踪的范围变更 | - -## Use Case -- sprint 结束时编写 -- 为下个 sprint planning 提供输入 -- 识别模式用于团队健康回顾 - -## Key Principle -- 零未追踪的 sprint 中期范围增加 -- 阻塞 > 24 小时未解决是 PM 失败 -- 范围变更必须正式评估和文档化 - -## Connection -- [[Product Manager Agent]] ← owns ← [[Sprint Health Snapshot]] -- [[Delivery Phase]] ← monitors ← [[Sprint Health Snapshot]] -- [[Roadmap (Now / Next / Later)]] ← updated_by ← [[Sprint Health Snapshot]] diff --git a/wiki/concepts/Sprint-Planning.md b/wiki/concepts/Sprint-Planning.md deleted file mode 100644 index 368bc152..00000000 --- a/wiki/concepts/Sprint-Planning.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: "Sprint Planning" -type: concept -tags: [agile, scrum, ceremony] -sources: [raw/Agent/agency-agents/product/product-sprint-prioritizer.md] -last_updated: 2026-04-20 ---- - -## Definition -敏捷开发中的核心仪式，定义 sprint 目标并选择可交付的故事。 - -## Process -### Pre-Sprint Planning（冲刺前一周） -1. Backlog Refinement：故事规模、验收标准、Done 定义审核 -2. Dependency Analysis：跨团队协调需求与时间线映射 -3. Capacity Assessment：团队可用性、假期、会议、培训评估 -4. Risk Identification：技术未知项、外部依赖缓解策略 -5. Stakeholder Review：优先级验证和范围对齐 - -### Sprint Planning（第一天） -1. Sprint Goal Definition：清晰可衡量的目标与成功标准 -2. Story Selection：基于容量的承诺，包含 15% 缓冲 -3. Task Breakdown：实施规划、估算与技能匹配 -4. Definition of Done：质量标准和自动化验收测试 -5. Commitment：团队对交付物和时间线的共识 - -## Related Concepts -- [[Team Velocity]] -- [[Capacity Planning]] -- [[RICE Framework]] -- [[Product Sprint Prioritizer]] diff --git a/wiki/concepts/Static-Analysis.md b/wiki/concepts/Static-Analysis.md deleted file mode 100644 index 5dc2dfcc..00000000 --- a/wiki/concepts/Static-Analysis.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "Static Analysis" -type: concept -tags: [smart-contract, security, tools] -sources: [blockchain-security-auditor] -last_updated: 2026-04-20 ---- - -## Definition -静态分析（Static Analysis）是通过分析代码结构而不执行程序来检测漏洞的方法，是智能合约安全审计的第一道防线。 - -## Tools in Ecosystem -- **Slither**：Trail of Bits 开发，Python 实现 -- **Mythril**：Consensys Diligence 开发，符号执行 -- **Medusa**：二进制模糊测试框架 -- **Semgrep**：通用代码分析工具 - -## Slither Detectors -| 严重级别 | 检测器 | -|---------|--------| -| High | reentrancy-eth, suicidal, controlled-delegatecall | -| Medium | reentrancy-benign, timestamp, low-level-calls | -| Low | naming-convention, unused-state | - -## Limitations -- 只能发现约 30% 的真实漏洞 -- 漏报率高（false negatives） -- 逻辑漏洞和经济漏洞难以发现 -- 依赖工具更新维护 - -## Best Practice -- 静态分析作为第一轮扫描 -- 人工审查作为主要手段 -- 属性测试补充验证 - -## Connections -- [[Formal Verification]] ← complements ← [[Static Analysis]] -- [[Slither]] ← implements ← [[Static Analysis]] -- [[Mythril]] ← implements ← [[Static Analysis]] - diff --git a/wiki/concepts/Statistical-Significance-Testing.md b/wiki/concepts/Statistical-Significance-Testing.md deleted file mode 100644 index 2230999e..00000000 --- a/wiki/concepts/Statistical-Significance-Testing.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: "Statistical Significance Testing" -type: concept -tags: [] -last_updated: 2026-04-21 ---- - -## Definition -统计显著性检验，用于验证分析结论是否具有统计意义，而非随机偶然。 - -## Key Principles -- P-value < 0.05：结果具有统计显著性 -- 95% 置信区间：标准置信水平 -- 样本量验证：确保样本量足够检测预期效应 -- 效应量（Effect Size）：实际显著性而非仅统计显著性 - -## Application in Analytics -- A/B 测试结果验证 -- 营销活动效果评估 -- 趋势识别确认 -- 预测模型准确性验证 - -## Related Concepts -- [[Data-Driven Decision Making]] - -## Source -- [[support-analytics-reporter]] - diff --git a/wiki/concepts/Statistical-Significance.md b/wiki/concepts/Statistical-Significance.md deleted file mode 100644 index 4def37c0..00000000 --- a/wiki/concepts/Statistical-Significance.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "Statistical Significance" -type: concept -tags: [statistics, experimentation] -sources: [project-management-experiment-tracker] -last_updated: 2026-04-20 ---- - -## Definition -Statistical Significance indicates that an observed effect is unlikely to have occurred by random chance under the null hypothesis, according to a predefined threshold. - -## Core Principles -- Define the alpha level before testing -- Distinguish significance from business impact -- Guard against multiple comparison inflation -- Report confidence intervals and effect sizes - -## Related Concepts -- [[Hypothesis Testing]] -- [[A/B Testing]] -- [[Power Analysis]] - -## Related Entities -- [[Experiment Tracker]] - diff --git a/wiki/concepts/Step-Functions.md b/wiki/concepts/Step-Functions.md deleted file mode 100644 index 415bfe15..00000000 --- a/wiki/concepts/Step-Functions.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "Step Functions" -type: concept -tags: - - AWS - - Serverless - - Orchestration - - Workflow -date: 2024-09-03 ---- - -## Definition -Step Functions（步进函数）是 AWS 无服务器工作流服务，基于状态机编排多个 AWS 服务的业务流程。通过可视化工作流协调分布式应用程序和微服务的组件。 - -## Two Flavors -- **Standard Workflows（标准工作流）**： - - 长期运行（最多 1 年） - - 精确一次执行 - - 每秒最多 2000 次执行 - -- **Express Workflows（快速工作流）**： - - 短期运行（最多 5 分钟） - - 至少一次执行 - - 每秒最多 100000 次执行 - - 面向事件驱动工作负载 - -## Key Concepts -- **State Machine（状态机）**：定义工作流逻辑的结构 -- **States（状态）**：工作流中的步骤，包括 Pass、Task、Choice、Wait、Parallel、Map 等 -- **Transitions（转换）**：状态之间的流向控制 - -## Use Cases -- 顺序处理：ETL 流程、数据处理 -- 并行处理：批量数据处理 -- 分支逻辑：条件分支处理 -- 人类审批：集成审批工作流 - -## Aliases -- AWS Step Functions -- Step Functions 状态机 \ No newline at end of file diff --git a/wiki/concepts/Story-Structure-Analysis.md b/wiki/concepts/Story-Structure-Analysis.md deleted file mode 100644 index 8a0f36b0..00000000 --- a/wiki/concepts/Story-Structure-Analysis.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "Story Structure Analysis" -type: concept -tags: [narrative-theory, story-structure, analysis] ---- - -## 定义 -系统化分析叙事作品结构的方法论，通过框架识别故事的组成元素和相互关系。 - -## 分析维度 -- **Controlling Idea**：故事论证的核心论点 -- **Structure Model**：适用的结构模型（三幕式、五幕式、英雄之旅、 Kishōtenketsu 等） -- **Act Breakdown**：各幕的 Setup、Confrontation、Resolution -- **Tension Curve**：关键张力峰值和谷值映射 -- **Information Asymmetry**：读者认知与角色认知的信息差 -- **Narrative Debts**：向读者做出的未兑现承诺 - -## 分析框架 -- [[Propp 叙事形态学]]：民间故事和 quest 结构 -- [[Campbell 英雄之旅]]：英雄叙事 -- [[McKee 故事结构]]：剧本结构 -- [[Todorov 均衡模型]]：基于 disruption 的情节 -- [[Genette 叙事学]]：叙事话语分析 -- [[Barthes 五代码]]：符号学分析 - -## 来源框架 -- [[Narratologist]] 的核心技术交付物 diff --git a/wiki/concepts/Strategic-Portfolio-Management.md b/wiki/concepts/Strategic-Portfolio-Management.md deleted file mode 100644 index a77dfa0f..00000000 --- a/wiki/concepts/Strategic-Portfolio-Management.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: "Strategic Portfolio Management" -type: concept -tags: [project-management, strategy] ---- - -## Definition -Strategic Portfolio Management is the practice of orchestrating multiple high-value projects with complex interdependencies and resource requirements to achieve organizational strategic objectives. - -## Core Principles -- Align creative excellence with business objectives and market opportunities -- Manage senior stakeholder relationships and executive-level communications -- Drive innovation strategy and competitive positioning through creative leadership -- Ensure 25% portfolio ROI with 95% on-time delivery - -## Key Activities -- Portfolio health monitoring and strategic course corrections -- Investment allocation across portfolio tiers (Tier 1: Strategic Priority, Tier 2: Growth Initiatives, Innovation Pipeline) -- Risk management and contingency planning -- Performance tracking against strategic objectives - -## Related Concepts -- [[Resource Allocation]] -- [[Cross-Functional Leadership]] -- [[Multi-Project Orchestration]] - -## Related Entities -- [[Studio Producer]] \ No newline at end of file diff --git a/wiki/concepts/Subagent-管理.md b/wiki/concepts/Subagent-管理.md deleted file mode 100644 index f1adb937..00000000 --- a/wiki/concepts/Subagent-管理.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: "Subagent 管理" -type: concept -tags: [] -sources: [] -last_updated: 2026-04-17 ---- - -## Definition -使用 sessions_spawn/sessions_send 管理子代理的技术，实现任务的分布式执行 - -## Methods -- sessions_spawn：创建新的子代理会话 -- sessions_send：向已有子代理发送消息 - -## Related Concepts -- [[去中心化协调]] -- [[Multi-Agent Team]] - -## Related Entities -- [[OpenClaw]] \ No newline at end of file diff --git a/wiki/concepts/Subscription.md b/wiki/concepts/Subscription.md deleted file mode 100644 index 9e75b0c7..00000000 --- a/wiki/concepts/Subscription.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: Subscription -type: concept -tags: [Azure, Isolation, Resource] -date: 2026-04-14 ---- - -## Definition -Azure Subscription（订阅）是 Azure 资源隔离的基本容器，每个订阅有独立的资源配额、计费账单和访问控制策略。在 Landing Zone 架构中，不同用途的工作负载使用独立的订阅实现隔离和管控。 - -## Key Characteristics -- 独立的资源配额（vCPU、存储等） -- 独立的计费账单 -- 独立的资源访问控制 -- 可绑定到不同的 Azure Active Directory 租户 - -## Common Subscription Types in Landing Zone -- **Platform Subscription**：平台服务（身份管理、连接） -- **Landing Zone Subscription**：工作负载部署 -- **Decommission Subscription**：退役资源存放 -- **Sandbox Subscription**：实验和测试环境 - -## Design Principles -- 每个订阅专注于特定用途 -- 实现故障隔离和资源管控 -- 最小化跨订阅依赖 -- 通过标签实现成本分摊 - -## Related Concepts -- [[Management Groups]]：组织多个订阅 -- [[Azure Landing Zone]]：多订阅架构 -- [[Terraform Cloud]]：跨订阅自动化管理 - -## Connections -- [[Subscription]] ← organized_by ← [[Management Groups]] -- [[Azure Landing Zone]] ← contains ← [[Subscription]] \ No newline at end of file diff --git a/wiki/concepts/Super-Topic-Community-Management.md b/wiki/concepts/Super-Topic-Community-Management.md deleted file mode 100644 index 7361a030..00000000 --- a/wiki/concepts/Super-Topic-Community-Management.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: "Super Topic Community Management" -type: concept -tags: [weibo, community, fandom, engagement] -last_updated: 2026-04-21 ---- - -## Definition -超级话题社区管理是通过创建和运营微博 Super Topic，构建品牌自有社区、培养核心粉丝的运营体系。 - -## Core Components -- **社区规则建立**：制定内容规范、行为准则、入群门槛 -- **内容审核机制**：维护社区秩序，防止负面内容扩散 -- **粉丝文化运营**：理解粉丝社区动力学，构建"粉丝俱乐部"式运营 - -## Fan Economy Operations -- **签到机制**：每日签到培养用户习惯，增强粘性 -- **榜单投票**：组织粉丝参与各类榜单投票，提升参与感 -- **协调评论**：引导粉丝在关键内容下统一发声 - -## Super Topic Events -- 站内主题活动 -- 抽奖互动 -- 粉丝共创挑战 - -## Celebrity Super Topic Strategy -- 代言人超级话题联动 -- 粉丝共创内容 -- 粉丝任务与激励体系 - -## Brand Super Topic Strategy -- 品牌自有社区构建 -- UGC 内容培育 -- 核心粉丝开发 -- 超级话题等级体系利用 - -## Connections -- [[Marketing Weibo Strategist]] → uses → [[Super Topic Community Management]] -- [[Fan Economy Operations]] ← part_of ← [[Super Topic Community Management]] \ No newline at end of file diff --git a/wiki/concepts/Superset-Dashboard.md b/wiki/concepts/Superset-Dashboard.md deleted file mode 100644 index 34a6186b..00000000 --- a/wiki/concepts/Superset-Dashboard.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: "Superset Dashboard" -type: concept -tags: [Apache-Superset, 数据可视化, BI] ---- - -## Definition -Apache Superset 数据可视化仪表盘，包含图表（Chart）、过滤器（Filter）、布局（Layout）的完整组合，用于展示和分析业务数据。 - -## Core Components -- **Chart（图表）**：数据可视化单元，如 Bar Chart、Scatter Plot、Heatmap、Table 等 -- **Filter（过滤器）**：交互式筛选器，支持 Category、Store Name、价格范围、时间范围等 -- **Layout（布局）**：仪表盘的页面结构安排，通常按行/列分布 - -## Use Cases -- 电商选品分析 Dashboard：展示热销产品、价格带分布、类目机会等 -- 竞争对手监控 Dashboard：展示店铺 GMV、销量排名、上新趋势等 -- 评论质量分析 Dashboard：展示评分趋势、评论数量、好评/差评占比等 - -## Related Concepts -- [[KPI-卡片]]：关键绩效指标展示组件 -- [[SQL-View]]：数据预处理视图 -- [[Apache-Superset]]：开源 BI 平台 \ No newline at end of file diff --git a/wiki/concepts/Supply-Chain-Security.md b/wiki/concepts/Supply-Chain-Security.md deleted file mode 100644 index 62845796..00000000 --- a/wiki/concepts/Supply-Chain-Security.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: "Supply Chain Security" -type: concept -tags: - - Security - - Supply-Chain - - CI/CD ---- - -## Definition -软件供应链安全，保护从开发到交付的全流程安全。包括源码管理（SCM）、构建组件（CI）、制品库到最终交付系统（CD）的所有环节的安全性。 - -## Key Components -- **开发环境安全**：开发人员工作站、IDE 安全 -- **源码管理（SCM）安全**：代码仓库访问控制、代码签名 -- **构建（CI）安全**：构建服务器安全、构建脚本验证、依赖检查 -- **制品库安全**：二进制文件完整性、签名验证 -- **交付（CD）安全**：交付渠道安全、版本验证 - -## Best Practices -- SBOM（Software Bill of Materials）：软件物料清单，记录所有依赖 -- 签名验证：所有构建产物必须经过数字签名 -- 安全扫描：构建过程中集成 SAST、 SCA、容器扫描 -- 最小权限：CI/CD 工具使用最小权限原则 - -## Related -- [[SolarWinds Hack]]：著名供应链攻击案例 -- [[CI/CD Security]]：持续集成与持续交付安全 -- [[SDL (Security Development Lifecycle)]]：软件安全开发生命周期 \ No newline at end of file diff --git a/wiki/concepts/Support-Analytics.md b/wiki/concepts/Support-Analytics.md deleted file mode 100644 index e5567a55..00000000 --- a/wiki/concepts/Support-Analytics.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -id: support-analytics -title: "Support Analytics" -type: concept -tags: [customer-service, analytics, metrics] -sources: [support-support-responder.md] -last_updated: 2026-04-21 ---- - -## Definition -支持分析（Support Analytics），客户支持团队的数据驱动性能监控和优化框架，计算响应时间、解决率、CSAT 等关键指标并识别改进机会。 - -## Key Metrics - -### Response Time Metrics -- **Average First Response Time**：从创建工单到首次响应平均耗时 -- **Average Resolution Time**：从创建到完全解决的平均耗时 -- **SLA Compliance Rate**：满足响应/解决 SLA 的百分比 - -### Quality Metrics -- **First Contact Resolution Rate**：首次联系解决百分比（目标 ≥ 80%） -- **Customer Satisfaction Score**：CSAT 平均分（目标 ≥ 4.5/5） -- **Ticket Volume by Channel**：各渠道工单分布 - -### Agent Performance -- **Tickets Handled**：单个 agent 处理工单数 -- **Average Resolution Time per Agent**：Agent 级平均解决时间 -- **CSAT Score per Agent**：Agent 级客户满意度 - -## Trend Analysis -- **Volume Trend**：日均工单量环比变化 -- **Top Issues**：高频问题分类统计 -- **Satisfaction Trend**：月度 CSAT 环比变化 -- **Response Time Trend**：周均响应时间环比变化 - -## Improvement Recommendations -基于数据分析的优化建议，优先级分类： -- **HIGH**：影响 SLA 或关键指标的改进 -- **MEDIUM**：效率提升机会 -- **LOW**：渐进优化 - -## Connections -- [[Support Responder]] — 分析数据的生成者 -- [[Customer Success]] — 分析驱动的主动干预目标 -- [[Knowledge Base Management]] — 分析揭示的知识缺口 \ No newline at end of file diff --git a/wiki/concepts/Support-Tiers.md b/wiki/concepts/Support-Tiers.md deleted file mode 100644 index d4b97579..00000000 --- a/wiki/concepts/Support-Tiers.md +++ /dev/null @@ -1,53 +0,0 @@ ---- -id: support-tiers -title: "Support Tiers" -type: concept -tags: [customer-service, support, escalation] -sources: [support-support-responder.md] -last_updated: 2026-04-21 ---- - -## Definition -支持层级（Support Tiers），分层客户服务架构，根据问题复杂度和客户类型将请求分配到不同专业级别的支持团队。 - -## Tier Structure - -### Tier 1 — General Support -**Capabilities**： -- Account Management：账户创建、修改、恢复 -- Basic Troubleshooting：常见问题诊断和解决 -- Product Information：产品功能和使用指导 -- Billing Inquiries：账单查询和基本计费问题 - -**Escalation Criteria**： -- 技术复杂度超出基础知识范围 -- 政策例外请求需要管理层批准 -- 客户表达不满且一线无法解决 - -### Tier 2 — Technical Support -**Capabilities**： -- Advanced Troubleshooting：复杂技术问题诊断 -- Integration Support：API 和系统集成支持 -- Custom Configuration：定制化配置指导 -- Bug Reproduction：问题复现和日志分析 - -**Escalation Criteria**： -- 需要工程团队介入的代码级别问题 -- 安全相关问题需要安全团队 -- 数据恢复需要 DBA 支持 - -### Tier 3 — Specialist Support -**Capabilities**： -- Enterprise Support：企业级客户专属支持 -- Custom Development：定制开发需求评估 -- Security Incidents：安全事件响应 -- Data Recovery：重大数据恢复操作 - -**Escalation Criteria**： -- C-Level 管理层涉及 -- 法律咨询需求 -- 需要产品团队深度协作 - -## Connections -- [[Multi-Channel Support Framework]] — 层级嵌入的框架 -- [[Support Responder]] — 层级执行的主体 \ No newline at end of file diff --git a/wiki/concepts/SwiftTerm.md b/wiki/concepts/SwiftTerm.md deleted file mode 100644 index e1df5d73..00000000 --- a/wiki/concepts/SwiftTerm.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: "SwiftTerm" -type: concept -tags: [swift, terminal, library, mit-license] ---- - -## 定义 -SwiftTerm 是用 Swift 编写的终端仿真库（MIT 许可证），为 macOS、iOS 和 visionOS 应用提供完整的终端仿真功能，是 The Agency 项目中 Terminal Integration Specialist 的核心技术栈。 - -## 核心特性 -- SwiftUI 深度集成 -- VT100/xterm 完整支持 -- UTF-8/Unicode 字符渲染 -- 文本选择和复制 -- 主题定制 - -## 技术栈 -- 渲染：Core Graphics、Core Text -- 输入：UIKit/AppKit 事件处理 -- 集成：SSH 流桥接（SwiftNIO SSH、NMSSH） - -## API 概览 -- SwiftUI View 组件 -- Input/Output Stream 处理 -- Theme 配置接口 -- Selection Handler - -## 相关资源 -- GitHub: https://github.com/migueldeicaza/SwiftTerm -- API Docs: https://migueldeicaza.github.io/SwiftTerm/ - -## 相关概念 -- [[Terminal Emulation]]：终端仿真基础 -- [[SSH Integration]]：SSH 集成模式 \ No newline at end of file diff --git a/wiki/concepts/Symbolic-Link.md b/wiki/concepts/Symbolic-Link.md deleted file mode 100644 index 77c5f49a..00000000 --- a/wiki/concepts/Symbolic-Link.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: "Symbolic Link" -type: concept -tags: [filesystem, macos, linux] -last_updated: 2025-01-14 ---- - -## Definition -符号链接（Symbolic Link，又称软链接）是一种特殊类型的文件，它包含指向另一个文件或目录的路径引用。符号链接类似于 Windows 中的快捷方式或 macOS 中的替身（Alias）。 - -## Technical Details -- 通过 `ln -s` 命令创建 -- 符号链接文件大小仅为目标路径的字节数 -- 删除符号链接不影响原始文件/目录 -- 可以跨文件系统创建 - -## Use Cases -- 将隐藏目录映射为可见目录（如 OpenClaw 的 ~/.openclaw → ~/openclaw） -- 在不同位置访问同一文件 -- 创建项目结构的符号链接以方便访问 - -## Commands -```bash -# 创建符号链接 -ln -s - -# 验证符号链接 -ls -l ~ | grep - -# 查看符号链接目标 -readlink - -# 删除符号链接（仅删除链接，不删除目标） -rm -``` - -## Related -- [[OpenClaw]] — 使用符号链接将隐藏目录映射为可见目录 -- [[Obsidian]] — 通过符号链接访问非标准路径的文件 \ No newline at end of file diff --git a/wiki/concepts/System-Resource-Monitoring.md b/wiki/concepts/System-Resource-Monitoring.md deleted file mode 100644 index d28e3a05..00000000 --- a/wiki/concepts/System-Resource-Monitoring.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: System Resource Monitoring -type: concept -tags: [system-administration, linux, observability] -sources: - - These 6 Linux apps let you monitor system resources in style -last_updated: 2025-12-16 ---- - -## Definition -系统资源监控，指对 CPU、内存、网络、存储等系统资源使用情况进行实时跟踪和可视化的行为。 - -## Monitoring Targets -- CPU 使用率和核心负载 -- 内存（RAM）使用情况 -- 网络流量和带宽 -- 存储（磁盘）使用率和 I/O -- 进程活动和管理 - -## Monitoring Tools -- TUI 类：Btop++、Htop、Glances、Bottom -- GUI 类：Mission Center、Stacer - -## Connections -- [[Btop++]] ← 监控工具 → [[System Resource Monitoring]] -- [[Htop]] ← 监控工具 → [[System Resource Monitoring]] -- [[Glances]] ← 监控工具 → [[System Resource Monitoring]] -- [[Bottom]] ← 监控工具 → [[System Resource Monitoring]] -- [[Mission Center]] ← 监控工具 → [[System Resource Monitoring]] -- [[Stacer]] ← 监控工具 → [[System Resource Monitoring]] -- [[Process Management]] ← 子领域 → [[System Resource Monitoring]] diff --git a/wiki/concepts/TAM-SAM-SOM.md b/wiki/concepts/TAM-SAM-SOM.md deleted file mode 100644 index bc10dc5f..00000000 --- a/wiki/concepts/TAM-SAM-SOM.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: "TAM/SAM/SOM" -type: concept -tags: [market-sizing, business-analysis] -sources: [raw/Agent/agency-agents/product/product-trend-researcher.md] -last_updated: 2026-04-20 ---- - -## Definition -TAM/SAM/SOM 是市场规模分析的三层模型，用于量化市场机会的大小和可实现性。 - -## Three Layers -- **TAM（Total Addressable Market）**：总可寻址市场，自顶向下和自底向上分析 -- **SAM（Serviceable Addressable Market）**：可服务市场，考虑地理和业务约束后的现实市场机会 -- **SOM（Serviceable Obtainable Market）**：可获得市场，通过竞争分析确定的可实现市场份额 - -## Analysis Methods -- Top-down Analysis：自顶向下，从宏观市场向下分解 -- Bottom-up Analysis：自底向上，从细分市场向上聚合 -- Validation：交叉验证确保准确性 diff --git a/wiki/concepts/TCO-Total-Cost-of-Ownership.md b/wiki/concepts/TCO-Total-Cost-of-Ownership.md deleted file mode 100644 index cec1998c..00000000 --- a/wiki/concepts/TCO-Total-Cost-of-Ownership.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: "TCO (Total Cost of Ownership)" -type: concept -tags: [cost-analysis, roi, tool-evaluation] -sources: [] -last_updated: 2026-04-21 ---- - -## Summary -总拥有成本（TCO）是一种综合成本分析方法，计算工具或系统的全生命周期成本，支持长期投资决策。 - -## Definition -TCO 包含以下成本组成部分： -- 许可费用（licensing） -- 实施成本（implementation） -- 培训成本（training） -- 维护成本（maintenance） -- 集成成本（integration） -- 迁移成本（migration） -- 支持成本（support） - -## Formula -``` -TCO = (年许可费 × 年数) + 实施费 + 培训费 + (年维护费 × 年数) + 集成费 + 迁移费 + (年支持费 × 年数) -``` - -## Application -- 工具选择决策 -- 预算规划 -- ROI 计算 -- 供应商比较 - -## Related Concepts -- [[Tool Evaluation Framework]] -- [[ROI Analysis]] -- [[Vendor Management]] diff --git a/wiki/concepts/TCO.md b/wiki/concepts/TCO.md deleted file mode 100644 index f268ac38..00000000 --- a/wiki/concepts/TCO.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: "TCO（全成本所有权）" -type: concept -tags: [supply-chain, procurement, cost-analysis] ---- - -## Definition -TCO（Total Cost of Ownership，全成本所有权）是一种采购决策框架，考虑采购项的完整成本，而非单一采购单价。 - -## Cost Components - -### 直接成本 -- 采购单价 -- 模具/夹具费 -- 包装费用 -- 运输费用 - -### 间接成本 -- 检验成本 -- 来料不良损失 -- 库存持有成本 -- 管理费用 - -### 隐藏成本 -- 供应商切换成本 -- 质量风险成本 -- 交期延误损失 -- 协调管理开销 - -### 全生命周期成本 -- 使用与维护成本 -- 处置与回收成本 -- 环境合规成本 - -## Application -- 供应商选择决策 -- 采购价格谈判基准 -- 供应商绩效评估维度 - -## Connections -- [[Supply Chain Strategist]] ← uses ← [[TCO（全成本所有权）]] -- [[Kraljic Matrix]] — TCO 常与 Kraljic Matrix 配合用于采购策略制定 - diff --git a/wiki/concepts/TJM-Brut.md b/wiki/concepts/TJM-Brut.md deleted file mode 100644 index a2dd708b..00000000 --- a/wiki/concepts/TJM-Brut.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: "TJM Brut" -type: concept -tags: [billing, france, rate] -date: 2026-04-20 ---- - -## Summary -总日均费率（Gross Daily Rate），ESN 向客户收取的日费率，也是计算净收入的基准。 - -## Definition -- **Full Name**: Taux Journalier Moyen Brut -- **Calculation**: 月费用 × 1.5 ÷ 18 可计费天数 = 最低可行 TJM -- **Rate Structure**: - - TJM Brut → Portage → ~50% net - - TJM Brut → Micro → ~70% net - -## Rate Negotiation Context -- ESN 以 TJM × 1.4-1.7 向客户收费 -- 如果知道客户预算，可以反推你的 TJM 上限 -- 锚定 15-20% 高于目标值，为谈判留出空间 - -## Connections -- [[Portage Salarial]] ← calculation_base -- [[Micro-Entrepreneur]] ← calculation_base -- [[French Consulting Market Navigator]] ← rate_benchmark diff --git a/wiki/concepts/TMUX-jiao-hu-mo-shi.md b/wiki/concepts/TMUX-jiao-hu-mo-shi.md deleted file mode 100644 index 39fd901f..00000000 --- a/wiki/concepts/TMUX-jiao-hu-mo-shi.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: "TMUX 交互模式" -type: concept -tags: [Claude Code, 工具调用] ---- - -## Definition -TMUX 交互模式是在 TMUX 会话中运行 Claude Code 的交互方式，适合超长任务，需要手动监控进度。 - -## Usage -```bash -# 创建 session 并直接进入 bypass 模式 -tmux new-session -d -s -x 140 -y 40 -tmux send-keys -t 'cd <项目目录> && claude --permission-mode bypassPermissions' Enter -sleep 8 && tmux capture-pane -t -p # 确认 Claude Code 已就绪 - -# 向 session 发送任务 -tmux send-keys -t '[任务描述]' Enter - -# 查看输出 -tmux capture-pane -t -p - -# 附加交互（可选） -tmux attach -t -``` - -## Use Cases -- 超长任务，需要长时间运行 -- 需要与 Claude Code 进行多轮交互 -- 需要实时查看执行进度 - -## Advantages -- 支持长时间运行 -- 可以随时查看输出 -- 可以附加交互 - -## Disadvantages -- 需要手动监控进度 -- 任务完成不会自动退出 - -## Related -- [[Print Mode]] -- [[Claude Code 调用方法总结]] \ No newline at end of file diff --git a/wiki/concepts/TOOLS.md b/wiki/concepts/TOOLS.md deleted file mode 100644 index 0856bb06..00000000 --- a/wiki/concepts/TOOLS.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: "TOOLS.md" -type: concept -tags: [OpenClaw, Agent] ---- - -## 定义 -TOOLS.md 是 OpenClaw workspace 中的工具权限声明与使用规范文件，定义 Agent 可用工具及其使用原则。 - -## 职责 -- 列出可用工具（Read/Write/Edit、Bash、Glob/Grep、sessions_spawn、memory_get/memory_search 等） -- 规定工具使用原则（优先使用文件操作工具、避免硬编码路径、批量修改前先确认内容） -- 明确受限工具（browser、文件删除操作需要用户授权） - -## 核心价值 -- **减少工具误用**：明确说明什么情况下不用某个工具 -- **降低权限越界风险**：把限制规则固化在 workspace 里 -- **与 openclaw.json 形成互补**：系统层决定"能不能用"，TOOLS.md 帮助理解"该不该用" - -## 典型结构 -```markdown -# TOOLS -## 可用工具 -- **Read / Write / Edit**：文件读写 -- **Bash**：执行 shell 命令 -- **Glob / Grep**：文件搜索 - -## 使用原则 -- 文件操作优先用 Read/Write/Edit，避免直接用 Bash 的 cat/echo -- 路径操作使用相对路径，不要硬编码绝对路径 - -## 受限工具 -- **browser**：网页浏览，只在用户明确要求时调用 -``` - -## 来源 -- [[万字讲透OpenClaw🦞从"能用"到"真好用"的分水岭：Workspace 深度解析]] - -## 相关 -- [[Workspace]]：包含 TOOLS.md 的工作台目录 -- [[AGENTS.md]]：与 TOOLS.md 配合定义 Agent 行为 \ No newline at end of file diff --git a/wiki/concepts/TTT.md b/wiki/concepts/TTT.md deleted file mode 100644 index 6178460f..00000000 --- a/wiki/concepts/TTT.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: "TTT" -type: concept -tags: [train-the-trainer, internal-trainer] -sources: [] -last_updated: 2026-04-20 ---- - -## Definition -Train the Trainer，内部培训师培养体系，将企业内部员工培养为合格讲师。 - -## Core Modules -- 成人学习原理 -- 课程开发技巧 -- 表达呈现技能 -- 课堂管理与互动 -- PPT 设计标准 - -## Trainer Development Path -试讲评审 → 基础认证 → 高级认证 → 金牌讲师 - -## Related Concepts -- [[ADDIE 模型]]：课程设计框架 diff --git a/wiki/concepts/TUI-Text-User-Interface.md b/wiki/concepts/TUI-Text-User-Interface.md deleted file mode 100644 index 0f1fa5cc..00000000 --- a/wiki/concepts/TUI-Text-User-Interface.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: TUI (Text User Interface) -type: concept -tags: [user-interface, terminal, linux] -sources: - - These 6 Linux apps let you monitor system resources in style -last_updated: 2025-12-16 ---- - -## Definition -文本用户界面（Text User Interface），基于终端文本显示的用户界面类型，区别于 GUI 的图形化界面。 - -## Key Features -- 响应迅速，即使在 GUI 卡顿情况下也能正常运行 -- 通过 SSH 远程访问友好 -- 键盘驱动操作 -- 资源占用低 -- 典型工具：Btop++、Htop、Glances、Bottom - -## Connections -- [[Btop++]] ← 使用 → [[TUI (Text User Interface)]] -- [[Htop]] ← 使用 → [[TUI (Text User Interface)]] -- [[Glances]] ← 使用 → [[TUI (Text User Interface)]] -- [[Bottom]] ← 使用 → [[TUI (Text User Interface)]] -- [[GUI]] ← 对比 → [[TUI (Text User Interface)]] diff --git a/wiki/concepts/TUI.md b/wiki/concepts/TUI.md deleted file mode 100644 index 0f2b5479..00000000 --- a/wiki/concepts/TUI.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: "TUI (Text User Interface)" -type: concept -tags: [Linux, 用户界面, 系统监控] -sources: ["https://www.howtogeek.com/these-linux-apps-let-you-monitor-system-resources-in-style/"] -last_updated: 2025-12-18 ---- - -## Definition -TUI（文本用户界面）是一种基于终端文本的界面类型，区别于 GUI（图形用户界面），通过键盘操作和终端输出进行交互。 - -## Key Characteristics -- 响应迅速，即使 GUI 卡顿也能正常运行 -- 可通过 SSH 远程访问 -- 资源占用低 -- 主要使用键盘操作 - -## Examples -- [[Btop++]] -- [[Htop]] -- [[Glances]] -- [[Bottom]] - -## Connections -- [[GUI]] ← 对比 → [[TUI (Text User Interface)]] -- [[SSH]] ← 远程访问 → [[TUI (Text User Interface)]] diff --git a/wiki/concepts/Tagging-Methodology.md b/wiki/concepts/Tagging-Methodology.md deleted file mode 100644 index a6f04fb8..00000000 --- a/wiki/concepts/Tagging-Methodology.md +++ /dev/null @@ -1,53 +0,0 @@ ---- -id: Tagging-Methodology -title: "Tagging Methodology" -type: concept -tags: - - AWS - - Tagging - - Security - - Automation -date_added: 2026-04-18 ---- - -## Definition -标签方法论，通过为资源定义标准化的元数据（如 Owner, BU, Product, Environment），作为自动化管理和安全策略执行的基础。 - -## Standard Tags -- **Owner:** 资源所有者 -- **BU (Business Unit):** 业务单元 -- **Product:** 产品线 -- **Environment:** 环境（dev, staging, prod） - -## Key Features -- 替代传统基于 IP 的防火墙规则 -- 支持动态的安全策略执行 -- 通过 SCP 的"显式拒绝"逻辑强制执行标签合规性 - -## Use Case -- 在 AWS Landing Zone 中实现基于标签的安全控制 -- 防止用户通过篡改标签绕过安全审计 - -## Related Concepts -- [[Service Control Policies]] -- [[Organizational Unit]] -- [[Checkpoint Firewall]] -- [[AWS Landing Zones]] - -## Related Entities -- [[AWS]] -- [[Gruntwork]] - -## OpenText Tagging Standard V2 -OpenText Tagging Standard V2 是标签方法论的具体实现，由 Phenops 团队于 2023 年发起，扩展了以下应用范围： -- 云账号 -- 云资源（计算、存储、网络） -- Kubernetes 对象（namespace、pod、deployment、service、configmap） -- 容器镜像 - -### 标签规范特点 -- 使用小写下划线语法（如 `ot_business_unit`） -- 前缀标签确保语义明确： - - OT_ 用于云标签 - - app.opentext.com 用于 Kubernetes 标签 - - com.opentext.image 用于容器镜像标签 \ No newline at end of file diff --git a/wiki/concepts/Talent-Assessment.md b/wiki/concepts/Talent-Assessment.md deleted file mode 100644 index b234303d..00000000 --- a/wiki/concepts/Talent-Assessment.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: "Talent Assessment" -type: concept -tags: [hr, recruiting, interview] -sources: [recruitment-specialist] -last_updated: 2026-04-20 ---- - -## Definition -Talent Assessment 是用结构化面试、行为面试、技术测试和评分卡评估候选人胜任力的过程。 - -## Core Principles -- 标准化评分卡，减少面试官偏差 -- 区分专业能力、通用能力与文化契合度 -- 用 STAR 方法追问真实行为 -- 让面试结论可比较、可追溯 - -## Related Entities -- [[Recruitment Specialist]] -- [[The Agency]] diff --git a/wiki/concepts/Task-Automation.md b/wiki/concepts/Task-Automation.md deleted file mode 100644 index 81dc4217..00000000 --- a/wiki/concepts/Task-Automation.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: "Task Automation" -type: concept -tags: [automation, productivity, workflow] ---- - -## Definition -自动将任务创建过程从手动操作转化为由系统或 AI Agent 执行的机制。核心价值在于消除人为遗忘和延迟，确保想法和决策及时转化为可执行任务。 - -## Use Cases -- 会议结束后自动提取行动项并创建任务 -- 邮件中识别待办事项并同步到任务管理工具 -- 社区讨论中提取任务并分配给负责人 - -## Related Concepts -- [[Workflow Automation]]：工作流自动化 -- [[上下文记忆]]：AI Agent 理解上下文的能力 -- [[Agentic AI]]：具备自主决策能力的 AI - -## Related Entities -- [[Jira]]：企业级任务管理 -- [[Linear]]：现代项目管理平台 -- [[Todoist]]：个人任务管理 -- [[Notion]]：全能笔记和任务管理 - -## Aliases -- Task Management Automation -- Automatic Task Creation \ No newline at end of file diff --git a/wiki/concepts/TaskListFormat.md b/wiki/concepts/TaskListFormat.md deleted file mode 100644 index ede6a3b5..00000000 --- a/wiki/concepts/TaskListFormat.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -title: "TaskListFormat" -type: concept -tags: [project-management, tasks] -sources: [project-manager-senior] -last_updated: 2026-04-20 ---- - -Describes the recommended structure for breaking specifications into development tasks: specification summary, technical stack, per-task description, acceptance criteria, files to create/edit, and references. Tasks should be small (30–60 minute devable) and include clear acceptance tests. diff --git a/wiki/concepts/Team-Velocity.md b/wiki/concepts/Team-Velocity.md deleted file mode 100644 index 8df3cd21..00000000 --- a/wiki/concepts/Team-Velocity.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "Team Velocity" -type: concept -tags: [agile, metrics, team-performance] -sources: [raw/Agent/agency-agents/product/product-sprint-prioritizer.md] -last_updated: 2026-04-20 ---- - -## Definition -团队在单个 sprint 中完成的故事点数量，用于衡量团队交付能力和进行未来容量规划。 - -## Key Metrics -- **历史数据**：6-sprint 滚动平均值，包含趋势分析和季节性调整 -- **Velocity Factors**：团队构成变化、复杂度变化、外部依赖 -- **Capacity Adjustment**：假期、培训、会议开销（通常 15-20%） -- **Buffer Management**：不确定缓冲（稳定团队 10-15%） - -## Target -- Sprint 间变化 <15% -- 呈现上升趋势 -- 90%+ 承诺故事点交付率 - -## Related Concepts -- [[Sprint Planning]] -- [[Capacity Planning]] -- [[RICE Framework]] -- [[Product Sprint Prioritizer]] diff --git a/wiki/concepts/Technical-Architecture-TA.md b/wiki/concepts/Technical-Architecture-TA.md deleted file mode 100644 index 3912357f..00000000 --- a/wiki/concepts/Technical-Architecture-TA.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -id: technical-architecture-ta -title: "Technical Architecture (TA)" -type: concept -tags: - - Technical-Architecture - - Cloud-Architecture ---- - -## Definition -技术架构（Technical Architecture，TA）是三种架构职能中最贴近技术的层级，负责底层技术实施与基础设施治理。 - -## Position in Architecture Hierarchy -- **企业架构（Enterprise Architecture, EA）**：高层，负责将业务目标转化为技术原则和标准 -- **方案架构（Solution Architecture, SA）**：中间层，负责特定项目或服务的优化实施 -- **技术架构（Technical Architecture, TA）**：底层，负责具体基础设施的设计和实施治理 - -## Responsibilities -- 维护AWS Enterprise Landing Zones（企业落地分区） -- 制定技术路线图（12-24个月前瞻性规划） -- 推行"云优先（Cloud-first）"策略 -- 技术领域（Technical Domains）的生命周期管理 - -## Related Concepts -- [[Enterprise-Architecture-EA]] -- [[Solution-Architecture-SA]] -- [[Technical-Domains]] -- [[AWS-Enterprise-Landing-Zones]] -- [[Cloud-First-Strategy]] - ---- - -*最后更新: 2026-04-19* \ No newline at end of file diff --git a/wiki/concepts/Technical-Discovery.md b/wiki/concepts/Technical-Discovery.md deleted file mode 100644 index 54faedb4..00000000 --- a/wiki/concepts/Technical-Discovery.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "Technical Discovery" -type: concept -tags: [sales, pre-sales, methodology] ---- - -## Definition -结构化需求分析过程，揭示买方架构、集成需求、安全约束和真正的技术决策标准，而非仅依赖公开的 RFP 文档。 - -## Core Elements -- 架构需求分析 -- 集成点识别 -- 安全约束确认 -- 技术决策标准挖掘 -- 真实需求 vs 表面需求区分 - -## Relationship to Sales Engineer -技术发现是售前工程师的核心能力之一，在 POC 和演示之前必须完成。发现的质量直接决定后续所有技术活动的方向正确性。 - -## Connections -- [[Sales Engineer]] — 执行技术发现的主体 -- [[Demo Engineering]] — 技术发现的输出用于设计演示 -- [[POC-Scoping]] — 技术发现的结果定义 POC 范围 -- [[Solution Architecture]] — 技术发现是解决方案架构的前置输入 -- [[Global Standards Coverage]] — 规范、边界条件和法域要求属于发现阶段必须厘清的输入 \ No newline at end of file diff --git a/wiki/concepts/Technical-Domains.md b/wiki/concepts/Technical-Domains.md deleted file mode 100644 index 193279a1..00000000 --- a/wiki/concepts/Technical-Domains.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -id: technical-domains -title: "Technical Domains" -type: concept -tags: - - Technical-Architecture - - Cloud-Governance ---- - -## Definition -将公司技术栈划分为特定的领域（如身份认证、网络、Microsoft堆栈等），每个领域由专人负责其生命周期与路线图。 - -## Purpose -- 通过首席架构师负责制，实现12-24个月前瞻性路线图规划 -- 帮助业务部门规避潜在风险、优化预算并提升交付速度 -- 从"救火式"响应转变为预测性规划 - -## Examples -- 身份认证领域（Identity & Access） -- 网络领域（Networking） -- Microsoft堆栈领域 - -## Related Concepts -- [[Technical-Architecture-TA]] -- [[Enterprise-Architecture-EA]] - ---- - -*最后更新: 2026-04-19* \ No newline at end of file diff --git a/wiki/concepts/Technology-Adoption-Curve.md b/wiki/concepts/Technology-Adoption-Curve.md deleted file mode 100644 index c995a7ee..00000000 --- a/wiki/concepts/Technology-Adoption-Curve.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: "Technology Adoption Curve" -type: concept -tags: [diffusion, innovation, rogerrs] -sources: [raw/Agent/agency-agents/product/product-trend-researcher.md] -last_updated: 2026-04-20 ---- - -## Definition -技术采用曲线（Rogers 扩散模型）描述了新技术在市场中传播的典型模式，是预测技术采用时间线的核心框架。 - -## Adoption Stages -1. **Innovators（创新者）**：2.5%，最早尝试新技术的先驱 -2. **Early Adopters（早期采用者）**：13.5%，有远见的早期采纳者 -3. **Early Majority（早期大众）**：34%，深思熟虑的跟随者 -4. **Late Majority（晚期大众）**：34%，怀疑论者后的采纳者 -5. **Laggards（落后者）**：16%，最后采纳的传统主义者 - -## Key Metrics -- Tip Point（临界点）：当采用率达到临界阈值时的爆发增长点 -- Adoption Rate（采用率）：单位时间内的新采用者比例 -- Critical Mass（临界群体）：达到自维持增长所需的采用者数量 diff --git a/wiki/concepts/Technology-Scouting.md b/wiki/concepts/Technology-Scouting.md deleted file mode 100644 index 755e3272..00000000 --- a/wiki/concepts/Technology-Scouting.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "Technology Scouting" -type: concept -tags: [technology, innovation, startups] -sources: [raw/Agent/agency-agents/product/product-trend-researcher.md] -last_updated: 2026-04-20 ---- - -## Definition -技术侦察是识别和评估新兴技术的系统化方法，支持创新决策和战略规划。 - -## Innovation Tracking -- 专利格局：新兴技术、R&D趋势、创新热点 -- 初创企业生态：融资轮次、转向模式、成功指标 -- 学术研究：大学合作、突破性技术、发表趋势 -- 开源项目：社区发展动力、采用模式、商业潜力 -- 标准制定：行业联盟、协议演进 - -## Technology Assessment -- 成熟度分析：技术就绪级别（TRL）、商业可行性 -- 采用预测：扩散模型、网络效应、临界点识别 -- 投资模式：VC投资、企业投资、并购活动 -- 监管影响：政策含义、合规要求 -- 整合机会：平台兼容性、生态系统契合度 diff --git a/wiki/concepts/Terminal-Emulation.md b/wiki/concepts/Terminal-Emulation.md deleted file mode 100644 index 82a7cdd3..00000000 --- a/wiki/concepts/Terminal-Emulation.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "Terminal Emulation" -type: concept -tags: [terminal, emulation, vt100, xterm] ---- - -## 定义 -终端仿真（Terminal Emulation）是一种软件技术，通过模拟传统物理终端的行为，使现代应用程序能够与基于文本的接口进行交互。 - -## 核心要素 -- VT100/xterm 标准支持 -- ANSI 转义序列解析 -- 光标控制 -- 字符编码处理（UTF-8/Unicode） - -## 技术原理 -1. 接收来自应用程序的字符输入 -2. 解析 ANSI 转义序列 -3. 更新终端状态 -4. 渲染文本到显示设备 - -## 应用场景 -- SSH 客户端 -- 终端仿真器应用 -- 远程服务器管理 - -## 相关技术 -- [[VT100]]：终端标准规范 -- [[ANSI Escape Sequence]]：终端控制指令 -- [[SwiftTerm]]：Swift 实现库 \ No newline at end of file diff --git a/wiki/concepts/TerraGrunt.md b/wiki/concepts/TerraGrunt.md deleted file mode 100644 index 6a2fc8b3..00000000 --- a/wiki/concepts/TerraGrunt.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -id: TerraGrunt -title: "TerraGrunt" -type: concept -tags: - - DevOps - - IaC - - Terraform - - AWS -last_updated: 2026-04-18 ---- - -## Aliases -- Terragrunt - -## Summary -- **定义**：Terraform 的包装工具，提供模块化、变量共享和环境隔离 -- **用途**：管理多环境、多账户的 Terraform 配置 -- **云迁移价值**：简化 Landing Zone 多账户部署 - -## Key Details -- **核心功能**： - - 远程状态存储配置 - - 模块化配置复用 - - 多环境/多账户管理 - - 自动输入变量传递 -- **工作目录结构**： - ``` - live/ - ├── prod/ - │ └── terragrunt.hcl - ├── staging/ - │ └── terragrunt.hcl - └── dev/ - └── terragrunt.hcl - ``` -- **与 Terraform 关系**： - - TerraGrunt 调用 Terraform - - 纯 Terraform 包装，不替代 - -## Octane Hub 案例 -- Octane Hub 使用 TerraGrunt 部署 AWS 基础设施 -- 从手动脚本演进到 IaC 流程 - -## Connections -- [[Terraform]] ← wrapped_by ← [[TerraGrunt]] -- [[Infrastructure-as-Code-IaC]] ← implementd_by ← [[TerraGrunt]] -- [[Multi-Account-Strategy]] ← managed_by ← [[TerraGrunt]] \ No newline at end of file diff --git a/wiki/concepts/TerraTest.md b/wiki/concepts/TerraTest.md deleted file mode 100644 index d834ad54..00000000 --- a/wiki/concepts/TerraTest.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "TerraTest" -type: concept -tags: - - Testing - - IaC - - Terraform -date Added: 2026-04-19 ---- - -## Summary -TerraTest 是使用 Golang 编写的自动化基础设施测试库，自动化 Terraform apply-test-destroy 周期，简化基础设施测试流程。 - -## Definition -Golang 编写的开源测试库，专门用于测试 Terraform 部署的基础设施。 - -## Key Features -- 自动 apply：自动应用 Terraform 配置 -- 自动 test：自动执行测试验证输出 -- 自动 destroy：测试完成后自动清理资源 - -## Use Cases -- 集成测试验证已部署基础设施的实际功能 -- 测试复杂 Terraform 模块 -- 测试驱动的基础设施开发（TDD） - -## Sources -- [[ctp-topic-56-automated-infrastructure-testing]] - -## Aliases -- TerraTest -- Terratest \ No newline at end of file diff --git a/wiki/concepts/Terraform.md b/wiki/concepts/Terraform.md deleted file mode 100644 index 4b2db61c..00000000 --- a/wiki/concepts/Terraform.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -id: Terraform -title: "Terraform" -type: concept -tags: - - DevOps - - IaC - - AWS - - Infrastructure -last_updated: 2026-04-19 ---- - -## Aliases -- Terraform -- IaC (Infrastructure as Code) - -## Summary -- **定义**：基础设施即代码工具，通过声明式配置定义云资源 -- **用途**：跨云平台（AWS、Azure、GCP）管理基础设施 -- **云迁移价值**：实现基础设施版本控制、可重复部署和环境一致性 - -## Key Details -- **核心概念**： - - Provider：云平台连接器（aws、azurerm 等） - - Resource：基础设施资源定义 - - Data Source：只读数据查询 - - Variable：输入变量 - - Output：输出值 - - Module：可复用配置单元 -- **工作流程**： - - init：初始化 provider 和 backend - - plan：预览变更 - - apply：执行变更 - - destroy：销毁资源 -- **状态管理**： - - 本地状态或远程状态（S3、DynamoDB） - - 状态锁防止并发冲突 - -## Terraform vs Terragrunt -- **Terraform**：底层 IaC 工具 -- **Terragrunt**：Terraform 包装器，提供模块变量共享、多环境管理、远程状态配置 - -## Connections -- [[TerraGrunt]] ← wraps ← [[Terraform]] -- [[Service-Catalog]] ← uses ← [[Terraform]] -- [[AWS]] ← managed_by ← [[Terraform]] -- [[Module]] ← implemented_by ← [[Terraform]] \ No newline at end of file diff --git a/wiki/concepts/Test-Driven-Development.md b/wiki/concepts/Test-Driven-Development.md deleted file mode 100644 index 93c5f839..00000000 --- a/wiki/concepts/Test-Driven-Development.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: "Test-Driven Development" -type: concept -tags: - - Testing - - Development - - TDD -date Added: 2026-04-19 ---- - -## Summary -测试驱动开发（Test-Driven Development，TDD）是一种软件开发方法论，先写测试再实现功能，确保聚焦开发目标并构建全面的测试套件。 - -## Definition -测试驱动开发是一种迭代开发方法论，通过先编写测试来定义期望行为，然后编写最小代码通过测试，最后重构改进。 - -## Workflow -1. 编写测试（Red）：定义期望行为 -2. 实现代码（Green）：编写最小代码通过测试 -3. 重构（Refactor）：优化代码结构 - -## Benefits -- 确保功能可测试 -- 构建全面测试套件 -- 聚焦开发目标 -- 提高代码质量 - -## Sources -- [[ctp-topic-56-automated-infrastructure-testing]] - -## Aliases -- TDD -- Test-Driven Development \ No newline at end of file diff --git a/wiki/concepts/Thought-Leadership.md b/wiki/concepts/Thought-Leadership.md deleted file mode 100644 index 0a4bc3c0..00000000 --- a/wiki/concepts/Thought-Leadership.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "Thought Leadership" -type: concept -tags: [marketing, brand, authority] -last_updated: 2026-04-21 ---- - -## Definition -思想领导力，通过专业知识分享、独特视角和创新洞察在行业中建立权威地位，使品牌或个人成为他人信赖的参考来源。 - -## Core Elements -- Deep Expertise：深入的专业知识，能够提供独到见解 -- Unique Perspective：与众不同的角度，避免泛泛而谈 -- Industry Advancement：推动行业对话和进步 -- Credibility Building：通过持续高质量输出建立信任 - -## Development Process -1. Identify core topics aligned with business expertise -2. Research existing experts and find differentiation gaps -3. Create comprehensive, data-backed content -4. Engage authentically in community discussions -5. Build subscriber base through consistent publishing - -## Connection to Zhihu Strategy -- Core Mission：Transform brands into Zhihu authority powerhouses through thought leadership -- Platform Fit：知乎用户寻求深度知识和专业见解 -- Content Standard：Only answer questions where genuine expertise exists - -## Key Metrics -- Answer Upvote Rate：100+ average upvotes per answer -- Top Answer Rate：30%+ of answers becoming "Best Answers" -- Authority Recognition：Topic authority badges, inclusion in "Best Experts" lists - -## Related Concepts -- [[Community Credibility]] ← builds ← [[Thought Leadership]] -- [[Content Pillar]] ← enables ← [[Thought Leadership]] -- [[Lead Generation Funnel]] ← drives ← [[Thought Leadership]] - -## Additional Sources -- [[Social Media Strategist]] — LinkedIn/Twitter 跨平台思想领导力建设 \ No newline at end of file diff --git a/wiki/concepts/Three-Act-Proposal-Narrative.md b/wiki/concepts/Three-Act-Proposal-Narrative.md deleted file mode 100644 index 3e5b7212..00000000 --- a/wiki/concepts/Three-Act-Proposal-Narrative.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "Three-Act Proposal Narrative" -type: concept -tags: [Proposal, Sales, Strategy, Narrative] -last_updated: 2026-04-20 ---- - -## Definition -三幕式提案叙事是一种将提案转化为引人入胜的故事的结构化方法，遵循经典叙事弧线而非简单的合规检查表。 - -## Three Acts - -### Act I — Understanding the Challenge（理解挑战） -展示你比预期更了解买家的世界。反映他们的语言、约束和政治格局。这是建立信任的地方。大多数失败的提案完全跳过这一幕或用模板填充。 - -### Act II — The Solution Journey（解决方案旅程） -引导评估者体验你的方法，而不是一堆功能倾倒。每个能力都映射到第一幕中提出的挑战。方法论作为决策序列解释，而不是一面流程图墙。这是制胜主题最重的工作的地方。 - -### Act III — The Transformed State（转型状态） -描绘买家未来的具体画面。量化结果、时间线里程碑、风险降低指标。评估者应该读完这部分想到的是实施，而不是评估。 - -## Key Principles -- 每个提案需要一个清晰的叙事弧线，而非 checklist -- 叙事 flow 必须贯穿所有 section -- Act I 建立信任，Act II 展示方法，Act III 激发行动 - -## Connections -- [[Three-Act Proposal Narrative]] ← framework_of ← [[Proposal Strategy]] -- [[Three-Act Proposal Narrative]] ← structured_by ← [[Win Theme]] -- [[Three-Act Proposal Narrative]] → leads_to → [[Executive Summary]] \ No newline at end of file diff --git a/wiki/concepts/Three-Lines-of-Defense.md b/wiki/concepts/Three-Lines-of-Defense.md deleted file mode 100644 index 5eb73655..00000000 --- a/wiki/concepts/Three-Lines-of-Defense.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: "Three Lines of Defense" -type: concept -tags: [Security, Governance, Risk-Management, Framework] -date: 2026-04-14 ---- - -## Definition -三道防线（Three Lines of Defense，3LoD）是一种企业风险管理框架，通过分层职责确保安全控制的有效性。 - -## First Line of Defense -业务单元：负责在其领域内实施和管理安全控制，是安全的直接责任方。 - -## Second Line of Defense -集团办公室：负责制定政策、事件响应和网络工具，作为第一道防线的顾问，提供指导和支持。 - -## Third Line of Defense -审计：确保第一道和第二道防线的合规性，为企业提供保证。 - -## Key Drivers -- 监管合规（Regulatory Compliance） -- 集中化平台（Centralized Platform） -- 云迁移（Cloud Migration） -- 基线控制（Baseline Controls） -- 更大的安全响应覆盖范围 - -## Work Streams Implemented -- 政策审查与整合 -- 事件响应参与 -- 网络安全风险与控制指标开发 -- 网络安全工具审查 -- 安全架构标准与模式 - -## Related Entities -- [[Coyote]] — Head of Enterprise Application Security，框架推动者 - -## Related Concepts -- [[Cloud-Security-Posture-Management]] -- [[Regulatory-Compliance]] -- [[Risk-Management]] - -## Related Sources -- [[CTP Topic 52 3 Lines of Defence (3LoD) framework Cloud Security Posture Management (CSPM)]] \ No newline at end of file diff --git a/wiki/concepts/TikTok-Shop.md b/wiki/concepts/TikTok-Shop.md deleted file mode 100644 index 542c2fa4..00000000 --- a/wiki/concepts/TikTok-Shop.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -title: "TikTok Shop" -type: concept -tags: [跨境电商, 电商平台] ---- - -TikTok Shop（也称为 TikTok 电商）是字节跳动旗下的短视频电商平台，集成在 TikTok 应用中，允许创作者和商家通过短视频和直播直接销售商品。 - -## Core Features -- 短视频带货：通过 TikTok 视频内容推广商品 -- 直播带货：通过 TikTok Live 实时展示和销售商品 -- 联盟营销：创作者可以推广商家商品获取佣金 -- 物流支持：提供面单系统和物流追踪服务 - -## Related Concepts -- [[面单授权]]：物流面单打印的授权配置 -- [[美国本土店]]：TikTok Shop 美国地区的本地商家店铺 -- [[跨境电商]]：涉及跨国境的电子商务活动 \ No newline at end of file diff --git a/wiki/concepts/Time-boxed.md b/wiki/concepts/Time-boxed.md deleted file mode 100644 index bae67392..00000000 --- a/wiki/concepts/Time-boxed.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "Time-boxed" -type: concept -tags: [workflow, time-management, scope-control] -last_updated: 2026-04-21 ---- - -## Definition -Time-boxed 是一种时间管理机制，为单一任务设置最大时长限制，防止范围蔓延和无限期延误。 - -## Purpose -- 防止范围蔓延（scope creep） -- 确保交付时间线 -- 提高专注度 -- 加速决策 - -## Example -Landing page sprint 时间表： -| Time | Activity | Agent | -|------|----------|-------| -| 9:00 | Copy + design kick off | Content Creator + UI Designer | -| 11:00 | Build starts | Frontend Developer | -| 14:00 | First version ready | — | -| 15:30 | Apply feedback | Frontend Developer | -| 16:30 | Ship | Deploy | - -## Connections -- [[Multi-Agent Workflow]]：所属工作流模式 -- [[Sprint Planning]]：相关时间规划概念 - diff --git a/wiki/concepts/Todorov-均衡模型.md b/wiki/concepts/Todorov-均衡模型.md deleted file mode 100644 index d36e7017..00000000 --- a/wiki/concepts/Todorov-均衡模型.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "Todorov 均衡模型" -type: concept -tags: [narrative-theory, story-structure, equilibrium] ---- - -## 定义 -Tzvetan Todorov 提出的叙事结构模型，基于平衡—失衡—新平衡的循环结构。 - -## 核心阶段 -1. **Equilibrium（均衡）**：初始平衡状态 -2. **Disruption（失衡）**：平衡被打破，冲突引入 -3. **Recognition（识别）**：认识到失衡状态 -4. **Repair（修复）**：尝试恢复平衡 -5. **New Equilibrium（新均衡）**：新的平衡状态（可能与初始状态不同） - -## 变体（五阶段模型） -- Binary opposites：基于二元对立的冲突结构 - -## 与其他框架关系 -- 与 [[McKee 故事结构]] 共享 equilibrium-disruption-return 结构 -- 与 [[Campbell 英雄之旅]] 的回归阶段相关 - -## 来源框架 -- [[Narratologist]] 使用此框架分析 disruption-based plots diff --git a/wiki/concepts/Token.md b/wiki/concepts/Token.md deleted file mode 100644 index 9aa11c84..00000000 --- a/wiki/concepts/Token.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -title: "Token" -type: concept -tags: [llm, token] -date: 2025-12-20 ---- - -## Definition -大模型各种算法的基本输入单元，可以认为是一个单词或者一个短语。 - -## Token Calculation Rules -- 1 个英文字符 ≈ 0.3 个 token -- 1 个中文字符 ≈ 0.6 个 token - -## Related Concepts -- [[LLM]]：使用 Token 作为输入的语言模型 -- [[Embedding]]：将 Token 转化为向量化表示 -- [[vLLM]]：优化 Token 处理效率的推理引擎 \ No newline at end of file diff --git a/wiki/concepts/Tool-Evaluation-Framework.md b/wiki/concepts/Tool-Evaluation-Framework.md deleted file mode 100644 index aab14dc9..00000000 --- a/wiki/concepts/Tool-Evaluation-Framework.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: "Tool Evaluation Framework" -type: concept -tags: [tool-evaluation, framework, methodology] -sources: [] -last_updated: 2026-04-21 ---- - -## Summary -工具评估框架是一种结构化的定量评估方法，通过加权评分体系对工具进行多维度评估，支持企业级工具选择决策。 - -## Definition -采用多准则决策分析（MCDA），通过七个核心维度对工具进行全面评估： -- 功能性（functionality） -- 可用性（usability） -- 性能（performance） -- 安全性（security） -- 集成（integration） -- 支持（support） -- 成本（cost） - -## Key Metrics -- 功能性测试：required features 80% + optional features 20% -- 性能测试：平均响应时间、P95 响应时间 -- TCO 计算：许可 + 实施 + 培训 + 维护 + 集成 + 迁移 + 支持 - -## Application -用于企业工具选择、供应商评估、投资回报分析等场景。 - -## Related Concepts -- [[TCO（Total Cost of Ownership）]] -- [[ROI Analysis]] -- [[Vendor Management]] diff --git a/wiki/concepts/Tool-Wrapper.md b/wiki/concepts/Tool-Wrapper.md deleted file mode 100644 index 7fa04026..00000000 --- a/wiki/concepts/Tool-Wrapper.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -id: tool-wrapper -title: "Tool Wrapper" -type: concept -tags: [Agent, Skill, 设计模式] -sources: [Google-5-Agent-Skill-design-patterns-2026-03-19] -last_updated: 2026-04-17 ---- - -## Summary -最容易上手的 Agent Skill 设计模式，让 agent 快速成为某个领域的专家。 - -## Definition -Tool Wrapper 模式把某个库或框架的规范文档打包成一个 skill，agent 只有在真正用到这个技术时才会加载相关文档。 - -## How It Works -1. **监听特定关键词**：SKILL.md 监听特定的库关键词（如 `FastAPI`、`React`） -2. **动态加载文档**：当用户开始使用特定技术时，动态加载 references 目录下的规范文档 -3. **规则执行**：把加载的规则当作绝对真理来执行 - -## Use Cases -- 分发团队内部的编码规范 -- 实现特定框架的最佳实践 -- 快速成为某个技术栈的专家 - -## Advantages -- 减少 system prompt 膨胀 -- 按需加载，降低 token 消耗 -- 易于维护和更新 - -## Related Concepts -- [[Agent-Skill-设计模式]] -- [[渐进式披露]] \ No newline at end of file diff --git a/wiki/concepts/Trend-Analysis.md b/wiki/concepts/Trend-Analysis.md deleted file mode 100644 index 03c63638..00000000 --- a/wiki/concepts/Trend-Analysis.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: "Trend Analysis" -type: concept -tags: [trend, forecasting, signal-detection] -sources: [raw/Agent/agency-agents/product/product-trend-researcher.md] -last_updated: 2026-04-20 ---- - -## Definition -趋势分析是通过识别数据中的模式、信号和规律，预测未来发展方向的研究方法。 - -## Core Capabilities -- 模式识别（Pattern Recognition） -- 信号检测（Signal Detection） -- 未来预测（Future Forecasting） -- 生命周期映射（Lifecycle Mapping） - -## Process -1. 信号收集：跨50+来源实时聚合 -2. 模式识别：统计分析和异常检测 -3. 上下文分析：驱动因素和障碍 -4. 影响评估：市场影响量化 -5. 验证：专家意见交叉验证 -6. 预测：时间线和采用率预测 -7. 可行性：具体行动建议 - -## Trend Lifecycle -- Emergence（出现） -- Growth（增长） -- Maturity（成熟） -- Decline（衰退） diff --git a/wiki/concepts/Trending-Topic-Operations.md b/wiki/concepts/Trending-Topic-Operations.md deleted file mode 100644 index c3e66d7f..00000000 --- a/wiki/concepts/Trending-Topic-Operations.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: "Trending Topic Operations" -type: concept -tags: [weibo, marketing, viral, social-media] -last_updated: 2026-04-21 ---- - -## Definition -趋势话题运营是通过策划和执行微博话题，实现品牌病毒式传播和持续增长的策略体系。 - -## Core Mechanics -- **算法逻辑**：热搜排名 = 搜索量 × 讨论量 × 参与速度 × 原创内容比例复合权重 -- **生命周期**：通常 4-8 小时，窗口期极为关键 -- **传播公式**：争议性 × 低参与门槛 × 情感共鸣 = 病毒扩散 - -## Topic Design Principles -- 简短有力（4-8 字符最佳） -- 包含悬念或争议（"XXX翻车了？"优于"XXX新品发布"） -- 包含情感触发词（震惊、出乎意料、真相、原来） - -## Distribution Cadence -| Phase | Timing | Action | Participants | -|-------|--------|--------|-------------| -| Warm-up | T-1 day | 预告海报+预览帖 | 官方账号 | -| Ignition | T-day 0-2h | 核心话题发布+KOL首发 | 3-5个顶级KOL | -| Amplification | T-day 2-6h | 中层创作者跟进+草根UGC | 20-30个中层KOL | -| Consolidation | T-day 6-24h | 话题收尾+二次分发素材 | 官方账号+媒体账号 | - -## Trending Advertising Products -- **Trending Companion**：品牌内容伴随热搜词展示，蹭流量 -- **Brand Trending**：自定义品牌热搜位，直接占据热搜入口 -- **Trending Easter Egg**：搜索品牌关键词触发自定义视觉效果 - -## Connections -- [[Marketing Weibo Strategist]] → uses → [[Trending Topic Operations]] -- [[Sentiment Early Warning System]] → monitors → [[Trending Topic Operations]] \ No newline at end of file diff --git a/wiki/concepts/Trigger-Framework.md b/wiki/concepts/Trigger-Framework.md deleted file mode 100644 index d26ebad3..00000000 --- a/wiki/concepts/Trigger-Framework.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: "Trigger Framework" -type: concept -tags: [salesforce, triggers, architecture] -sources: [specialized-salesforce-architect.md] -last_updated: 2026-04-20 ---- - -# Trigger Framework - -Salesforce 触发器的标准化架构模式。 - -## 核心原则 -- 每个对象一个触发器 -- 触发器不包含业务逻辑，只委托给 handler 类 -- 必须支持批量处理（Bulkification） - -## 架构组成 -1. **Trigger** — 入口点，只做委托 -2. **Handler** — 包含业务逻辑 -3. **Selector** — SOQL 查询封装 -4. **Service** — 跨触发器共享逻辑 - -## 关键规则 -- 无业务逻辑放在触发器中 -- 委托给 handler 类处理所有业务逻辑 - -## 相关概念 -- [[Bulkification]] — 触发器必须支持批量处理 \ No newline at end of file diff --git a/wiki/concepts/TweetClaw.md b/wiki/concepts/TweetClaw.md deleted file mode 100644 index 9d35fc19..00000000 --- a/wiki/concepts/TweetClaw.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "TweetClaw" -type: concept -tags: [ai-agent, automation, social-media] -last_updated: 2026-04-17 ---- - -## Definition -TweetClaw 是 OpenClaw 插件，通过自然语言实现 X/Twitter 运营自动化的工具。 - -## Related Features -- 发推与互动：发推文、回复、点赞、转发、关注/取消关注、发送私信 -- 搜索与提取：搜索推文和用户，提取粉丝、点赞者、转发者、引用推文者、列表成员 -- 抽奖管理：从推文互动者中随机抽取获奖者，支持按粉丝数、账号年龄、关键词等条件筛选 -- 账户监控：监控指定账户的新推文或粉丝变化，主动通知用户 - -## Technical Details -- 安装方式：`openclaw plugins install @xquik/tweetclaw` -- npm 包：`@xquik/tweetclaw` -- GitHub 仓库：https://github.com/Xquik-dev/tweetclaw -- 所有操作通过托管 API 完成，无需浏览器 Cookie、无需爬虫、无凭证暴露风险 - -## Aliases -- TweetClaw -- X/Twitter Automation - -## Related Concepts -- [[工作流自动化]] — 预定义自动化流程 -- [[自然语言处理]] — 通过自然语言指令驱动操作 - -## Related Entities -- [[OpenClaw]] — 插件宿主工具 \ No newline at end of file diff --git a/wiki/concepts/UEFI.md b/wiki/concepts/UEFI.md deleted file mode 100644 index b4718842..00000000 --- a/wiki/concepts/UEFI.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "UEFI" -type: concept -tags: [firmware, boot, bios, standards] -date: 2026-04-16 ---- - -## Aliases -- UEFI -- Unified Extensible Firmware Interface -- 统一可扩展固件接口 - -## Definition -UEFI（统一可扩展固件接口）是替代传统 BIOS 的现代固件接口标准，提供更大的硬盘支持、更快的启动速度和更强的安全特性（如 Secure Boot）。 - -## Key Properties -- 发布时间：2007 年 -- 最大启动盘支持：理论上 16EB（实际受操作系统限制） -- 启动速度：比传统 BIOS 快 -- 安全特性：支持 Secure Boot -- 驱动程序：可在固件中加载 - -## Use Cases -- 现代台式机和笔记本电脑启动（如 HP ZBook 安装 Ubuntu） -- 服务器系统初始化 -- 安全启动 Windows/Linux - -## Connections -- [[UEFI]] ← works_with ← [[GPT]] -- [[UEFI]] ← requires ← [[Secure Boot]] \ No newline at end of file diff --git a/wiki/concepts/USER.md b/wiki/concepts/USER.md deleted file mode 100644 index d97d6eec..00000000 --- a/wiki/concepts/USER.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "USER.md" -type: concept -tags: [OpenClaw, Agent] ---- - -## 定义 -USER.md 是 OpenClaw workspace 中的用户画像与偏好固化文件，作用是将用户反复要说的偏好沉淀为默认背景。 - -## 职责 -- 固化用户基本信息（职业、使用场景、常用语言） -- 定义用户偏好设定（回答风格、代码偏好、内容偏好） -- 记录用户不喜欢的行为（被反问太多次、过度解释） -- 列举用户常见任务类型 -- 说明背景知识假设 - -## 典型结构 -```markdown -# 用户档案 -## 基本信息 -- 职业：独立开发者 / 内容创作者 -- 主要使用场景：代码工具、内容写作、项目管理 - -## 偏好设定 -- 回答风格：简洁直接，避免废话 -- 代码偏好：TypeScript / Python - -## 不喜欢 -- 被反问太多次、过度解释已经懂的概念 -``` - -## 与 SOUL.md 的协同 -SOUL.md 定义 Agent 的性格，USER.md 定义用户的性格。两者放在一起，相当于在 Agent 的脑子里预装了一份"这个人机关系的基本共识"。 - -## 来源 -- [[万字讲透OpenClaw🦞从"能用"到"真好用"的分水岭：Workspace 深度解析]] - -## 相关 -- [[SOUL.md]]：Agent 性格档案 -- [[Workspace]]：包含 USER.md 的工作台目录 \ No newline at end of file diff --git a/wiki/concepts/Usability-Testing.md b/wiki/concepts/Usability-Testing.md deleted file mode 100644 index 02be5be4..00000000 --- a/wiki/concepts/Usability-Testing.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: "Usability Testing" -type: concept -tags: [ux, testing, methodology] -last_updated: 2026-04-20 ---- - -## Definition -可用性测试是评估产品易用性的方法，通过让真实用户执行任务来识别可用性问题。 - -## Testing Methods -- 实验室测试 -- 远程测试 -- 基准测试 -- 比较测试 - -## Key Metrics -- 任务完成率 -- 任务时间 -- 错误数量 -- 用户满意度评分 -- NPS - -## Process -1. 定义测试目标和任务 -2. 招募参与者 -3. 进行测试 session -4. 分析数据 -5. 生成报告和建议 - -## Related Concepts -- [[User Research]] -- [[User Journey Mapping]] \ No newline at end of file diff --git a/wiki/concepts/User-Journey-Mapping.md b/wiki/concepts/User-Journey-Mapping.md deleted file mode 100644 index b656c4ce..00000000 --- a/wiki/concepts/User-Journey-Mapping.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: "User Journey Mapping" -type: concept -tags: [ux, journey, mapping] -last_updated: 2026-04-20 ---- - -## Definition -用户旅程映射是可视化用户与产品交互全过程的系统化方法，识别关键触点、痛点和改进机会。 - -## Components -- 用户阶段 -- 触点 -- 行为 -- 情绪曲线 -- 痛点 -- 机会 - -## Process -1. 定义范围和目标 -2. 创建阶段划分 -3. 映射行为和触点 -4. 绘制情绪曲线 -5. 识别改进机会 - -## Related Concepts -- [[User Research]] -- [[User Persona]] -- [[Usability Testing]] \ No newline at end of file diff --git a/wiki/concepts/User-Persona.md b/wiki/concepts/User-Persona.md deleted file mode 100644 index 36298847..00000000 --- a/wiki/concepts/User-Persona.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "User Persona" -type: concept -tags: [ux, persona, research] -last_updated: 2026-04-20 ---- - -## Definition -用户画像是基于实证数据创建的理想用户原型，代表目标用户群体的特征、目标、需求和痛点。 - -## Components -- 人口统计学信息 -- 行为模式 -- 目标和需求 -- 痛点 -- 技术熟练度 -- 设备偏好 - -## Creation Process -1. 收集用户数据 -2. 识别模式 -3. 创建原型 -4. 验证和迭代 - -## Related Concepts -- [[User Research]] -- [[User Journey Mapping]] \ No newline at end of file diff --git a/wiki/concepts/User-Research.md b/wiki/concepts/User-Research.md deleted file mode 100644 index 926cc5f6..00000000 --- a/wiki/concepts/User-Research.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: "User Research" -type: concept -tags: [ux, research, methodology] -last_updated: 2026-04-20 ---- - -## Definition -用户研究是通过定性定量方法理解用户行为、需求、动机和痛点的系统性过程。 - -## Research Methods -- 用户访谈 -- 问卷调查 -- 可用性测试 -- 行为数据分析 -- 竞品分析 - -## Key Outputs -- 用户画像 -- 用户旅程地图 -- 研究报告 -- 设计建议 - -## Related Concepts -- [[Usability Testing]] -- [[User Persona]] -- [[User Journey Mapping]] -- [[Behavioral Analytics]] \ No newline at end of file diff --git a/wiki/concepts/VAT.md b/wiki/concepts/VAT.md deleted file mode 100644 index 30b10b20..00000000 --- a/wiki/concepts/VAT.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: VAT (Value Added Tax) -type: concept -tags: [compliance, taxation, cross-border, europe, uk] -aliases: [Value Added Tax, UK VAT, EU VAT, OSS, IOSS] ---- - -## Definition -增值税，欧盟和英国等市场对商品和服务征收的消费税。跨境电商必须注册、申报和缴纳。 - -## Key Markets -- UK：必须注册英国 VAT，申报周期通常为季度 -- Germany：VerpackG（包装法）额外要求 -- EU：OSS/IOSS 一站式申报，简化多国申报流程 - -## Compliance Requirements -- 注册 VAT 是销售的前置条件 -- 不合规会导致平台下架 + 罚款 -- 税务欺诈是跨境电商的定时炸弹 - -## Connection to Cross-Border E-Commerce -VAT 合规是进入欧洲和英国市场的必要条件，成本必须计入产品定价模型。 - -## Connections -- [[Marketing Cross-Border E-Commerce Specialist]] ← requires ← [[VAT (Value Added Tax)]] -- [[Legal Compliance Checker]] ← validates ← [[VAT (Value Added Tax)]] \ No newline at end of file diff --git a/wiki/concepts/VDI.md b/wiki/concepts/VDI.md deleted file mode 100644 index 0a0382fa..00000000 --- a/wiki/concepts/VDI.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: "VDI" -type: concept -tags: [] ---- - -## Definition -Virtual Desktop Infrastructure，虚拟桌面基础设施。通过远程桌面协议（如 RDP、WSP）提供虚拟计算环境，用户可以在任何设备上访问托管的虚拟桌面。 - -## Use Cases -- 远程办公和混合工作模式 -- BYOD（自带设备）安全访问企业资源 -- 标准化桌面管理和安全控制 - -## Related Concepts -- [[持久化桌面]]：数据和应用设置在会话间保留 -- [[非持久化桌面]]：每次登录分配新桌面 - -## Related Entities -- [[AWS-Workspaces]] -- [[AppStream-2.0]] \ No newline at end of file diff --git a/wiki/concepts/VLESS.md b/wiki/concepts/VLESS.md deleted file mode 100644 index 38e32d80..00000000 --- a/wiki/concepts/VLESS.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -id: vless -title: VLESS -type: concept -tags: [protocol, proxy, security] -sources: [] -last_updated: 2026-04-16 ---- - -## Aliases -- VLESS Protocol - -## Summary -- 定义：轻量级代理协议，是 V2Ray/ Xray 的核心协议之一 -- 作用：提供高性能的科学上网服务，相比 VMESS 更轻量 - -## Key Facts -- 无状态设计，性能更高 -- 支持 TLS 伪装 -- 支持与 Reality 组合使用 -- 不需要额外的认证密钥，使用 UUID 或密码 diff --git a/wiki/concepts/VPA.md b/wiki/concepts/VPA.md deleted file mode 100644 index 04f510f3..00000000 --- a/wiki/concepts/VPA.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: "VPA" -type: concept -tags: [Kubernetes, EKS, Auto-Scaling] ---- - -## Description -VPA（Vertical Pod Autoscaler）是 Kubernetes 的垂直 Pod 自动扩缩容功能，根据实际使用情况自动调整 Pod 的资源请求（CPU、内存），但调整时会重启 Pod。 - -## Note -与 HPA 不同，VPA 调整的是单个 Pod 的资源大小而非副本数。 - -## Related Concepts -- [[HPA]] -- [[EKS 可靠性]] - -## Related Entities -- [[EKS]] -- [[Kubernetes]] - -## Connections -- [[VPA]] ← 实现 [[EKS 可靠性]] \ No newline at end of file diff --git a/wiki/concepts/VPC-Endpoint.md b/wiki/concepts/VPC-Endpoint.md deleted file mode 100644 index 81dd0d1c..00000000 --- a/wiki/concepts/VPC-Endpoint.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: "VPC Endpoint" -type: concept -tags: - - AWS - - networking - - security ---- - -## Aliases -- VPC Endpoint -- VPC 终端节点 -- PrivateLink -- AWS PrivateLink - -## Description -AWS 提供的私有网络连接服务，允许 VPC 中的资源安全地访问 AWS 服务而不经过公网。通过 VPC Endpoint，应用可以与 AWS 服务进行私有通信，确保数据不暴露在公网。 - -## Endpoint Types -- **接口终端节点（Interface Endpoint）**：通过 ENI（弹性网络接口）连接到 AWS 服务，支持 TCP 流量，适用于大多数 AWS 服务 -- **网关终端节点（Gateway Endpoint）**：通过路由表配置，适用于 S3 和 DynamoDB - -## Use Cases -- SES SMTP 访问：通过 VPC Endpoint 实现私有邮件发送 -- Secrets Manager 访问：通过 VPC Endpoint 实现凭证私有访问 -- S3/DynamoDB 访问：使用网关终端节点 - -## Security Benefits -- 数据不经过公网，避免中间人攻击 -- 满足合规要求（数据不出公网） -- 降低防火墙管理复杂度 - -## Sources -- [[ctp-topic-12-using-ses-smtp-service-terraform-module]] \ No newline at end of file diff --git a/wiki/concepts/VPC-Transit-Gateway.md b/wiki/concepts/VPC-Transit-Gateway.md deleted file mode 100644 index 92288335..00000000 --- a/wiki/concepts/VPC-Transit-Gateway.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -id: VPC-Transit-Gateway -title: "VPC Transit Gateway" -type: concept -tags: - - AWS - - Network - - VPC - - Cloud-Migration -last_updated: 2026-04-18 ---- - -## Aliases -- Transit Gateway -- TGW - -## Summary -- **定义**：AWS 中心辐射式网络互联服务，允许跨 VPC 和本地数据中心之间的网络流量路由 -- **用途**：简化复杂网络的连接和管理 -- **云迁移价值**：实现多 VPC 统一网络架构 - -## Key Details -- **核心功能**： - - 跨 VPC 互联（数千个 VPC） - - AWS 与本地数据中心互联（通过 Direct Connect 或 VPN） - - 跨区域互联 - - 路由表控制 -- **优势**： - - 简化网络 architecture（中心辐射模型） - - 减少复杂对等连接管理 - - 集中审计和日志 -- **计费**：按小时和数据量计费 - -## Octane Hub 案例 -- Octane Hub 使用 VPC Transit Gateway 实现网络互联 -- 解决了多 VPC 和本地数据中心连接需求 - -## Connections -- [[AWS]] ← provides ← [[VPC-Transit-Gateway]] -- [[VPC]] ← connected_by ← [[VPC-Transit-Gateway]] -- [[AWS-Organizations]] ← manages ← [[VPC-Transit-Gateway]] \ No newline at end of file diff --git a/wiki/concepts/VT100.md b/wiki/concepts/VT100.md deleted file mode 100644 index 0186c7e2..00000000 --- a/wiki/concepts/VT100.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: "VT100" -type: concept -tags: [terminal, standard, ansi] ---- - -## 定义 -VT100 是 DEC（Digital Equipment Corporation）公司于 1978 年发布的终端标准，是现代终端仿真器实现的事实标准。 - -## 核心特性 -- ANSI escape sequence 支持 -- 屏幕光标控制 -- 属性设置（加粗、下划线、闪烁等） -- 屏幕清除和行删除 -- 键盘功能键映射 - -## 标准版本 -- VT100：基础版本 -- VT220：在 VT100 基础上增加功能键和更多控制序列 -- xterm：终端仿真器扩展，增加 256 色、鼠标支持等 - -## ANSI 转义序列示例 -- `\x1b[31m` — 红色文本 -- `\x1b[0m` — 重置属性 -- `\x1b[2J` — 清除屏幕 -- `\x1b[H` — 光标归位 - -## 相关技术 -- [[Terminal Emulation]]：终端仿真 -- [[ANSI Escape Sequence]]：ANSI 转义序列 -- [[SwiftTerm]]：Swift 实现库 - -## 参考文档 -- https://vt100.net/docs/ \ No newline at end of file diff --git a/wiki/concepts/Vaillant-Defense-Mechanisms.md b/wiki/concepts/Vaillant-Defense-Mechanisms.md deleted file mode 100644 index 4d2a4798..00000000 --- a/wiki/concepts/Vaillant-Defense-Mechanisms.md +++ /dev/null @@ -1,49 +0,0 @@ ---- -title: "Vaillant Defense Mechanisms Hierarchy" -type: concept -tags: [psychodynamic, defense-mechanisms, vaillant] -sources: [] -last_updated: 2026-04-20 ---- - -# Vaillant Defense Mechanisms Hierarchy - -## Aliases -- Vaillant 防御机制层级 -- 防御机制层级 -- Defense Mechanism Hierarchy - -## Summary -George Vaillant 通过纵向研究提出的防御机制分类系统，将适应不良到成熟的防御方式组织为四个层级，是精神分析自我心理学的重要贡献。 - -## Hierarchy Levels - -### 成熟防御（Level 4 - Mature） -- **升华（Sublimation）**：将不可接受的冲动转化为社会认可的活动 -- **幽默（Humor）**：以轻松方式处理困难情绪 -- **压抑（Suppression）**：有意识地推迟处理困难情境 -- **利他（Altruism）**：通过帮助他人处理个人痛苦 - -### 神经质防御（Level 3 - Neurotic） -- **理智化（Intellectualization）**：用理性掩盖情感痛苦 -- **情感隔离（Dissociation）**：将情感与情境分离 -- **反形成（Reaction Formation）**：用相反的情感替代真实感受 - -### 不成熟防御（Level 2 - Immature） -- **投射（Projection）**：将自身不可接受的特质归于他人 -- **否认（Denial）**：拒绝承认现实 -- **退缩（Withdrawal）**：从情境中退出 -- **躯体化（Somatization）**：心理痛苦转化为身体症状 - -### 自恋性防御（Level 1 - Narcissistic） -- **分裂（Splitting）**：将人或情境绝对分为全好或全坏 -- **理想化与贬低（Idealization/Devaluation）**：极端正面或负面评价 - -## Applications -- [[Academic Psychologist Agent]] 识别角色的主要和压力下的防御模式 -- 区分适应性与非适应性防御 -- 理解角色的核心创伤与应对策略 - -## Connections -- [[Academic Psychologist Agent]] ← 分析工具 ← [[Vaillant 防御机制层级]] -- [[George Vaillant]] ← 研究者 ← [[Vaillant 防御机制层级]] diff --git a/wiki/concepts/Vendor-Lock-In.md b/wiki/concepts/Vendor-Lock-In.md deleted file mode 100644 index 0a99ec01..00000000 --- a/wiki/concepts/Vendor-Lock-In.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: "Vendor Lock-In" -type: concept -tags: [Cloud, Risk] -sources: [How-Can-a-Multi-Cloud-Strategy-Transform-Your-Business-ROI] -last_updated: 2025-03-01 ---- - -## Summary -Vendor Lock-In（供应商锁定）是指企业过度依赖单一云服务提供商，导致难以迁移到其他供应商或退回本地部署的状态，会限制企业的灵活性和谈判筹码。 - -## Definition -供应商锁定指企业被锁定在单一云供应商的生态系统中，更换供应商需要付出高昂的迁移成本。这限制了企业的灵活性、增加了风险、并削弱了与供应商的谈判能力。 - -## Why It Matters -- 限制选择权：只能使用该供应商的服务和定价 -- 高迁移成本：数据和应用迁移复杂耗时 -- 风险集中：单一故障点影响整个业务 -- 削弱议价能力：无法有效谈判价格 - -## How Multi-Cloud Addresses It -多云策略通过同时使用多个云提供商，让企业可以根据具体需求选择最佳服务，避免被单一供应商绑定，从而降低锁定风险。 - -## Connections -- [[Vendor Lock-In]] ← mitigated_by ← [[Multi-Cloud]] -- [[Vendor Lock-In]] → relates_to → [[Cloud Adoption]] diff --git a/wiki/concepts/Versioned-Draft.md b/wiki/concepts/Versioned-Draft.md deleted file mode 100644 index 13fa6352..00000000 --- a/wiki/concepts/Versioned-Draft.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "Versioned Draft" -type: concept -tags: [writing, workflow, revision] -sources: [sources/workflow-book-chapter.md] -last_updated: 2026-04-21 ---- - -## 定义 -版本化草稿是通过迭代修订循环产生的带版本号的章节草稿，每一版本基于前版本的编辑注释进行改进。 - -## 核心特征 -- 带版本编号（如 Version 1、Version 2） -- 基于反馈进行渐进改进 -- 记录编辑决策和假设 -- 暴露开放编辑问题供作者决策 - -## 与反馈循环的关系 -版本化草稿依赖反馈循环机制： -- Feedback Loop 提供结构化修订请求 -- Editorial Notes 标注假设和证据缺口 -- Next Step 定义下一版本的改进方向 - -## Aliases -- 版本化草稿 diff --git a/wiki/concepts/Vibe-Coding.md b/wiki/concepts/Vibe-Coding.md deleted file mode 100644 index 73c041d0..00000000 --- a/wiki/concepts/Vibe-Coding.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "Vibe Coding" -type: concept -tags: [ai-coding, workflow] ---- - -## 定义 -一种使用 AI 编程助手的开发方式，开发者通过自然语言描述需求，AI 负责具体的代码实现。 - -## 核心特征 -- 自然语言驱动开发 -- AI 辅助代码生成和修改 -- Plan 模式预先审查实现方案 -- AGENTS.md 记录项目代码模式 - -## 工作流程 -1. 描述需求 → AI 生成实现计划（Plan 模式） -2. 审查计划 → 调整需求或确认方案 -3. 切换到 Build 模式 → AI 执行代码修改 -4. 审查结果 → 可用 /undo 撤销 - -## 工具 -- [[OpenCode]] -- [[Claude Code]] -- [[Ollama]]（本地 LLM） - -## 关联概念 -- [[Plan Mode]] -- [[Build Mode]] -- [[AGENTS.md]] \ No newline at end of file diff --git a/wiki/concepts/View-Page-Source.md b/wiki/concepts/View-Page-Source.md deleted file mode 100644 index eed98141..00000000 --- a/wiki/concepts/View-Page-Source.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: "View Page Source" -type: concept -tags: [浏览器, 开发者工具, 网页] -date: 2026-04-18 ---- - -## Definition -View Page Source（查看网页源代码）是浏览器内置的开发者工具功能，允许用户查看当前网页的 HTML 源代码。 - -## Usage -- 查找隐藏的信息（如 YouTube Channel ID） -- 学习网页设计技术 -- 调试和排查网页问题 - -## How to Use -1. 在网页空白处右键点击 -2. 选择 "View Page Source"（查看网页源代码） -3. 使用 Ctrl+F（或 Cmd+F）搜索关键字 - -## Use Case -获取 YouTube 频道 RSS 订阅源时，在频道页面使用 View Page Source，搜索 "channel_id=" 即可找到对应的 Channel ID。 - -## Related -- [[Channel-ID]]: 可通过 View Page Source 获取 -- [[YouTube]]: 应用场景之一 \ No newline at end of file diff --git a/wiki/concepts/Visual-Coherence-Engine.md b/wiki/concepts/Visual-Coherence-Engine.md deleted file mode 100644 index 2a8c4419..00000000 --- a/wiki/concepts/Visual-Coherence-Engine.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: "Visual Coherence Engine" -type: concept -tags: [ai, image-generation, gemini, branding] -sources: [marketing-carousel-growth-engine] -last_updated: 2026-04-21 ---- - -## Definition -通过 Gemini image-to-image 技术确保 6 张轮播幻灯片视觉一致性的生成系统。 - -## Mechanism -1. **Slide 1**：纯文本 prompt 生成，建立视觉 DNA（颜色、字体、美学） -2. **Slides 2-6**：使用 Slide 1 作为 reference image 输入，通过 Gemini image-to-image 生成，保持视觉一致性 - -## Technical Implementation -- **Model**: `gemini-3.1-flash-image-preview` -- **Input**: `--input-image slide-1.jpg` 作为参考 -- **Output**: 768x1376 JPG 格式（TikTok 要求） - -## Brand Integration -- 通过 Playwright 提取 CSS 颜色并融入 prompt -- 字体样式和大小通过结构化 prompt 保持一致 -- 背景场景叙事性演进同时保持视觉统一 - -## Aliases -- 视觉一致性引擎 -- Image-to-Image Pipeline \ No newline at end of file diff --git a/wiki/concepts/Visual-Identity-System.md b/wiki/concepts/Visual-Identity-System.md deleted file mode 100644 index 147a6ed3..00000000 --- a/wiki/concepts/Visual-Identity-System.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: "Visual Identity System" -type: concept -tags: [brand-strategy, design-system] -date: 2026-04-20 ---- - -## Concept Definition -视觉识别系统是品牌视觉表达的标准化定义，确保跨所有应用的一致性和专业性。 - -## Core Components -1. **Logo System**：标志系统（horizontal、stacked、icon variants） -2. **Color Palette**：色彩系统（primary、secondary、accent、neutral variations） -3. **Typography**：字体系统（primary、secondary、accent、hierarchy） -4. **Spacing System**：间距系统（xs、sm、md、lg、xl） -5. **Pattern Library**：视觉元素模式库 - -## Implementation Standards -- 最小尺寸要求 -- 空白区域要求 -- 无障碍色彩对比（WCAG compliant） -- Web 实现字体加载与 fallback - -## Design Variables Example -```css -:root { - --brand-primary: [hex-value]; - --brand-secondary: [hex-value]; - --brand-accent: [hex-value]; - --brand-font-primary: '[font-name]', [fallbacks]; -} -``` - -## Related Concepts -- [[Brand-Foundation-Framework]]：品牌基础框架 -- [[Brand-Voice]]：品牌声音 -- Brand Consistency：品牌一致性（95%+ 跨触点） \ No newline at end of file diff --git a/wiki/concepts/Vogler-作家旅程.md b/wiki/concepts/Vogler-作家旅程.md deleted file mode 100644 index 928f46b0..00000000 --- a/wiki/concepts/Vogler-作家旅程.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: "Vogler 作家旅程" -type: concept -tags: [narrative-theory, story-structure, screenplay, hero-journey] ---- - -## 定义 -Christopher Vogler 在《作家之旅》中将 Joseph Campbell 的英雄神话理论转化为现代编剧实用框架。 - -## 核心阶段 -1. Ordinary World（普通世界） -2. Call to Adventure（冒险召唤） -3. Refusal of the Call（拒绝召唤） -4. Meeting the Mentor（遇见导师） -5. Crossing the Threshold（跨越门槛） -6. Tests, Allies, Enemies（考验、盟友、敌人） -7. Approach to the Inmost Cave（接近最深处洞穴） -8. Ordeal（严峻考验） -9. Reward（获得奖赏） -10. The Road Back（回归之路） -11. Resurrection（复活） -12. Return with the Elixir（带着灵药回归） - -## 角色原型 -- Hero（英雄） -- Mentor（导师） -- Threshold Guardian（门槛守护者） -- Herald（信使） -- Shapeshifter（变形者） -- Shadow（暗影/对手） -- Trickster（骗徒） - -## 与 [[Campbell 英雄之旅]] 的关系 -Vogler 直接基于 Campbell 的单一神话理论，但针对现代编剧实践进行了调整和优化。 - -## 来源框架 -- [[Narratologist]] 使用此框架进行角色弧线评估和英雄叙事分析 diff --git a/wiki/concepts/Voice-Agent.md b/wiki/concepts/Voice-Agent.md deleted file mode 100644 index a304ff89..00000000 --- a/wiki/concepts/Voice-Agent.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "Voice Agent" -type: concept -tags: [ai-agent, voice-technology] -aliases: [语音代理] ---- - -## Definition -具备语音交互能力的 AI 代理，能够通过语音对话完成任务。在 Event Guest Confirmation 场景中用于自动外呼宾客并收集出席信息。 - -## Context -Voice Agent 与传统语音识别不同，它不仅能听懂语音，还能理解上下文、进行多轮对话、完成复杂任务。典型应用场景包括： -- 活动宾客确认 -- 预约提醒 -- 客户回访 -- 语音客服 - -## Key Characteristics -- 实时语音处理 -- 多轮对话能力 -- 上下文理解 -- 任务导向对话 - -## Related -- [[OpenClaw]] -- [[SuperCall]] -- [[Event Guest Confirmation]] \ No newline at end of file diff --git a/wiki/concepts/Voice-of-Customer.md b/wiki/concepts/Voice-of-Customer.md deleted file mode 100644 index a687be73..00000000 --- a/wiki/concepts/Voice-of-Customer.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: "Voice of Customer" -type: concept -tags: [Customer Research, Qualitative Analysis] -sources: [] -last_updated: 2026-04-20 ---- - -## Definition -Voice of Customer（用户之声，简称VoC）是一种系统性收集、分析和解释客户反馈的研究方法，将分散的定性反馈转化为可操作的洞察。 - -## Components -- **原文汇编（Verbatim Compilation）**：按主题汇编代表性引述 -- **故事开发（Story Development）**：用户旅程叙事与情感映射 -- **边缘案例识别（Edge Case Identification）**：识别不常见但关键的反饴 -- **情感映射（Emotional Mapping）**：用户挫败和愉悦点的强度评分 - -## Analysis Methods -- 主题分析（Thematic Analysis）：跨反馈源的模式识别 -- 统计相关性（Statistical Correlation）：主题与业务指标的定量关系 -- 用户旅程映射（User Journey Mapping）：反馈整合到体验流 - -## Usage -Voice of Customer 是 [[Product Feedback Synthesizer]] 的核心能力之一，专注于从定性反馈中提取洞察并转化为产品决策依据。 - -## Connections -- [[Product Feedback Synthesizer]]：核心分析方法 -- [[情感分析]]：NLP驱动的情绪检测 -- [[RICE评分]]：基于洞察的优先级排序 diff --git a/wiki/concepts/WAF.md b/wiki/concepts/WAF.md deleted file mode 100644 index 519ffb4f..00000000 --- a/wiki/concepts/WAF.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: "WAF (Web Application Firewall)" -type: concept -tags: - - Security - - AWS - - Web-Protection -date-added: 2026-04-18 ---- - -## Description -Web Application Firewall（WAF）是一种保护 Web 应用免受常见攻击（如 SQL 注入、跨站脚本、XSS 等）的安全服务。在 SaaS Landing Zone 中，WAF 监控传入产品账号的流量。 - -## Role in SaaS Landing Zone -- 监控 Product Accounts 的入站流量 -- 防护 Web 应用免受常见攻击 -- 可与 CloudFront 集成实现端到端安全 - -## Related -- [[AWS]]：云服务提供商 -- [[CloudFront]]：CDN 服务 -- [[ctp-topic-7-saas-landing-zone-design]]：SaaS Landing Zone 设计 \ No newline at end of file diff --git a/wiki/concepts/WCAG-2-2.md b/wiki/concepts/WCAG-2-2.md deleted file mode 100644 index 00695385..00000000 --- a/wiki/concepts/WCAG-2-2.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: "WCAG 2.2" -description: Web Content Accessibility Guidelines 2.2，网页内容无障碍指南的国际标准 -tags: [accessibility, standards, wcag] ---- - -## Definition -WCAG 2.2（Web Content Accessibility Guidelines 2.2）是 W3C 发布的网页内容无障碍指南标准，是国际公认的网站无障碍设计规范。最新版本于 2023 年 10 月正式发布。 - -## POUR Principles（四大原则） -### Perceivable（可感知） -- 所有信息都必须以用户可感知的方式呈现 -- 包括文本替代、字幕、放大功能等 - -### Operable（可操作） -- 所有功能都必须可以通过键盘操作 -- 不能依赖特定设备或输入方式 - -### Understandable（可理解） -- 信息和操作必须是可理解的 -- 避免歧义，提供清晰的错误提示 - -### Robust（健壮） -- 内容必须能被各种用户代理可靠解释 -- 包括辅助技术和未来兼容性 - -## Conformance Levels -- **Level A**：最低要求，必须满足 -- **Level AA**：标准要求，大多数合规标准以此为准 -- **Level AAA**：最高要求，适用于特定场景 - -## Key Success Criteria -- 1.4.3 Contrast Minimum（对比度最低 4.5:1） -- 2.1.1 Keyboard（所有功能可键盘操作） -- 2.4.7 Focus Visible（焦点可见性） -- 4.1.2 Name, Role, Value（名称、角色、值可机器读取） - -## Related Concepts -- [[Screen Reader Testing]] -- [[Keyboard Navigation Audit]] -- [[POUR Principles]] - -## Source -- [[Accessibility Auditor]] -- W3C WCAG 2.2 Official \ No newline at end of file diff --git a/wiki/concepts/WOL-Wake-on-LAN.md b/wiki/concepts/WOL-Wake-on-LAN.md deleted file mode 100644 index 68398cc5..00000000 --- a/wiki/concepts/WOL-Wake-on-LAN.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "WOL (Wake on LAN)" -type: concept -tags: [network, power-management, lan] -date: 2026-04-17 ---- - -## Definition -WOL (Wake on LAN，网络唤醒) 是一种允许通过网络信号唤醒处于睡眠或关机状态计算机的技术。用户可以通过发送特殊的魔术数据包（Magic Packet）到目标设备的 MAC 地址，实现远程唤醒。 - -## Technical Details -- **魔术数据包**：包含目标设备 MAC 地址的特殊 UDP 数据包，发送到端口 9 -- **MAC 地址格式**：如 `XX:XX:XX:XX:XX:XX` -- **默认端口**：9（UDP） - -## macOS Configuration -```bash -# 启用网络唤醒 -sudo pmset -a womp 1 - -# 验证是否启用 -pmset -g | grep womp -``` - -## Use Cases -- 远程唤醒家庭服务器（如 Mac Mini） -- 远程桌面连接前先唤醒目标机器 -- 节约能源，按需唤醒不在使用的机器 - -## Related Concepts -- [[pmset]]：电源管理工具，可启用 WOL -- [[caffeinate]]：临时保持唤醒的工具 \ No newline at end of file diff --git a/wiki/concepts/WSJF.md b/wiki/concepts/WSJF.md deleted file mode 100644 index 82d7f8ae..00000000 --- a/wiki/concepts/WSJF.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: "WSJF (Weighted Shortest Job First)" -type: concept -tags: [Prioritization, CTP, Value-Delivery] -last_updated: 2026-04-19 ---- - -## Definition -WSJF（加权最短作业优先）是一种用于序列 CTP（云转型计划）工作的优先级排序方法，基于成本效益最大化原则。 - -## Formula -``` -WSJF = (业务价值 + 时间关键性 + 风险与机会) / 作业规模 -``` - -## Components -- **业务价值 (Business Value)**：收入增加、成本降低、风险改善 -- **时间关键性 (Time Criticality)**：工作的时间敏感性 -- **风险与机会 (Risk & Opportunity)**：潜在风险和机会评估 -- **作业规模 (Size of Job)**：完成工作所需的 effort - -## Application -用于在多个需求之间进行优先级排序，以实现： -- 最小 effort 实现最大 value -- 早期价值交付回业务 -- 最大化经济利益 - -## Connections -- [[WSJF]] ← prioritizes ← [[CTP]] -- [[Demand Manager]] ← provides ← [[Business Value]] -- [[Delivery Manager]] ← estimates ← [[Size of Job]] - -## Aliases -- Weighted Shortest Job First -- Cost of Delay \ No newline at end of file diff --git a/wiki/concepts/WSL.md b/wiki/concepts/WSL.md deleted file mode 100644 index c7b56180..00000000 --- a/wiki/concepts/WSL.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "WSL" -type: concept -tags: [] -last_updated: 2026-04-18 ---- - -## Summary -- Windows Subsystem for Linux（Windows Linux 子系统），Microsoft 开发的在 Windows 上运行 Linux 发行版的兼容层 -- 允许开发者直接在 Windows 上使用 Linux 工具、实用程序和 Bash，无需传统虚拟机或双系统启动 - -## Key Features -- 与 Windows 无缝集成，文件系统共享 -- 支持多个 Linux 发行版（Ubuntu、Debian、SUSE、Kali 等） -- 可通过 Windows Terminal 管理 -- 直接调用 Windows 程序 - -## Versions -- WSL 1：一代架构，Linux 系统调用转换为 Windows API -- WSL 2：二代架构，使用轻量级虚拟机，运行完整 Linux 内核，性能更优 - -## Installation -- Windows 10 2004+ 或 Windows 11：使用 `wsl --install` 一键安装 -- 老版本：手动安装，需启用"适用于 Linux 的 Windows 子系统"可选组件 - -## Commands -- `wsl --install`：一键安装（默认 Ubuntu） -- `wsl -l -v`：列出已安装发行版 -- `wsl --set-version <1|2>`：设置版本 -- `wsl -d `：启动指定发行版 - -## Connections -- [[Ubuntu]] ← default_distro ← [[WSL]] -- [[WSL2]] ← extends ← [[WSL]] -- [[Windows Terminal]] ← manages ← [[WSL]] -- [[PowerShell]] ← invokes ← [[WSL]] - -## Wiki Connections -- [[Install WSL]] → describes → [[WSL]] -- [[WSL2 启动与网络配置指南]] → describes → [[WSL2]] \ No newline at end of file diff --git a/wiki/concepts/WSL2.md b/wiki/concepts/WSL2.md deleted file mode 100644 index 22e696b5..00000000 --- a/wiki/concepts/WSL2.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: WSL2 -type: concept -tags: [windows, linux, subsystem] ---- - -## Definition -Windows Subsystem for Linux 2（WSL2）是 Microsoft 提供的 Windows 10/11 上的 Linux 兼容层，基于 Hyper-V 虚拟化技术，提供完整的 Linux 内核。 - -## Core Features -- 真正的 Linux 内核（而非 WSL1 的翻译层） -- 系统调用兼容性大幅提升 -- 性能接近原生 Linux -- 与 Windows 文件系统无缝集成 - -## Key Commands -- `wsl --install` — 快速安装 WSL2（含 Ubuntu） -- `wsl -l -v` — 查看已安装分发版及状态 -- `wsl -d <分发版名称>` — 启动指定 Linux 发行版 -- `wsl --shutdown` — 强制停止所有 WSL 实例 - -## Network Configuration -WSL2 默认使用 NAT 模式，可通过 .wslconfig 启用镜像网络模式解决代理问题。 - -## Aliases -- Windows Subsystem for Linux -- WSL -- WSL 2 - -## Related Concepts -- [[镜像网络模式]] -- [[.wslconfig]] -- [[Ubuntu]] \ No newline at end of file diff --git a/wiki/concepts/WSP-Protocol.md b/wiki/concepts/WSP-Protocol.md deleted file mode 100644 index 29b2d62e..00000000 --- a/wiki/concepts/WSP-Protocol.md +++ /dev/null @@ -1,16 +0,0 @@ ---- -title: "WSP Protocol" -type: concept -tags: [] ---- - -## Definition -Workspaces Streaming Protocol，AWS Workspaces 专用的桌面流协议。专为高延迟网络环境设计，优化远程桌面的用户体验。 - -## Characteristics -- 专为高延迟网络优化 -- 支持剪贴板、摄像头、智能卡等外设 -- 适用于远程工作和分布式团队 - -## Related Entities -- [[AWS-Workspaces]] \ No newline at end of file diff --git a/wiki/concepts/Wayland.md b/wiki/concepts/Wayland.md deleted file mode 100644 index 926f0e43..00000000 --- a/wiki/concepts/Wayland.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: "Wayland" -type: concept -tags: [display-protocol, linux, wayland] -last_updated: 2026-04-17 ---- - -## Description -Linux 桌面环境的现代显示协议，作为 X11 的继任者设计，提供更好的安全性和性能。 - -## Key Characteristics -- 相比 X11 更加安全，限制客户端之间的隔离 -- 默认用于 Ubuntu 24.04 -- 出于安全设计，严格限制外部程序在用户未登录状态下获取屏幕控制权 - -## Relationship to Other Concepts -- 继任者：[[X11 (Xorg)]] -- 兼容：[[GDM3]]（登录管理器） -- 远程桌面问题：RustDesk 在 Wayland 下无法在登录界面正常工作 \ No newline at end of file diff --git a/wiki/concepts/Weak-Signal-Detection.md b/wiki/concepts/Weak-Signal-Detection.md deleted file mode 100644 index 5a2147c0..00000000 --- a/wiki/concepts/Weak-Signal-Detection.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: "Weak Signal Detection" -type: concept -tags: [early-detection, foresight, trend-identification] -sources: [raw/Agent/agency-agents/product/product-trend-researcher.md] -last_updated: 2026-04-20 ---- - -## Definition -弱信号检测是在信号尚处于早期微弱阶段时识别新兴趋势的能力，是领先竞争对手 3-6 个月的关键。 - -## Signal Categories -- **Weak Signal（弱信号）**：早期微弱迹象，需要验证 -- **Moderate Signal（中信号）**：趋势初步确认 -- **Strong Signal（强信号）**：趋势明确，主流开始关注 - -## Detection Methods -- 跨行业模式分析 -- 弱信号统计验证 -- 专家意见交叉验证 -- 数据三角测量 - -## Success Metrics -- 领先主流采用 3-6 个月 -- 6个月预测准确率 ≥80% -- 置信区间明确量化 diff --git a/wiki/concepts/WebXR.md b/wiki/concepts/WebXR.md deleted file mode 100644 index d3ca69ab..00000000 --- a/wiki/concepts/WebXR.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "WebXR" -type: concept -tags: [xr, webxr, standard, api] -date: 2026-04-20 ---- - -## Definition -WebXR Device API 是 W3C 制定的浏览器标准接口，用于提供沉浸式虚拟现实（VR）和增强现实（AR）体验。 - -## Core Attributes -- 浏览器原生支持 -- 跨平台兼容性 -- 手势追踪输入 -- 头部追踪和空间定位 - -## Related Concepts -- [[Spatial Computing]]：应用场景 -- [[Immersive-Cockpit]]：应用模式 - -## Related Entities -- [[A-Frame]]：WebXR 框架 -- [[Three.js]]：3D 渲染库 -- [[Babylon.js]]：3D 引擎 - -## Application -浏览器端 VR/AR 应用、沉浸式游戏、XR 培训体验 \ No newline at end of file diff --git a/wiki/concepts/Webhook.md b/wiki/concepts/Webhook.md deleted file mode 100644 index 4dfd8d69..00000000 --- a/wiki/concepts/Webhook.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "Webhook" -type: concept -tags: [n8n, trigger, http] -date: 2026-04-17 ---- - -## Definition -n8n 接收外部 HTTP POST 请求的触发器，使工作流能够响应来自外部系统的请求。 - -## How It Works -1. 在 n8n 工作流中添加 Webhook 触发器节点 -2. 配置唯一的工作流路径（如 `webhook/my-workflow`） -3. 外部系统通过 `POST http://n8n:5678/webhook/my-workflow` 发起请求 -4. n8n 接收 JSON payload 并执行工作流 - -## Use Cases -- AI Agent 调用外部 API（通过 webhook 代理） -- 接收 GitHub/GitLab Webhook 通知 -- 接收表单提交 -- 接收 Twilio/SendGrid 等服务的回调 - -## Aliases -- Webhook Trigger -- Incoming Webhook \ No newline at end of file diff --git a/wiki/concepts/What-If-Simulations.md b/wiki/concepts/What-If-Simulations.md deleted file mode 100644 index b4f15e83..00000000 --- a/wiki/concepts/What-If-Simulations.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: "What-If Simulations" -type: concept -tags: [simulation, decision-support, AI] -sources: [How-Agentic-AI-can-help-for-Cloud-DevOps] -last_updated: 2026-04-16 ---- - -## Summary -What-If Simulations（假设模拟）是 AI 辅助的决策支持工具，帮助预测架构变更、迁移决策对性能、成本和合规性的影响。 - -## Definition -在实施变更前，通过 AI 模拟不同场景，预测云迁移、实例类型变更或架构调整的结果。 - -## Key Applications -- **云迁移模拟**：预测迁移到不同云平台的影响 -- **实例类型变更**：评估更换实例类型的效果 -- **架构重构影响**：评估微服务拆分/合并的影响 -- **成本影响分析**：预测变更的成本影响 - -## Example -模拟将 AWS SaaS 应用迁移到 GCP 私有云对性能、成本和合规性的影响。 - -## Connections -- [[Agentic AI]] ← implements ← [[What-If Simulations]]：Agentic AI 实现假设模拟 -- [[Cloud Migration]] ← supports ← [[What-If Simulations]]：假设模拟支持云迁移决策 diff --git a/wiki/concepts/Whimsy-Taxonomy.md b/wiki/concepts/Whimsy-Taxonomy.md deleted file mode 100644 index 25b342c4..00000000 --- a/wiki/concepts/Whimsy-Taxonomy.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: "Whimsy Taxonomy" -type: concept -tags: [] ---- - -## Definition -品牌体验中趣味元素的分类体系，将趣味设计分为四个层次：微妙趣味、交互式趣味、发现式趣味、情境式趣味。 - -## Categories -- **Subtle Whimsy（微妙趣味）**：不干扰用户的轻量级趣味，如悬停效果、加载动画、按钮反馈 -- **Interactive Whimsy（交互式趣味）**：用户触发的愉悦交互，如点击动画、表单验证庆祝、进度奖励 -- **Discovery Whimsy（发现式趣味）**：隐藏元素奖励探索，如彩蛋、键盘快捷键、秘密功能 -- **Contextual Whimsy（情境式趣味）**：场景适配的幽默和趣味，如 404 页面、空状态、季节主题 - -## Implementation Principles -- 每个趣味元素必须服务功能或情感目的 -- 趣味设计必须包容无障碍（支持屏幕阅读器、减少运动偏好） -- 品牌个性应贯穿全光谱（专业场景→休闲场景） -- 趣味元素需性能优化，不能影响页面加载速度 - -## Related Concepts -- [[Micro-Interaction]] -- [[Easter Egg]] -- [[Gamification]] - -## Sources -- [[design-whimsy-injector]] \ No newline at end of file diff --git a/wiki/concepts/Win-Theme.md b/wiki/concepts/Win-Theme.md deleted file mode 100644 index 1593eaa5..00000000 --- a/wiki/concepts/Win-Theme.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: "Win Theme" -type: concept -tags: [Proposal, Sales, Strategy] -last_updated: 2026-04-20 ---- - -## Definition -制胜主题（Win Theme）是连接解决方案与买家最紧迫需求的核心陈述，是提案叙事的骨架。每个提案需要 3-5 个制胜主题，必须在执行摘要、解决方案叙事、案例研究和定价说明中贯穿出现。 - -## Core Principles -- 命名买家的具体挑战，而非通用行业问题 -- 将具体能力与可衡量结果关联 -- 无需提及竞争对手即可实现差异化 -- 可通过证据、案例研究或方法论证明 - -## Structure -每个制胜主题包含： -- **Buyer Need**：RFP 或发现阶段确定的特定挑战 -- **Our Differentiator**：能力、方法论或资产 -- **Proof Point**：指标、案例研究或证据 -- **Sections Where Appears**：主题出现的章节列表 - -## Example -- **Weak**: "We have deep experience in digital transformation" -- **Strong**: "Our migration framework reduces cutover risk by staging critical workloads in parallel — the same approach that kept [similar client] at 99.97% uptime during a 14-month platform transition" - -## Connections -- [[Win Theme]] ← core_concept_of ← [[Proposal Strategy]] -- [[Win Theme]] ← enables ← [[Competitive Positioning]] -- [[Win Theme]] ← integrated_into ← [[Executive Summary]] \ No newline at end of file diff --git a/wiki/concepts/Workflow-Architecture.md b/wiki/concepts/Workflow-Architecture.md deleted file mode 100644 index 427157da..00000000 --- a/wiki/concepts/Workflow-Architecture.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: "Workflow Architecture" -type: concept -tags: [workflow-design, systems-design, process-engineering] -sources: [specialized-workflow-architect] -last_updated: 2026-04-20 ---- - -## Definition -Workflow Architecture 是一种把系统行为建模为工作流树的方法：先发现入口，再定义每一步的成功条件、失败分支、恢复动作、可观察状态和清理责任。 - -## Core Principles -- 先发现，再设计 -- 先 happy path，再分支 -- 每个步骤都必须有 timeout -- 每个失败都必须有 recovery path -- 每个资源都必须进入 cleanup inventory -- 每个交接都必须有明确 contract -- 每个 spec 都必须接受现实验证 - -## Key Building Blocks -- Workflow Registry：系统中所有工作流的权威清单 -- Handoff Contract：系统边界的 payload / response / timeout / recovery 定义 -- Observable States：客户、操作员、数据库、日志的状态定义 -- ABORT_CLEANUP：失败后的逆向销毁流程 -- Reality Checker：将 spec 与实际实现对齐的验证步骤 - -## Related Entities -- [[Workflow Architect]] -- [[The Agency]] - -## Related Concepts -- [[Claude Skills]] -- [[Process Optimization]] -- [[AI-powered Runbooks]] -- [[Document Generation]] diff --git a/wiki/concepts/Workload-Optimization.md b/wiki/concepts/Workload-Optimization.md deleted file mode 100644 index ce4494c1..00000000 --- a/wiki/concepts/Workload-Optimization.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "Workload Optimization" -type: concept -tags: [cloud, cost-management, AWS] -sources: [public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco] -last_updated: 2026-04-19 ---- - -## Summary -Workload Optimization（工作负载优化）是通过现代化和 Right Sizing 优化资源配置以降低云成本的实践。 - -## Definition -工作负载优化涵盖两个主要方向：现代化（使用新一代服务）和 Right Sizing（调整资源规格匹配实际需求）。 - -## Key Techniques -- **现代化（Modernization）**：使用新一代服务实例 - - Intel 迁移到 AMD：节省 6-10% 按需价格 - - 迁移到 Graviton：节省 20-25% 按需价格 - - GP2 升级到 GP3：直接节省 20% 存储成本 - - EKS 集群升级到最新版本：避免高额扩展支持费用 - -- **Right Sizing**：根据实际需求调整资源配置 - - EC2 Right Sizing 推荐报告 - - 实例调度（非生产环境按需开关） - - 闲置资源清理 - -## Connections -- [[FinOps]] ← enables ← [[Workload Optimization]]：FinOps 推动工作负载优化 -- [[Cost Optimization]] ← implements ← [[Workload Optimization]]：工作负载优化是成本优化的一部分 -- [[Rate Optimization]] ← combines_with ← [[Workload Optimization]]：与费率优化配合实现最大节省 \ No newline at end of file diff --git a/wiki/concepts/Workspace.md b/wiki/concepts/Workspace.md deleted file mode 100644 index 55638dd0..00000000 --- a/wiki/concepts/Workspace.md +++ /dev/null @@ -1,55 +0,0 @@ ---- -title: "Workspace" -type: concept -tags: [OpenClaw, Agent] ---- - -## 定义 -Workspace 是 OpenClaw 中 Agent 的工作台目录，包含决定 Agent 如何工作的配置文件体系。默认路径为 `~/.openclaw/workspace/`（主 Agent 和 sub-agent 都适用）。 - -## 目录结构 -``` -~/.openclaw/ -├── openclaw.json # 总控配置，整个系统的"宪法" -├── workspace/ # 默认情况下主 Agent 的工作区 -│ ├── AGENTS.md # Agent 的行为规则与多Agent协调 -│ ├── SOUL.md # Agent 的叙事性格设定 -│ ├── USER.md # 用户画像与偏好 -│ ├── IDENTITY.md # Agent 身份元数据 -│ ├── TOOLS.md # 工具权限声明与使用规范 -│ ├── HEARTBEAT.md # 会话节奏/状态提示 -│ ├── BOOTSTRAP.md # 首次启动引导（完成后删除） -│ ├── BOOT.md # 启动检查清单 -│ ├── MEMORY.md # 长期知识总表 -│ ├── memory/ # 按日期滚动的记忆笔记 -│ ├── skills/ # 技能包目录 -│ └── canvas/ # 画布/可视化上下文 -└── agents/ # 各 Agent 的运行态目录 -``` - -## 核心文件职责 -| 文件 | 职责 | -|------|------| -| AGENTS.md | 岗位说明书——做什么、不该做什么 | -| SOUL.md | 性格档案——是谁、什么风格 | -| USER.md | 用户偏好——用户是什么样、喜欢什么 | -| IDENTITY.md | 身份元数据——名字、emoji、头像 | -| TOOLS.md | 工具规范——工具权限和使用原则 | -| BOOTSTRAP.md | 初始化引导——一次性使用后删除 | -| memory/ | 长期记忆——跨会话积累 | - -## 关键区分 -- **workspace**：管"这个 Agent 平时怎么干活" -- **openclaw.json**：管"这个系统怎么把它跑起来" -- **agentDir**：openclaw.json 里的一个配置字段，指向存放运行状态的目录 -- **sessions**：工作日志，记对话历史 - -## 价值 -workspace 这套文件体系，解决的核心问题是：**怎么让 Agent 从"能工作"变成"好用"**。配合好了，Agent 不再是每次都要重新 onboarding 的陌生人，而是一个真正懂你、记得你、靠谱的长期搭档。 - -## 来源 -- [[万字讲透OpenClaw🦞从"能用"到"真好用"的分水岭：Workspace 深度解析]] - -## 相关 -- [[OpenClaw]]：包含 workspace 的 AI Agent 管理工具 -- [[AGENTS.md]]、[[SOUL.md]]、[[USER.md]]、[[IDENTITY.md]]、[[TOOLS.md]]、[[BOOTSTRAP.md]]、[[Memory 目录]] \ No newline at end of file diff --git a/wiki/concepts/X11-Xorg.md b/wiki/concepts/X11-Xorg.md deleted file mode 100644 index ae8419dc..00000000 --- a/wiki/concepts/X11-Xorg.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "X11 (Xorg)" -type: concept -tags: [display-protocol, linux, x11] -last_updated: 2026-04-17 ---- - -## Aliases -- X11 -- Xorg -- X Window System - -## Description -传统的 Linux 显示协议，Ubuntu 早期版本默认使用，现在可作为 Wayland 的替代方案。 - -## Key Characteristics -- 兼容性更好，支持更多远程桌面软件 -- 允许外部程序在登录界面获取屏幕控制权 -- 通过 GDM3 配置可强制使用 X11 替代 Wayland - -## Configuration -在 /etc/gdm3/custom.conf 中设置： -``` -[daemon] -WaylandEnable=false -``` - -## Relationship to Other Concepts -- 前身：传统 X11 -- 替代：[[Wayland]] -- 兼容：[[GDM3]] -- 远程桌面：支持 [[RustDesk]] 正常工作 \ No newline at end of file diff --git a/wiki/concepts/Xinchuang.md b/wiki/concepts/Xinchuang.md deleted file mode 100644 index 51ff19e7..00000000 --- a/wiki/concepts/Xinchuang.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: "Xinchuang" -type: concept -tags: [domestic-it, government-it, compliance] -last_updated: 2026-04-20 ---- - -## Definition -Xinchuang（信息技术应用创新）指围绕国产 CPU、国产操作系统、国产数据库和国产中间件等进行的软硬件国产化替代与适配工作。 - -## Core Points -- 常见组合包括 Kunpeng、Phytium、Loongson、UOS、Kylin、DM8、KingbaseES 等 -- 需要先做兼容性测试，再逐步迁移替换 -- 重点是“可用、可管、可持续”，而不是一次性全量替换 -- 常与政府采购和等级保护、密码应用要求一起出现 - -## Related Concepts -- [[Government Procurement]] -- [[Digital Government]] -- [[Compliance Enforcement]] - -## Related Entities -- [[Government Digital Presales Consultant]] diff --git a/wiki/concepts/Xray.md b/wiki/concepts/Xray.md deleted file mode 100644 index 3a1b9555..00000000 --- a/wiki/concepts/Xray.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -id: xray -title: Xray -type: concept -tags: [proxy, protocol, security] -sources: [] -last_updated: 2026-04-16 ---- - -## Summary -- 定义：多功能代理软件，支持 VMESS、VLESS、Trojan、Shadowsocks 等多种协议 -- 作用：提供科学上网服务，支持流量转发和加密传输 - -## Key Facts -- 基于 V2Ray 项目发展而来 -- 支持 VLESS + Reality 组合，可实现无 TLS 特征的 TLS 伪装 -- 支持流量统计和规则分流 -- 支持多种入站和出站协议 diff --git a/wiki/concepts/Y-Combinator.md b/wiki/concepts/Y-Combinator.md deleted file mode 100644 index 9f691a27..00000000 --- a/wiki/concepts/Y-Combinator.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: "Y Combinator" -type: concept -tags: [] ---- - -## Definition -Y 不动点组合子（Y Combinator），λ 表达式为：Y ≡ λf.(λx.f(x,x))(λx.f(x,x))。用于在 λ-calculus 中表达递归。 - -## Context -在递归自优化生成系统的 λ-calculus 形式化中，Y 组合子用于表达稳定生成器的自引用本质： -- STEP ≡ λG. (M G) ((O (G I)) Ω) -- G* ≡ Y STEP - -这使得生成器被定义为转换生成器的函数的不动点，显式表达了自引用性质。 - -## Related Concepts -- [[Fixed Point]] -- [[Self-Map]] -- [[Recursive Self-Optimizing Generative Systems]] \ No newline at end of file diff --git a/wiki/concepts/YouTube-Digest.md b/wiki/concepts/YouTube-Digest.md deleted file mode 100644 index ea83c4bb..00000000 --- a/wiki/concepts/YouTube-Digest.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "YouTube Digest" -type: concept -tags: [agent-workflow, automation] -date: 2026-04-17 ---- - -## Source -- [[raw/Agent/usecases/daily-youtube-digest.md]] - -## Definition -AI Agent 自动从订阅的 YouTube 频道获取最新视频并生成每日摘要的工作流。 - -## When to Use -- 每天早晨获取感兴趣频道的更新 -- 追踪特定关键词相关的新视频 -- 替代不可靠的 YouTube 官方通知 - -## How It Works -1. 使用 youtube-full skill 的 `channel/latest` 获取频道最新视频 -2. 获取视频 Transcript（消耗积分） -3. 用 AI 总结要点 -4. 推送 digest（每日定时或按需） - -## Related Concepts -- [[Agent-Chain]]：多个 Agent 串联工作 -- [[TranscriptAPI]]：视频转录服务 \ No newline at end of file diff --git a/wiki/concepts/Zero-Trust-Access.md b/wiki/concepts/Zero-Trust-Access.md deleted file mode 100644 index 439e916d..00000000 --- a/wiki/concepts/Zero-Trust-Access.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -title: "Zero Trust Access" -type: concept -tags: - - Security - - AWS ---- - -## Definition -零信任访问（Zero Trust Access）是一种安全框架，遵循"永不信任、始终验证"原则，每次访问请求都需经过身份验证和授权，无论请求来自网络内部还是外部。 - -## Application -在 AWS Landing Zone 中，通过 SSM 实现零信任访问：用户需扮演 IAM 角色获得目标 EC2 实例的 SSM agent 访问权限，依赖现有访问控制并启用双因素认证。 - -## Related Concepts -- [[SSM-Access]] -- [[AWS-Landing-Zone]] -- [[Break-Glass-Access]] \ No newline at end of file diff --git a/wiki/concepts/Zero-Trust-Architecture.md b/wiki/concepts/Zero-Trust-Architecture.md deleted file mode 100644 index da34bef0..00000000 --- a/wiki/concepts/Zero-Trust-Architecture.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: "Zero Trust Architecture" -type: concept -tags: [Security, Cloud, Network] -sources: [modern-itsm-driving-efficiency-security-resilience] -last_updated: 2026-04-16 ---- - -## Summary -Zero Trust Architecture（零信任架构）是一种安全框架，假设网络内部和外部都不可信，要求持续验证。 - -## Definition -Zero Trust Architecture（零信任架构）是一种安全模型，主张"永不信任，始终验证"。它要求对所有用户、设备和应用程序进行持续身份验证和授权，无论它们是在网络内部还是外部。ZTA 遵循最小权限原则，只授予用户完成任务所需的最低访问权限。 - -## Key Attributes -- **核心原则**：永不信任、始终验证、最小权限 -- **关键技术**：微隔离、身份和访问管理（IAM）、多因素认证（MFA）、设备信任 -- **与 ITSM 结合**：AI 驱动的威胁情报、自动化风险评分 - -## Why -- 传统边界防护失效：云原生和远程工作打破传统网络边界 -- 横向移动风险：攻击者获取初始访问后可横向移动 -- 合规要求：满足 ISO 27001、PCI-DSS 等安全标准 - -## Connections -- [[Cloud Security]] ← 增强 ← [[Zero Trust Architecture]] -- [[ITSM]] ← 保护 ← [[Zero Trust Architecture]] -- [[Policy-as-Code]] ← 实现 ← [[Zero Trust Architecture]] \ No newline at end of file diff --git a/wiki/concepts/Zettelkasten.md b/wiki/concepts/Zettelkasten.md deleted file mode 100644 index 228c5014..00000000 --- a/wiki/concepts/Zettelkasten.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "Zettelkasten" -type: concept -tags: [knowledge-management, methodology] -date: 2026-04-19 ---- - -## Summary -- 定义：卢曼卡片盒知识管理系统，通过原子化笔记和索引入口构建知识网络 -- 核心：笔记作为独立知识单元，可被多个索引指向，发现路径而非分类体系 - -## Key Principles -- 原子性：每条笔记可独立理解 -- 连接性：每条笔记至少2个有意义链接 -- 有机增长：避免过度结构化 -- 持续对话：激发进一步思考 - -## Implementation -- [[ZK Steward]]：AI 时代的 Zettelkasten 实现 - -## Connections -- [[Zettelkasten]] ← invented_by ← [[Niklas Luhmann]] -- [[ZK Steward]] ← implements ← [[Zettelkasten]] -- [[Claude Skills]] ← parallels ← [[Zettelkasten]] \ No newline at end of file diff --git a/wiki/concepts/Zod参数验证.md b/wiki/concepts/Zod参数验证.md deleted file mode 100644 index 09179d36..00000000 --- a/wiki/concepts/Zod参数验证.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -title: "Zod参数验证" -type: concept -tags: [typescript, validation, mcp] -date: 2026-04-20 ---- - -## Definition -在 TypeScript MCP Server 中使用 Zod 为工具参数提供运行时类型验证与约束。 - -## Key Points -- 在工具边界做验证 -- 为枚举、默认值、范围限制提供清晰 schema -- 避免把未验证参数传入外部 API - -## Connections -- [[MCP Builder]] -- [[MCP服务器]] diff --git a/wiki/concepts/arxiv-reader-skill.md b/wiki/concepts/arxiv-reader-skill.md deleted file mode 100644 index 72e6db02..00000000 --- a/wiki/concepts/arxiv-reader-skill.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: "arxiv-reader skill" -type: concept -tags: [agent, skill, arxiv, research] -last_updated: 2025-04-17 ---- - -## Definition -Prismer 项目提供的 arXiv 论文读取 skill，包含三个核心工具：arxiv_fetch（获取全文）、arxiv_sections（列出章节）、arxiv_abstract（获取摘要）。 - -## Key Features -- 直接从 arXiv 下载论文源码，自动解压并扁平化 LaTeX -- 按章节浏览，避免一次性加载全文 -- 批量摘要对比，多论文筛选 -- 本地缓存，重复访问秒级响应 - -## Dependencies -- Node.js（无需 Docker 或 Python） - -## Use Cases -- 学术论文阅读助手 -- 研究文献调研 -- 跨论文对比分析 \ No newline at end of file diff --git a/wiki/concepts/audio-overviews.md b/wiki/concepts/audio-overviews.md deleted file mode 100644 index 86702c7a..00000000 --- a/wiki/concepts/audio-overviews.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -id: audio-overviews -title: "Audio Overviews" -type: concept -tags: [AI, audio, learning] -sources: [] -last_updated: 2025-04-18 ---- - -## Definition -NotebookLM 将文档转化为双人 AI 对话播客的功能，适合被动学习场景。 - -## How It Works -1. 用户上传文档到 Notebook -2. 选择 Audio Overview 功能 -3. AI 生成两个虚拟主持人对话 -4. 可下载或在线播放 - -## Features -- **双人对话**：两个 AI 声音进行深入讨论 -- **风格可调**：可选择评论、辩论、简报等风格 -- **自定义指令**：可指定主持人扮演特定角色 -- **多语言**：支持多语言内容生成 - -## Use Cases -- 通勤时学习 -- 做家务时听 -- 健身时听 -- 睡前学习 - -## Advantages -- **被动学习**：不占用视觉和手部 -- **时间复用**：将碎片时间转化为学习时间 -- **深入浅出**：将复杂文档转化为易懂的对话 -- **个性化**：可定制对话风格和重点 - -## Comparison with TTS -| 特性 | Audio Overviews | 普通 TTS | -|------|---------------|----------| -| 内容理解 | 深入理解后转化 | 仅语音合成 | -| 对话形式 | 双人对话 | 单人朗读 | -| 风格可选 | 多风格可调 | 固定风格 | -| 引用支持 | 有 | 无 | - -## Related Concepts -- [[Source-grounding]] -- [[AI配音]] - -## Aliases -- NotebookLM Audio -- AI Podcast \ No newline at end of file diff --git a/wiki/concepts/cAdvisor.md b/wiki/concepts/cAdvisor.md deleted file mode 100644 index 5d33603f..00000000 --- a/wiki/concepts/cAdvisor.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: "cAdvisor" -type: concept -tags: [container, monitoring, prometheus, docker] -sources: [家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox] -last_updated: 2026-04-16 ---- - -## Definition -cAdvisor（Container Advisor）是 Google 开发的容器指标采集器，实时采集容器（Docker）的资源使用和性能数据，提供容器级别的监控。 - -## Key Metrics -- **CPU**：CPU 使用率、限制、throttling -- **内存**：使用量、限制、缓存 -- **网络**：入站/出站流量、丢包 -- **文件系统**：容器日志大小 -- **容器元数据**：镜像、启动命令、标签 - -## Docker 部署 -```yaml -cadvisor: - image: gcr.io/cadvisor/cadvisor:latest - ports: - - "8080:8080" - volumes: - - /:/rootfs:ro - - /var/run:/var/run:ro - - /sys:/sys:ro - - /var/lib/docker/:/var/lib/docker:ro -``` - -## Common Alert Rules -- 容器重启次数 > 0（1 小时内） -- 容器 CPU 限制超过 90% -- 容器内存限制超过 85% - -## Default Port -- 8080 - -## Connections -- [[cAdvisor]] ← scrapes_by ← [[Prometheus]] -- [[cAdvisor]] ← container_monitoring ← [[监控可观测性]] \ No newline at end of file diff --git a/wiki/concepts/caffeinate.md b/wiki/concepts/caffeinate.md deleted file mode 100644 index 81984dc2..00000000 --- a/wiki/concepts/caffeinate.md +++ /dev/null @@ -1,52 +0,0 @@ ---- -title: "caffeinate" -type: concept -tags: [macos, power-management, command-line] -date: 2026-04-17 ---- - -## Definition -caffeinate 是 macOS 内置工具，用于临时阻止系统进入睡眠状态。与 pmset 不同，caffeinate 不修改系统设置，仅在运行时有效，按 Ctrl+C 停止后系统恢复默认睡眠行为。 - -## Installation -```bash -# macOS 内置，无需安装 -``` - -## Usage -```bash -# 防止显示器睡眠 -caffeinate -d - -# 防止系统空闲时睡眠 -caffeinate -i - -# 防止系统睡眠 -caffeinate -s - -# 模拟用户活动（防止睡眠） -caffeinate -u - -# 组合使用（常用） -caffeinate -d -i -s - -# 保持唤醒（按 Ctrl+C 停止） -caffeinate -d -i -s -``` - -## Parameters -| 参数 | 作用 | -|------|------| -| `-d` | 防止显示器睡眠 | -| `-i` | 防止系统空闲时睡眠 | -| `-s` | 防止系统睡眠 | -| `-u` | 模拟用户活动（防止睡眠） | - -## Use Cases -- 临时运行需要持续运行的任务（如大型下载、安装） -- 演示或展示时需要保持屏幕常亮 -- 不希望修改系统电源设置时的临时方案 - -## Related Concepts -- [[pmset]]：永久修改系统电源设置的工具 -- [[WOL (Wake on LAN)]]：网络唤醒功能 \ No newline at end of file diff --git a/wiki/concepts/dm-verity.md b/wiki/concepts/dm-verity.md deleted file mode 100644 index 9c01cf62..00000000 --- a/wiki/concepts/dm-verity.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "dm-verity" -type: concept -tags: [Linux-Kernel, Security, Filesystem] -date: 2026-04-19 ---- - -## Definition -dm-verity（device-mapper verity）是 Linux 内核子系统，用于验证块设备的完整性，通过 cryptographic hash 树实现只读文件系统的完整性保护。 - -## How It Works -- 在块设备上构建 hash 树结构 -- 每个块的数据 hash 与上一级 hash 比对 -- 根 hash 存储在信任的存储位置 -- 任何块内容变化都会导致验证失败 - -## Use Cases -- 防止根文件系统被篡改 -- 确保容器镜像完整性 -- 安全启动链的一部分 - -## Related Concepts -- [[Bottlerocket-OS]] — 使用 dm-verity 验证根文件系统 -- [[Secure-Boot]] — 安全启动机制 -- [[Root-Filesystem]] — 根文件系统保护 diff --git a/wiki/concepts/efibootmgr.md b/wiki/concepts/efibootmgr.md deleted file mode 100644 index 97be0ee2..00000000 --- a/wiki/concepts/efibootmgr.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: "efibootmgr" -type: concept -tags: [boot, efi, linux, command-line] -date: 2026-04-16 ---- - -## Aliases -- efibootmgr - -## Definition -efibootmgr 是 Linux 下的命令行工具，用于管理 EFI 固件中的启动顺序和启动项。可以查看、创建、删除和调整 UEFI 启动顺序，解决 HP BIOS 等系统启动顺序被重置的问题。 - -## Key Properties -- 平台：Linux -- 功能：NVRAM 启动项管理 -- 权限：需要 root 权限 -- 常见用法：-o 设置启动顺序，-c 创建新启动项，-v 查看详细信息 - -## Use Cases -- 修复 Ubuntu 启动顺序问题 -- 设置默认启动操作系统 -- 处理 HP BIOS 启动顺序被重置 - -## Example Commands -```bash -# 查看当前启动顺序 -sudo efibootmgr - -# 将 Ubuntu (Boot0005) 设为首选 -sudo efibootmgr -o 0005,0000,0001,0002,0003 - -# 创建新启动项 -sudo efibootmgr -c -d /dev/nvme0n1 -p 1 -L "Ubuntu" -l "\\EFI\\ubuntu\\shimx64.efi" -``` - -## Connections -- [[efibootmgr]] ← manages ← [[UEFI]] -- [[efibootmgr]] ← fixes ← [[启动顺序]] \ No newline at end of file diff --git a/wiki/concepts/node_exporter.md b/wiki/concepts/node_exporter.md deleted file mode 100644 index 93d5c680..00000000 --- a/wiki/concepts/node_exporter.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "node_exporter" -type: concept -tags: [exporter, prometheus, monitoring, linux] -sources: [家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox] -last_updated: 2026-04-16 ---- - -## Definition -node_exporter 是 Prometheus 官方的主机指标采集器，采集 Linux/Unix 主机的 CPU、内存、磁盘、网络、文件系统等系统指标。 - -## Key Metrics -- **CPU**：使用率、上下文切换、软中断 -- **内存**：总量、可用、已用、缓存 -- **磁盘**：使用率、IO、inode -- **网络**：流量、丢包、错误 -- **文件系统**：挂载点、容量、使用率 - -## Docker 部署 -```yaml -node_exporter: - image: prom/node-exporter:latest - network_mode: "host" - volumes: - - /proc:/host/proc:ro - - /sys:/host/sys:ro - - /:/rootfs:ro -``` - -## Common Alert Rules -- CPU 使用率 > 85% -- 磁盘空间 < 10% -- 可用内存 < 15% - -## Default Port -- 9100 - -## Connections -- [[node_exporter]] ← scrapes_by ← [[Prometheus]] -- [[node_exporter]] ← core_exporter ← [[监控可观测性]] \ No newline at end of file diff --git a/wiki/concepts/npm.md b/wiki/concepts/npm.md deleted file mode 100644 index 1c056282..00000000 --- a/wiki/concepts/npm.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "npm" -type: concept -tags: [javascript, package-manager] -last_updated: 2026-04-17 ---- - -## 定义 -npm（Node Package Manager）是 Node.js 默认的包管理器，用于安装、管理和分享 JavaScript 代码包。 - -## 用途 -- 安装全局或本地 Node 包 -- 发布自己的 npm 包 -- 管理项目依赖 -- 运行 package.json 中的脚本 - -## 常用命令 -```bash -npm install # 安装本地包 -npm install -g # 全局安装 -npm init # 初始化项目 -npm run