feat(blog): publish sandbox platform comparison

Author: xfgong

.agents/skills/write-cubeplex-blog-zh/SKILL.md

@@ -0,0 +1,107 @@
+---
+name: write-cubeplex-blog-zh
+description: Write, restructure, translate, or review Chinese CubePlex Blog articles in a direct, specific editorial style. Use for Chinese titles, outlines, MDX posts, technical comparisons, release analysis, and any request to remove AI-like wording or structure from content under i18n/zh-Hans/docusaurus-plugin-content-blog.
+---
+
+# CubePlex Blog 中文写作
+
+写清对象、事实、关系和限制。不要用修辞包装普通判断，也不要把聊天回答的组织方式带进文章。
+
+## 判断 AI 味
+
+不要因为出现某个词就判定文本由 AI 生成。检查多种模板是否集中出现，以及这些表达是否承担信息功能。
+
+- **元话语过多**：标题或句子反复说明“先讲什么”“下面分析什么”，却不直接写内容。
+- **抽象外壳过多**：使用“真正的差别”“核心价值”“关键能力”等通用说法，没有具体对象、动作或限制。
+- **人为制造深度**：用否定式反转、反问、比喻或递进排比包装普通事实，让简单判断显得像认知突破。
+- **结构过分整齐**：各节标题长度相近、句式相同，固定使用总分总、三段式和统一的问答结构。
+- **聊天回答痕迹**：使用“先说结论”“如果你正在……”“那么问题来了”“接下来我们看看”等面向对话用户的引导语。
+
+人类作者也会偶尔使用这些句式。问题在于集中、机械地使用，并且删掉以后不损失任何信息。
+
+## 标题
+
+直接写本节讨论的对象或关系。让标题单独出现在目录里时仍能说明内容。
+
+- 使用“接口与运行时”“Kubernetes 部署”“节点要求”“POC 验收项”这类内容标题。
+- 把主要结论写进导语或正文，不要设置“先说结论”“该怎么选”之类的导航标题。
+- 删除“真正的”“本质上”“不只是”“不在于……而在于……”等制造反转的包装。
+- 不用反问或模拟读者提问。把“为什么”“怎么做，才能……”改成具体名词或陈述。
+- 不为整齐而统一标题长度、句式或冒号结构。
+- 仅在副标题能缩小技术范围时使用冒号，不用冒号制造悬念。
+
+对照修改：
+
+| 避免 | 为什么有 AI 味 | 改为 |
+| --- | --- | --- |
+| 先给结论：两者该怎么选 | “先给结论”只说明文章顺序；“两者该怎么选”又重复文章主题，标题本身没有新信息 | 删除该标题，直接在导语写判断 |
+| 真正的差别不在功能清单 | “真正的”宣称掌握隐藏答案，“不在……”制造否定式反转，却没有直接说出差别 | 接口与运行时 |
+| POC 怎么测，才能得到可比较的结果 | 模拟用户提问并补充一个不言自明的目的，像聊天助手或 SEO 教程标题 | POC 验收项 |
+| Kubernetes 上每个 Sandbox 都是 Pod 吗？ | 用反问制造悬念，读者要进入正文才能得到本可直接写出的资源边界 | Kubernetes 部署与 MicroVM 调度 |
+| 如果你正在搭建 Agent 平台，应该关注什么 | 虚构读者场景，把明确的技术范围改写成通用问答 | Agent 平台的运行时要求 |
+| 这不仅是一次升级，更是架构理念的重塑 | 用否定式递进和抽象名词放大普通版本变化，没有说明改了哪些组件 | v0.6.0 的控制面和节点组件变更 |
+
+同样检查正文：
+
+| 避免 | 问题 | 改法 |
+| --- | --- | --- |
+| Sandbox 是连接 Agent 与基础设施的桥梁 | “桥梁”没有说明接口、调度或执行关系 | 写明 Agent 通过哪个接口调用哪个运行时 |
+| 那么问题来了，CubeSandbox 能跑在 Kubernetes 上吗？ | 这是聊天式转场和自问自答 | 直接写 v0.6.0 的 Kubernetes 支持范围 |
+| 首先看接口，其次看隔离，最后看运维 | 为了三段式而显式编号，实际材料未必只有三个层次 | 按接口、组件或部署约束自然分段 |
+
+## 结构
+
+按材料本身的关系组织文章，不套“背景—问题—挑战—展望”或“首先—其次—最后”。
+
+1. 确定文章要回答的一个主要问题和一个主要判断。
+2. 在导语中直接写判断和适用范围，不预告文章结构。
+3. 用项目、组件、接口、部署条件、数据或验证项命名章节。
+4. 每个章节只承担一个任务。相邻章节反复证明同一判断时合并。
+5. 保留有独立信息价值的图表。正文已经说清的内容不要再做一张总结表。
+6. 结论写完即停止，不复述整篇文章，也不追加空泛的行业意义。
+
+项目历史、许可证和组织背景只有在影响判断时才进入主线，否则放在末尾的源码与版本说明中。
+
+## 句子
+
+优先使用“谁做什么、条件是什么、证据在哪里”的句子。
+
+- 直接陈述事实。删除“值得注意的是”“不难看出”“可以说”等提示语。
+- 使用具体组件、版本、接口、权限和结果，少用“能力”“价值”“格局”“生态”等抽象词代替内容。
+- 不硬造比喻。技术对象可以直接说明时，不把它写成“桥梁”“底座”“双刃剑”或“分水岭”。
+- 不用排比制造完整感。分类数量由材料决定，不强行列三项。
+- 不用假设场景引出观点。需要表达部署条件时，直接写可验证条件及结果。
+- 不用反问推进段落。把问题改成陈述或可执行的检查项。
+- 限制“不是 A，而是 B”“不仅 A，而且 B”之类的否定式反转。直接写 B；确有对照价值时再保留 A。
+- 保留必要的技术英文，在第一次出现时解释含义；不要中英文来回替换同一概念。
+- 使用绝对日期，不写“昨天”“最近”等很快失效的相对时间。
+
+条件句可以用于真实约束。例如“集群禁止 privileged DaemonSet 时，CubeSandbox v0.6 不适合进入部署测试”。不要写虚构人物、想象场景或“如果你正在……”式开场。
+
+## 证据
+
+- 对发布版本、功能支持、接口和部署要求使用官方文档或源码。
+- 对容易变化的事实重新核对，不沿用旧文章或记忆中的结论。
+- 固定源码提交或明确分析版本。区分当前实现、文档描述和作者判断。
+- 把启动时延、密度、安全性等产品数字标为项目方数据，除非已经独立复测。
+- 不用“业内认为”“有观点指出”等模糊归因。
+
+## 编辑流程
+
+1. 先写不超过两层的目录，只保留能直接命名内容的标题。
+2. 检查每个标题：能否用于无关文章；若可以，说明过于抽象，重新命名。
+3. 通读正文，删除不增加事实、判断、条件或证据的句子。
+4. 合并重复结论，把对照关系集中到最合适的一处。
+5. 检查比喻、排比、假设、反问、否定式反转和元话语；默认删除。
+6. 大声读一遍。拆开节奏过于一致的句子，保留自然的长短变化。
+7. 修改 MDX 后运行 `pnpm check`，确认双语构建、类型和 URL 检查通过。
+
+## 交付检查
+
+- 标题是否直接写出对象、组件或关系？
+- 导语是否已经给出主要判断？
+- 每段是否有新的事实、条件、证据或结论？
+- 同一观点是否在表格、图和正文中重复出现？
+- 是否为了显得深刻使用了反转、比喻或反问？
+- 是否把项目方主张写成了已验证事实？
+- 删除任一句话后信息是否不变？若不变，删除它。

.agents/skills/write-cubeplex-blog-zh/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "CubePlex Blog 中文写作"
+  short_description: "为 CubePlex Blog 撰写直白、具体、无模板腔的中文文章"
+  default_prompt: "使用 $write-cubeplex-blog-zh 撰写或修改一篇直白、具体的 CubePlex 中文博客文章。"

AGENTS.md

@@ -1,5 +1,13 @@
 # CubePlex Blog Agent Guide
 
+## Chinese editorial writing
+
+Before drafting, restructuring, translating, or reviewing Chinese blog content,
+read and follow `.agents/skills/write-cubeplex-blog-zh/SKILL.md`. Apply it to
+Chinese titles, outlines, and MDX posts. Prefer direct, specific statements over
+metaphors, parallel slogans, hypothetical setups, rhetorical questions, and
+chat-style navigation.
+
 ## Blog cover images
 
 Create article cover images as final 2:1 WebP assets at `1280x640`. Keep the