diff --git a/.gitignore b/.gitignore
index d6af2bb..7fa7c06 100644
--- a/.gitignore
+++ b/.gitignore
@@ -18,6 +18,7 @@ public/dl-index/
# Contentlayer cache
ui/docs/.contentlayer/
+src/content/blog/
# Lock files (如果不希望追踪)
uyarn.lock
diff --git a/next-env.d.ts b/next-env.d.ts
index 6a87cbd..c4b7818 100644
--- a/next-env.d.ts
+++ b/next-env.d.ts
@@ -1,7 +1,6 @@
///
///
-import "./.next/types/routes.d.ts";
-///
+import "./.next/dev/types/routes.d.ts";
// NOTE: This file should not be edited
// see https://nextjs.org/docs/app/api-reference/config/typescript for more information.
diff --git a/src/content/blog/Cloud-Neutral-Hybrid-Network-Architecture.md b/src/content/blog/Cloud-Neutral-Hybrid-Network-Architecture.md
deleted file mode 100644
index 86ece09..0000000
--- a/src/content/blog/Cloud-Neutral-Hybrid-Network-Architecture.md
+++ /dev/null
@@ -1,448 +0,0 @@
-# 概述
-
-从传统 DMZ 到 Zero-Trust 与可迁移混合云互联
-
-企业网络架构的演进，从未是一条直线，而是一场在安全性、灵活性与成本之间不断博弈的旅程。
-
-这条路径大致可划分为四个阶段：私有云 / IDC 的传统 DMZ → Cloud-Native 架构的兴起 → Zero-Trust 零信任体系的确立 → 回归到 Hybrid Cloud Connectivity 多云互联阶段。
-
-- 传统 DMZ : 在最初的 Traditional DMZ 模型中，安全边界是物理的——通过防火墙、NAT、VLAN 将“内部”与“外部”隔离。它简单直观，却脆弱而僵硬：一旦攻击者穿透边界，内网几乎裸奔。
-- Cloud-Native 架构: 随着容器与微服务的普及，系统开始走向 Cloud-Native 架构。安全边界逐渐虚化，服务粒度变小，弹性伸缩成为常态。但与此同时，复杂的流量拓扑和多环境部署带来了新的挑战：身份验证、服务间信任、跨集群通信、以及合规性审计。
-- Zero-Trust 零信任体系: 不再假设“内网可信”，而是以身份、设备、上下文为信任基石，动态验证每一次访问。安全策略从外围防御转向全局分布式的身份治理和访问控制，使云上与云下的资源都处于持续可验证状态。
-- 多云互联: 零信任并非终点。 回归 Hybrid Cloud Connectivity（混合云互联）：让应用、数据和安全策略在多云与边缘之间自由流动。企业可以在数据敏感度与成本之间动态权衡——核心数据仍在私有云或本地数据中心，弹性算力与AI训练在公有云上完成，通过安全互信的隧道与策略层实现双向可控连接。
-
-这一路线的终极目标，是面对实现一种“循环最优解”：
-
-- 系统能够在成本与合规之间自由切换；
-- 架构能够在多云之间迁移、扩展、回退；
-- 安全策略不依赖特定厂商，而能独立于底层平台存在。
-
-这就是“Cloud-Neutral”理念的核心——去绑定、可迁移、可验证、可逆转。它让云计算真正成为基础设施，而不是新的锁链。
-
-## Part I — 传统 DMZ 在公有云中的虚拟化实现
-
-Traditional DMZ Virtualization in Public Cloud）
-
-### 背景（Background）
-
-传统的 DMZ（Demilitarized Zone，隔离区） 模型源自物理数据中心时代：通过 Core / DMZ / Internal 三层安全域分隔，将企业内外部网络划定明确边界。
-
-在迁移到公有云后，这一模式以 NAT + DMZ + 静态路由表 的形式被虚拟化，实现了“云上镜像版”的安全分区。
-
-其核心目标依旧是：
-
-- 集中出入口，实现统一的安全审计与访问策略；
-- 将公网威胁“阻挡在门口”；
-- 以最小改造成本支撑遗留系统与传统安全模型的上云。
-
-这一架构往往是企业云化的第一步，既满足合规监管的边界审计要求，又提供熟悉的安全操作模式。
-
-### 网络拓扑（Network Topology）
-
-
-
-拓扑逻辑：
-
-- DMZ 子网（如 10.0.10.0/24）直接连接 Internet Gateway，承载外部访问点（如 ALB/WAF/Proxy）。
-- Private 子网 默认路由指向 NAT/防火墙，仅能通过受控出口访问外部网络。
-- 所有流量路径（入站与出站）在 DMZ 层集中，实现日志与安全策略统一。
-
-### 云上实现要点（Implementation Highlights）
-
-- 子网设计
- - 独立 DMZ 子网负责外网通信，Private 子网仅经 NAT 出站。
- - 路由表控制出入口：强制所有外部流量经 DMZ。
- - 安全控制
- - 安全组与网络 ACL 严格区分方向：外→内仅限特定端口（如 443）。
- - 启用 VPC Flow Logs 与 CloudTrail/Audit Logs 记录出入流量。
-- 流量管理
- - 出站经 NAT Gateway 统一 SNAT，便于安全审计与配额管理。
- - 对高频外联业务可使用 PrivateLink / Service Connect 代替公网出口。
- - 优点与局限（Pros & Limitations）
-
-### 优点 / 局限对照表
-
-| 优点 | 局限 |
-|:----|:----|
-| 架构直观，迁移成本低，符合传统安全思维。 | 出口集中导致带宽瓶颈与高延迟。 |
-| 审计路径清晰，满足监管与合规要求。 | 静态 ACL 与固定拓扑难适配云原生弹性。 |
-| 边界隔离明确，便于策略集中管理。 | “内网可信”假设失效，难以防范横向移动攻击。 |
-| 落地快，适合遗留系统与阶段性混合部署。 | 自动化与多环境编排支持较弱。 |
-
-
-### ☁️ 云服务选型与映射（Cloud Service Mapping）
-
-| 能力 | AWS | GCP | Azure | 阿里云 |
-|:----|:----|:----|:----|:----|
-| 公网入口 | ALB / NLB + WAF | External HTTP(S) LB + Cloud Armor | App Gateway + WAF | SLB / ALB + 云盾 WAF |
-| 出站 NAT | NAT Gateway | Cloud NAT | NAT Gateway | NAT 网关 |
-| DMZ 防护 | Network Firewall / GWLB / 第三方防火墙 | 3rd FW via ILB / NLB | Azure Firewall | 云防火墙 / 第三方 |
-| 审计与日志 | VPC Flow Logs + CloudTrail | VPC Flow Logs + Audit Logs | NSG Flow Logs + Activity Logs | 流日志 + ActionTrail |
-| DNS 解析 | Route53 Resolver | Cloud DNS | Private DNS | PrivateZone |
-
-
-### 💰 成本考量（Cost Considerations）
-
-- **流量类成本**：公网出口带宽、NAT 传出、LB/WAF 按量计费。
-- **防火墙类成本**：托管型云防火墙按**吞吐量/规则数/区域数**计费。
-- **审计日志**：日志存储（CloudWatch / LogService / Stackdriver）随时间线性增长。
-- **优化建议**：
- - 对固定出口场景使用 **PrivateLink / PSC** 减少公网流量；
- - 对防火墙规则进行**分层复用**（区域模板化）以降低策略数量；
- - 结合 **流量监控+FinOps** 做出口成本归因。
-
-### 显性成本
-
-- NAT 出口流量计费（按 GB 或包量）。
-- WAF / LB / Firewall 实例与镜像流量计费。
-- 带宽与日志存储费用。
-
-### 隐性成本
-
-- 单一出口造成带宽与延迟瓶颈。
-- 防火墙实例的可用性维护与策略变更窗口。
-- 安全组、ACL、Route Table 的人工变更与回归测试成本。
-
-### 优化建议（Optimization Tips）
-
-- 分层出口：按环境（生产/测试）或业务域拆分 NAT 出口，减少拥塞。
-- 内网专通道：对云内服务尽量使用 PrivateLink / PSC，避免公网流量循环。
-- 缓存与流量分层：结合 CDN / Edge / 缓存层降低 DMZ 压力。
-- 安全策略即代码（SaC）：以 Terraform / Pulumi 自动化管理 ACL 与路由。
-
-## Part II — 基于云的 DMZ 与 Proxy 演进（虚拟化检查面）
-
-(Cloud-Based DMZ & Proxy Architecture: From Boundary to Inspection Plane）
-
-### 背景（Background）
-
-在完成传统 DMZ 的虚拟化之后，企业网络安全架构的第二阶段，是从“物理边界”过渡到“服务化检查面（Service Inspection Plane）”。
-
-在这一阶段，安全不再依赖物理隔离与静态 ACL，而是借助云原生托管能力——如 云防火墙、云 NAT、WAF、集中日志服务——实现动态、可编排、可审计的安全策略。
-
-与此同时，引入 Egress Proxy（出站代理） 与 DNS 策略控制，使出站访问能够细粒度治理：按域名、按方法、按身份，真正实现“按需信任”与“最小外联原则”。
-
-这种模式常被称为云上的“虚拟化检查面（Virtualized Inspection Plane）”，它在零信任落地之前，构成企业级安全架构的关键中期形态。
-
-### 网络拓扑（Network Topology）
-
-
-
-### 拓扑逻辑说明：
-
-- Hub VPC：集中部署云防火墙、NAT、Egress Proxy 与 Private DNS，作为全局出入口与检查面。
-- Spoke VPC：业务应用通过 http\_proxy/https\_proxy 环境变量或透明代理，将出站流量统一导向 Proxy/NAT。
-- 入站流量 由 WAF 或 L7 LB 接入，结合 Cloud Armor / 云盾实现 L7 级安全防护。
-- DNS 策略控制：仅解析受信任域名，并与 Egress Proxy 联动实现出站白名单。
-
-### 核心能力（Key Capabilities）
-
-- Egress Proxy 治理
-- 支持 HTTP(S) 协议的出站过滤与缓存。
-- 按域名 / URL / Method / 用户身份控制外联范围。
-- 内置流量审计与访问日志，满足合规追踪。
-- 云防火墙集中策略模板化
-- L3–L7 多层次检测：应用识别、地理位置、端口与方向控制。
-- 支持跨账户 / 多 VPC 策略同步，形成企业安全模板库。
-
-### 私网访问（Private Connectivity）
-
-- 使用 PrivateLink（AWS）/ Private Service Connect（GCP）/ Private Link（Azure） 实现私有网络访问云服务。
-- 减少公网暴露面，实现云内服务通信最小化。
-- DNS 策略治理
-- DNS 仅解析白名单域；结合 Proxy 强制拦截外部未知域访问。
-- 可使用 DNS-over-TLS 加密与审计。
-
-### 适用场景（Use Cases）
-
-- 企业级 API 与微服务的 出站访问治理与合规审计；
-- 多环境（Prod/Stage/Dev）统一出口与审计点；
-- 渐进式安全强化：在零信任改造前的“云上中期形态”；
-- 有“集中出网 + 审计 + 合规报表”要求的行业（金融、通信、能源等）。
-
-### 优点与局限（Pros & Limitations）
-
-| 优点 | 局限 |
-|:----|:----|
-| 出站可按域名 / 类别进行白名单治理，减少恶意外连。 | 代理集群需维护可用性与证书透传复杂性。 |
-| 云防火墙集中策略模板化，支持合规审计与回溯。 | 非 HTTP(S) 协议治理能力有限，需结合防火墙或透明代理。 |
-| DNS + Proxy 联动，实现端到端可见性与细粒度控制。 | 代理与 NAT 的性能与扩展性成为关键瓶颈。 |
-| 缓存与流量准入合并，提升出口效率与安全性。 | 对遗留系统改造成本较高，需适配 Proxy 配置与认证逻辑。 |
-
-
----
-
-### 云服务选型与映射（Cloud Service Mapping）
-
-| 能力 | AWS | GCP | Azure | 阿里云 |
-|:----|:----|:----|:----|:----|
-| 云防火墙 | AWS Network Firewall | Cloud IDS / 3rd FW | Azure Firewall | 云防火墙 |
-| Egress 代理 | 自建 Envoy / Squid（EC2 / EKS） | Envoy / Squid（GCE / GKE） | 自建或 Marketplace 模板 | 自建 / Marketplace |
-| 私网访问 | PrivateLink | Private Service Connect | Private Link | PrivateLink |
-| DNS 策略 | Route53 Resolver | Cloud DNS + Policy | Private DNS | PrivateZone |
-
-
----
-
-### 成本考量（Cost Considerations）
-
-- **显性成本**：代理层计算与带宽、云防火墙吞吐/策略数量计费、私网通道费用、日志与审计存储。
-- **隐性成本**：代理/证书运维复杂度、跨可用区流量与延迟、变更与回归测试人力、非 HTTP 流量额外治理成本。
-- **优化方向**：
- - 代理与 NAT **同 AZ** 部署并**横向扩展**（ASG/HPA）；
- - **DNS 白名单**与 Proxy 联动；
- - 非 Web 协议走 **L3/L4 防火墙** 或透明代理；
- - **集中日志**与指标（可观测性）用于容量与策略的持续优化。
-
-### 显性成本
-
-- 代理层计算 + 带宽；
-- 云防火墙策略数、吞吐量与实例计费；
-- 专线或私网通道带宽费用。
-
-### 隐性成本
-
-- Proxy 集群运维与横向扩展；
-- SSL/TLS 中间证书管理复杂度；
-- 对接多云 DNS 与跨环境路由策略的配置成本。
-
-### 收益
-
-- 公网暴露面显著缩小；
-- 外联行为完全可视；
-- 异常外连检测提前到出口层；
-- 入站攻击面经 WAF/Armor 降低。
-
-### 优化建议（Optimization Tips）
-
-- Proxy 与 NAT 同 AZ 部署，减少跨区流量与延迟。
-- 代理集群横向扩展，结合 ASG / HPA 实现弹性出网能力。
-- DNS 白名单策略：仅允许解析可信域名，未命中直接拒绝外联。
-- 非 HTTP(S) 流量交由云防火墙 L3/L4 控制；Proxy 专注 L7 层。
-- 集中日志审计：通过 CloudWatch / Stackdriver / Log Analytics / SLS 统一出口日志。
-
-## Part III — Cloud-Native 与 Zero-Trust 架构演进
-
-(Identity-Driven Cloud-Native Security Architecture）
-
-### 背景（Background）
-
-在进入云原生时代后，安全范式从“边界防御”彻底转向“身份与策略驱动（Identity & Policy-Driven）”。
-
-在传统模型中，安全依赖网络层面的划分与访问控制（DMZ、防火墙、ACL）。
-
-而在云原生环境中，应用以容器和微服务形式运行，边界被打散，通信更多发生在东西向（East-West）流量中。
-
-因此，信任不再来源于位置，而来源于可验证的身份与可编排的策略。
-
-核心技术堆栈包括：
-
-- mTLS（Mutual TLS）：双向认证与加密通信，确保服务间信任基于证书而非网络位置。
-- SPIFFE/SPIRE：自动颁发与管理服务身份（SPIFFE ID），形成“服务身份证体系”。
-- OIDC / IAM / ZTNA：人机统一的身份与访问控制，连接 IdP 与工作负载。
-- 微分段（Micro-Segmentation）：以服务或身份为边界，而非子网或 VLAN。
-- OPA/Rego 策略引擎：实现细粒度的动态授权（ABAC、RBAC、Context-Aware）。
-- eBPF 与 Service Mesh：构建分布式策略执行面（Data Plane）与可观测性框架。
-
-这是一场从“网络隔离”到“信任连续性”的革命。
-
-### 网络拓扑（Network Topology）
-
-
-
-拓扑说明：
-
-- 集群内部由 Service Mesh（如 Istio 或 Cilium Service Mesh） 统一管理流量。
-- 每个服务通过 SPIFFE ID 获得可信身份，并使用 mTLS 加密通信。
-- 策略控制面（OPA/IAM）动态下发访问规则，实现“按身份信任”。
-- 出口由 Egress Gateway 或 Firewall-as-a-Service 控制，与 Mesh Egress 策略结合，统一审计与访问。
-
-### 关键能力（Key Capabilities）
-
-- 集中身份信任链 (Landline LDP / SPIFFE/SPIRE)
-- 构建服务到服务的 PKI 信任链，自动轮换证书。
-- 消除共享密钥与硬编码凭证问题。
-- 在多集群/多云中实现统一身份命名空间（Trust Domain）。
-- mTLS 与 Service Mesh
-- 所有东西向流量加密；Mesh Sidecar 拦截并强制执行策略。
-- 与 OPA 或 Envoy Filter 协同，实现基于身份的 L7 访问控制。
-
-### eBPF 内核增强
-
-- Cilium 等方案通过 eBPF 直接在内核态执行策略，降低 Sidecar 开销。
-动态追踪流量、封包行为与审计事件，构建零侵入可观测性。
-- 策略即代码（Policy-as-Code）
-- 使用 OPA Rego 或 Kyverno 在 CI/CD 中自动校验部署策略。
-- 与 IAM/OIDC 结合，实现 RBAC + ABAC + Context 组合策略。
-- Egress 与 Zero-Trust Access（ZTNA）
-
-应用级出口控制：Egress Gateway 与 Mesh 策略共同定义外联白名单。
-
-用户级接入：通过 ZTNA 网关实现最小权限远程访问。
-
-### 对比（传统 vs 零信任）
-
-| 传统 DMZ/NAT 模式 | 云原生 / 零信任 模式 |
-|:----|:----|
-| 边界防御（Perimeter） | 身份与策略（Identity & Policy） |
-| 统一出口 | 分布式 Sidecar / eBPF 数据平面 |
-| NAT 审计 | 微分段 + Mesh 策略 |
-| DMZ 子网 | Mesh Egress / Firewall-as-a-Service |
-| 静态 ACL / 路由 | OPA / IAM / eBPF 动态策略 |
-
-
----
-
-### 云服务选型与映射（Cloud Service Mapping）
-
-| 能力 | AWS | GCP | Azure | 阿里云 |
-|:----|:----|:----|:----|:----|
-| **Mesh / 容器** | EKS + Istio / Cilium | GKE + Istio / Cilium | AKS + Cilium / Istio | ACK + Istio / Cilium |
-| **Egress 控制** | Istio Egress + Network FW | Istio Egress + 3rd FW | Cilium / Istio + Azure Firewall | Istio Egress + 云防火墙 |
-| **身份 / 零信任** | IAM + Verified Access | IAM + BeyondCorp | Entra ID + ZTNA | RAM + 第三方 ZTNA |
-| **策略引擎** | OPA / Gatekeeper | OPA / KRM | Azure Policy + OPA | OPA / 自建 |
-
-
-## 成本与可观测性（Cost & Observability）
-
-### Mesh 成本
-
-- 每个 Sidecar 带来 CPU 与 内存开销（平均 5–20%）。
-- 可通过 Cilium eBPF 模式减少流量复制与延迟。
-- 零信任 / 身份成本
-- ZTNA、IdP 等订阅费用（如 BeyondCorp、Entra ID）。
-- 统一认证后减少凭证管理与安全事件成本。
-
-### 可观测性设计
-
-- Mesh Telemetry：流量指标、延迟、失败率。
-- OPA Audit Logs：策略匹配与拒绝事件。
-- eBPF Tracing：实时追踪系统调用与数据包。
-
-### 总体收益
-
-- 入侵面与故障域显著缩小；
-- 策略可编程与自动化；
-- 不同环境（Dev/Staging/Prod）可共享一致的安全基线；
-- 安全与运维从被动防守转向“验证式治理”。
-
-### 优化建议（Optimization Guidelines）
-
-- 优先采用 eBPF 模式（Cilium L7），减少 Sidecar 带宽与资源开销。
-- 使用 SPIFFE ID 绑定服务身份，替代硬编码凭证或 K8s Secrets。
-- 在 CI/CD 中集成 OPA / Kyverno，实现策略门禁与自动回归。
-- 将策略与审计集中至 Control Plane（Landline LDP 或自建 Trust Controller）。
-- 跨云互信：通过 SPIFFE Federation 或 OIDC Federation 实现多云身份联合。
-
-## Part IV — 混合云互联
-
-(Cloud-Neutral Connectivity & Policy Federation）
-
-### 背景（Background）
-
-云计算进入后半场，焦点已从“全面上云”转向“理性用云”。
-
-企业在成本、数据主权、合规要求与技术去绑定之间，寻求一个动态平衡点。
-
-核心动因包括：
-
-- 成本压力：尤其是跨云 Egress、GPU 训练算力与带宽费用；
-- 数据主权：不同区域的存储与访问受制于本地监管；
-- 可回退性：防止被单一云厂商锁定；
-- 弹性调度：根据实时策略在云、IDC、边缘之间平滑迁移。
-
-于是出现了“云中立（Cloud-Neutral）”理念：
-
-- 控制平面保持中立与声明式（IaC / GitOps / Policy-as-Code），
-- 数据与应用采用开放接口（Kubernetes、S3、Kafka、PostgreSQL），
-- 实现可迁移、可回退、可观测的多云混合架构。
-
-### 综合拓扑（Hybrid Connectivity）
-
-
-
-拓扑逻辑：
-
-- Fabric 层：以 SD-WAN / WireGuard / BGP Mesh 构建跨云安全隧道，实现低成本互联；
-- Control 层：IaC、GitOps 与 Policy 构成统一控制面（声明式编排、可回滚、可审计）；
-- Compute 层：各云与 IDC 运行统一的 Kubernetes 集群；
-- Data 层：以开放协议存储与传输，确保数据跨域可复制与一致。
-
-### 云服务选型（“中立优先”原则）
-
-| 层面 | 云绑定形态 | 云中立 / 可迁移形态 |
-|:----|:----|:----|
-| **网络骨干** | 各云专线（DX / ER / IC） | Equinix Fabric / Cato + WireGuard / BGP Overlay |
-| **控制平面** | CFN / ARM / ROS | OpenTofu / Pulumi + Crossplane / ClusterAPI |
-| **计算层** | ECS / VM / ASG | Kubernetes（云 / 本地统一编排） |
-| **存储与消息** | S3 / OSS / CloudMQ / RDS | MinIO（S3 兼容） / Kafka / PostgreSQL |
-| **身份与接入** | 各云 IAM | OIDC + Zero-Trust + SPIFFE / SPIRE |
-| **策略控制** | 云特定 Policy Engine | OPA / Kyverno / Gatekeeper |
-
-
----
-
-### 成本与主权（FinOps + Data Sovereignty）
-
-1. **出云与跨域传输**
- - 优先使用私网（PrivateLink / PSC）代替公网；
- - 日志、对象等数据就近落地，跨域同步采用差分策略。
-2. **GPU / AI 资源分布**
- - 训练任务放置于 IDC / 私有云以降低成本并确保数据主权；
- - 推理任务在公有云或边缘弹性扩展，实现混合调度。
-3. **FinOps 策略自动化**
- - 将 **成本与延迟指标** 作为策略输入（GitOps + Policy Engine）；
- - 实现动态迁移、灰度切换与可回退的多云资源调度。
-
-### 出云与跨域传输
-
-- 尽量走私网（PrivateLink / PSC）而非公网；
-- 数据分层：日志与对象数据就近落地，跨域采用差分同步。
-- GPU / AI 资源分布
-- 训练任务放在 IDC 或 GPU Edge（成本可控、数据安全）；
-- 推理任务弹性部署在公有云或边缘节点，实现动态调度。
-
-### FinOps 策略自动化
-
-将成本与延迟指标作为策略输入（GitOps + Policy Engine）；
-
-自动化迁移、灰度切换与回退，实现“算力流动经济”。
-
-### 优化建议（Optimization Guidelines）
-
-- 统一镜像与制品仓库：Helm/OCI/Container Registry 跨云同步；
-- 应用依赖标准化协议：S3、Kafka、PostgreSQL、gRPC 等开放接口；
-- 多活复制与切换剧本：建立可回退的数据库与对象存储复制策略；
-- 集中策略联邦（Policy Federation）：跨云统一 OPA / IAM / Trust Policy；
-- 监控与审计：Prometheus + Loki + Tempo + Grafana 构成多云可观测层。
-
-### 循环策略（Cost × Data Sensitivity）
-
-| 数据敏感度 / 成本 | 策略方向 |
-|:----|:----|
-| **高敏感 × 高成本** | 回归 IDC 或私有云（安全与合规优先） |
-| **低敏感 × 弹性峰值** | 调度至公有云（弹性与性价比） |
-| **低延迟场景** | 下沉至边缘节点（近源计算） |
-
-
-### 闭环逻辑
-
-统一控制面根据策略输入（延迟、成本、敏感度）执行声明式迁移与灰度切换，
-
-在“策略 → 度量 → 优化”的循环中实现持续演化。
-
-# 结语｜可流动的云，才是真正的云
-
-当我们把安全从“边界”升级为“身份”，把控制从“脚本”升级为“声明”，把连通从“专线”升级为“中立织体”，云就不再是一座岛，而是一张可自由伸缩、按需迁徙的网络。
-
-Cloud-Neutral 的内核不是“多云数量”，而是这三件事：
-
-- 可迁移：同一栈、同一声明、同一策略，随时上云、可随时下云、能平滑回退。
-- 可组合：网络中立（Fabric/SD-WAN）、身份统一（OIDC/mTLS/SPIFFE）、控制声明式（IaC/GitOps/Policy），像乐高一样重组能力，而非重写系统。
-- 可度量：以成本、延迟、主权、风险作为策略输入，自动在公有云/私有云/边缘之间做最优流量与算力调度。
-
-一句话的价值主张：
-
-A cloud that can move is a cloud that can choose.
-
-真正的自由，不是待在某朵云里，而是能在任意云之间呼吸。
diff --git a/src/content/blog/README.md b/src/content/blog/README.md
deleted file mode 100644
index 9c57450..0000000
--- a/src/content/blog/README.md
+++ /dev/null
@@ -1,44 +0,0 @@
-# Blog Content Directory
-
-This directory contains all blog posts for the Cloud-Neutral platform.
-
-## Directory Structure
-
-```
-src/content/blog/
-├── README.md # This file
-├── first-post.md # Example blog post
-└── ...
-```
-
-## Adding a New Blog Post
-
-1. Create a new markdown file in this directory
-2. Use the following format:
-
-```markdown
----
-title: Your Post Title
-author: Author Name
-date: 2025-01-01
-tags: [tag1, tag2, tag3]
-excerpt: Brief description of the post
----
-
-Your post content here in Markdown format.
-```
-
-## File Naming Convention
-
-- Use kebab-case: `my-first-post.md`
-- Avoid spaces and special characters
-- Include the `.md` extension
-
-## Metadata Fields
-
-- **title**: The post title (required)
-- **author**: Author name (optional)
-- **date**: Publication date in YYYY-MM-DD format (required)
-- **tags**: Array of tags (optional)
-- **excerpt**: Brief description (optional, auto-generated if not provided)
-
diff --git a/src/content/blog/gitops-security-compliance.md b/src/content/blog/gitops-security-compliance.md
deleted file mode 100644
index df892c9..0000000
--- a/src/content/blog/gitops-security-compliance.md
+++ /dev/null
@@ -1,44 +0,0 @@
----
-title: GitOps Security & Compliance in 2025
-author: Security Team
-date: 2025-01-05
-tags: [gitops, security, compliance, automation]
-excerpt: How to implement robust security and compliance controls in your GitOps workflows.
----
-
-GitOps has revolutionized how we manage infrastructure, but security and compliance remain critical concerns.
-
-## Security Considerations
-
-### Supply Chain Security
-- Scan dependencies for vulnerabilities
-- Use signed commits
-- Implement code signing
-- Verify container images
-
-### Access Control
-- Principle of least privilege
-- Multi-factor authentication
-- Role-based access control
-- Audit all changes
-
-## Compliance Framework
-
-### Policy as Code
-- Define policies in version control
-- Automate compliance checks
-- Block non-compliant changes
-- Regular policy reviews
-
-### Audit Trail
-- Immutable Git history
-- Signed commits
-- Change tracking
-- Compliance reporting
-
-## Implementation Strategy
-
-1. Start with high-level policies
-2. Implement progressive enforcement
-3. Automate validation
-4. Monitor and alert
diff --git a/src/content/blog/kubernetes-observability-best-practices.md b/src/content/blog/kubernetes-observability-best-practices.md
deleted file mode 100644
index 00e4885..0000000
--- a/src/content/blog/kubernetes-observability-best-practices.md
+++ /dev/null
@@ -1,36 +0,0 @@
----
-title: Kubernetes Observability Best Practices
-author: SRE Team
-date: 2025-01-10
-tags: [kubernetes, observability, sre, monitoring]
-excerpt: Learn the essential practices for building a robust observability strategy in Kubernetes environments.
----
-
-Building effective observability in Kubernetes requires understanding the unique challenges of containerized environments.
-
-## The Three Pillars
-
-### Metrics
-- Use Prometheus for metrics collection
-- Monitor resource usage (CPU, memory, disk)
-- Track application-specific metrics
-- Set up alerting rules
-
-### Logs
-- Centralize logs with ELK or similar stack
-- Structured logging for better searchability
-- Log levels: DEBUG, INFO, WARN, ERROR
-- Correlate logs with trace IDs
-
-### Traces
-- Use OpenTelemetry for distributed tracing
-- Track request flows across services
-- Identify performance bottlenecks
-- Monitor service dependencies
-
-## Best Practices
-
-1. **Start with Golden Signals**: Latency, traffic, errors, saturation
-2. **Use SLOs**: Define and track Service Level Objectives
-3. **Alert Wisely**: Alert on symptoms, not causes
-4. **Correlate Data**: Connect metrics, logs, and traces
diff --git a/src/content/blog/welcome-to-cloud-neutral.md b/src/content/blog/welcome-to-cloud-neutral.md
deleted file mode 100644
index 30d67e2..0000000
--- a/src/content/blog/welcome-to-cloud-neutral.md
+++ /dev/null
@@ -1,32 +0,0 @@
----
-title: Welcome to Cloud-Neutral
-author: Cloud-Neutral Team
-date: 2025-01-15
-tags: [announcement, cloud-native, platform]
-excerpt: Introducing Cloud-Neutral - your unified platform for managing complex multi-cloud operations.
----
-
-Welcome to Cloud-Neutral, the platform that unifies governance, automation, and observability for modern cloud-native environments.
-
-## What is Cloud-Neutral?
-
-Cloud-Neutral is designed to help platform teams manage complex multi-cloud estates with clarity. We provide a unified interface for:
-
-- **Unified multi-cloud governance** - Manage resources across AWS, Azure, GCP, and more
-- **Automated security & compliance** - Policy-as-code guardrails with global acceleration
-- **Observability with intelligent workflows** - Unified metrics, logs, and traces
-
-## Key Features
-
-### XCloudFlow
-Multi-cloud automation & GitOps orchestration that connects Terraform, Pulumi, and GitOps pipelines.
-
-### XScopeHub
-Observability & intelligent collaboration that unifies metrics, logs, and traces with AI-guided incident response.
-
-### XStream
-Security & compliance automation with policy-as-code guardrails.
-
-## Getting Started
-
-Visit our [documentation](/docs) to learn more about how Cloud-Neutral can help your team.