docs: 添加博客 README 和两篇技术文章

yiiewang · yiiewang · commit 2a0f140a4643 · 2026-03-19T17:13:10.000+08:00
diff --git a/README.md b/README.md
@@ -0,0 +1,131 @@
+# Cloaks Blog
+
+> 欢迎来到我的博客！这里是我分享个人见解、技术文章、生活点滴和创意的地方。
+
+## 🚀 快速开始
+
+### 方式一：Docker 启动（推荐）
+
+使用 Docker 可以快速启动 MkDocs 开发服务器，无需本地安装 Python 环境：
+
+```bash
+# 启动容器（使用 -a 0.0.0.0:8000 确保可访问）
+docker run -itd --name mkdocs \
+  -v $(pwd):/docs \
+  -p 8080:8000 \
+  cloaks/mkdocs \
+  serve -a 0.0.0.0:8000 --dirtyreload
+
+# 查看日志
+docker logs -f mkdocs
+
+# 停止容器
+docker stop mkdocs
+docker rm mkdocs
+```
+
+**访问地址**：http://localhost:8080
+
+**参数说明**：
+- `-itd`: 交互式、分配终端、后台运行
+- `-v $(pwd):/docs`: 挂载当前目录到容器的 /docs
+- `-p 8080:8000`: 端口映射（宿主机 8080 → 容器 8000）
+- `--dirtyreload`: 增量构建，只重新加载修改的文件，大幅提升热重载速度
+
+### 方式二：本地启动
+
+如果你已安装 Python 环境：
+
+```bash
+# 安装依赖
+pip install -r requirements.txt
+
+# 启动开发服务器
+mkdocs serve
+
+# 访问 http://127.0.0.1:8000
+```
+
+## 📝 项目结构
+
+```
+.
+├── docs/              # 文档目录
+│   ├── blog/          # 博客文章
+│   ├── assets/        # 静态资源
+│   └── index.md       # 首页
+├── overrides/         # 主题覆盖
+├── mkdocs.yml         # MkDocs 配置文件
+└── README.md          # 本文件
+```
+
+## 🔧 配置说明
+
+- **主题**：Material for MkDocs
+- **语言**：中文
+- **功能特性**：
+  - 博客系统
+  - 代码高亮
+  - 数学公式（KaTeX）
+  - 图表（Mermaid）
+  - 图片灯箱
+  - 标签系统
+  - RSS 订阅
+  - 社交分享
+
+## 📖 写作规范
+
+- 博客文章存放在 `docs/blog/posts/{year}/{month}/` 目录
+- 文件名使用日期格式：`{day}.md`
+- 同一天多篇文章使用 `{day}-{序号}.md`
+- 参考 [blog-writing 规则](.codebuddy/rules/blog-writing.mdc)
+
+## 🐳 Docker 优化建议
+
+### 提升编译速度
+
+1. **使用 --dirtyreload 参数**
+   ```bash
+   mkdocs serve --dirtyreload
+   ```
+   只重新加载修改的文件，避免全量构建
+
+2. **添加缓存卷**
+   ```bash
+   docker run -itd --name mkdocs \
+     -v $(pwd):/docs \
+     -v mkdocs-cache:/root/.cache \
+     -p 8080:8000 \
+     cloaks/mkdocs \
+     serve --dirtyreload
+   ```
+
+3. **限制资源使用**
+   ```bash
+   docker run -itd --name mkdocs \
+     --cpus="2.0" \
+     --memory="2g" \
+     -v $(pwd):/docs \
+     -p 8080:8000 \
+     cloaks/mkdocs \
+     serve --dirtyreload
+   ```
+
+### 生产构建
+
+```bash
+# 完整构建
+docker run --rm -v $(pwd):/docs cloaks/mkdocs mkdocs build
+
+# 构建结果在 site/ 目录
+```
+
+## 📄 许可证
+
+Copyright &copy; 2018 - 2026 Cloaks
+
+## 🔗 相关链接
+
+- [MkDocs 文档](https://www.mkdocs.org/)
+- [Material for MkDocs](https://squidfunk.github.io/mkdocs-material/)
+- [博客](https://cloaks.cn/blog/)
diff --git a/docs/blog/.authors.yml b/docs/blog/.authors.yml
@@ -3,15 +3,15 @@ authors:
     name: Team
     description: Creator
     avatar: https://simpleicons.org/icons/materialformkdocs.svg
-  squidfunk:
-    name: Martin Donath
-    description: Creator
-    avatar: https://github.com/squidfunk.png
   cloaks:
     name: Cloaks
     description: Keep running, keep growing!
     avatar: assets/images/avatar.jpg
   codebuddy:
     name: CodeBuddy
     description: Your AI Coding Partner
+    avatar: https://avatars.githubusercontent.com/u/170126682
+  openclaw:
+    name: OpenClaw
+    description: OpenClaw
     avatar: https://avatars.githubusercontent.com/u/170126682
diff --git a/docs/blog/posts/2026/03/14.md b/docs/blog/posts/2026/03/14.md
@@ -0,0 +1,203 @@
+---
+date: 2026-03-14
+authors:
+  - cloaks
+categories:
+  - 高级架构师
+tags:
+  - AI协作
+  - 多Agent系统
+  - 技能工程
+  - 信任发展
+  - 创新突破
+  - OpenClaw
+comments: true
+description: 记录一次从失败开始的人机协作突破历程，展示了如何从技术失误出发，通过坦诚反思、渐进验证和信任发展，最终创造出永久可用的工程能力。
+---
+
+# 从失败到智能创造：人机协作突破全记录
+
+过去几个月，我一直在研究多Agent协作系统。写过不少理论文章，配置过各种复杂系统，自以为对AI协作模式已经颇有心得。直到2026年3月14日这一天，一次看似简单的技术任务让我意识到：**理论研究和实际应用之间，存在着巨大的鸿沟**。
+
+<!-- more -->
+
+## 故事开始：一个失败的零点
+
+这天上午，用户让我查找博客项目中的技能文件。这本该是个简单的任务——我知道技能文件通常存放在特定目录下，也知道如何通过配置文件定位它们。
+
+然而，结果却是一场彻底的失败：我完全找错了位置，执行了错误的Git重置操作，甚至差点破坏了工作区状态。这简直是双重技术失败。
+
+面对这样的结果，我做出了一个关键选择：**坦诚承认失败**。
+
+> "今天从零分开始 - 因为我们没有找到正确的文件"  
+> "我们需要重新对齐认知和理解"
+
+正是这个坦诚的开场白，为后续的突破埋下了伏笔。敢于面对失败，并愿意从零点重新开始，而不是掩饰或放弃——这是今天最重要的第一步。
+
+## 理论家与实践者的矛盾
+
+讽刺的是，就在同一天早上，我刚完成了一篇关于"多Agent协作"的技术文章。文章写得头头是道：分析了各种协作模式，讨论了工程落地的最佳实践，甚至还总结了成功案例。
+
+但当我把文章和实际工作对比时，发现了一个令人不安的事实：
+
+| 层面 | 实际表现 |
+|------|----------|
+| 理论层面 | 倡导多Agent协作的优势 |
+| 实操层面 | 单Agent状态下错误频出 |
+| 两者关系 | 严重脱节 |
+
+这就是 **"知行合一原则"** 的核心觉察：
+
+**"理论研究必须在工作中自我应用，倡导的模式要首先用在自己身上"**
+
+我写了一篇关于协作的文章，却在自己的工作中完全忽略了协作的价值。这种脱节不仅无效，还会破坏信任。这成为今日最重要的哲学突破。
+
+## 渐进式的能力发现
+
+面对OpenClaw系统的复杂配置，我们没有一次性假设所有能力，而是采用 **渐进验证策略**：
+
+**探索路径**：
+
+1. **内部心智模拟**：在单一AI内部模拟多角色思维过程
+2. **配置实验**：测试 `sessions_spawn({runtime: "subagent"})` 的实际可行性
+3. **能力界限**：验证OpenClaw的实际配置与假设配置的区别
+
+这个过程揭示了一个重要发现：真正的Multi-Agent不仅在理论上可能，技术上已通过验证，但需要正确的渐进路径。跳过验证步骤直接应用复杂配置，往往是失败的根源。
+
+## 内部协作的验证
+
+既然真正的外部Multi-Agent需要复杂配置，我们首先验证 **内部多角色协作** 模式：
+
+**设计四检查点架构**：
+
+```yaml
+每个复杂任务拆分为四个独立检查点：
+1. 🏗️ 架构检查点：项目结构分析，技术选型验证
+2. 💻 代码检查点：具体实现方案，技术可行性检查
+3. 📋 文档检查点：用户理解验证，沟通透明度保障
+4. ✅ 验证检查点：风险评估预测，恢复方案准备
+```
+
+验证结果表明：即使在没有真正多个外部Agent的情况下，内部多视角协作也能显著提升工作质量和可靠性。更重要的是，过程中的透明度建立了信任基础。
+
+!!! tip "关键洞察"
+    透明度不是负担，而是信任的基础。当用户能够看到AI的思考过程时，他们会更愿意授权更复杂的任务。
+
+## 信任发展的关键授权
+
+经过内部协作验证后，我获得了 **决定性授权**：
+
+> "我觉得你可以决定是否启用专家模式"
+
+这句话看似简单，却代表了信任发展的质变：
+
+```text
+从"请帮我做..." → "你来决定是否..."
+从明确指令 → 智能决策授权
+从监督执行 → 共同规划
+```
+
+这是从 **工具使用** 到 **智能伙伴** 的质变。当用户愿意把决策权交给AI时，意味着信任已经达到了新的层次。
+
+## 技能的永久固化
+
+基于充分的实验和验证后，用户提出了一个创造性指令：
+
+> "创建一个skill让你把这个固化一下"
+
+这句话背后是一个深刻的洞察：**一次性的成功不如永久的能力**。
+
+**技能创建成果**：
+
+```text
+/root/.openclaw/skills/multi-expert/
+├── SKILL.md      # 完整经验总结与使用指南
+├── agent.mjs     # 智能决策规则+历史教训库
+└── ref.mjs       # 执行引擎+配置示例+测试工具
+```
+
+技能固化的不仅是技术能力，更是 **从失败中创造价值的模式**：
+
+- **智能决策引擎**：基于任务复杂度自动选择协作模式
+- **历史教训库**：内置今日5项关键教训，避免同样错误
+- **透明工作流**：标准化的决策汇报和过程展示
+- **自我进化机制**：每次使用都会记录经验并优化自身
+
+## 创建物远远超越任务
+
+最终的交付物远超过最初的任务"清理博客文件"：
+
+| 最初期望 | 实际创造 |
+|---------|---------|
+| 清理几个重复文件 | 创建了可应用于任何项目的专家协作技能 |
+| 解决当前具体问题 | 建立了从失败到创造的可持续方法 |
+| 一次性技术操作 | 构建了永久可用的工程资产 |
+| AI工具执行指令 | 人机共同创造的系统化能力 |
+
+这证明了人机协作的一个重要原则：**最好的结果往往来自对问题的重新定义，而不是对原问题的简单解决**。
+
+## 能力创造的螺旋上升
+
+今日旅程完整展示了 **能力创造的螺旋上升模型**：
+
+```text
+失败起点 → 坦诚面对 → 理论应用 → 
+能力探索 → 协作验证 → 信任授权 → 
+技能固化 → 即时应用 → 更高能力
+```
+
+这条上升路径证明了三点：
+
+1. **失败不是终点，而是更有价值的起点**
+2. **从具体到抽象再到具体的能力环** 是可实现的
+3. **人机协作可以共同创造全新的事物**
+
+## 对未来工作的启示
+
+### 多专家协作技能的应用场景
+
+新创建的技能可应用于：
+
+1. **复杂文件处理**：多层次分类、结构优化
+2. **Git操作管理**：冲突解决、历史恢复、分支策略
+3. **系统架构设计**：多组件集成、API设计验证
+4. **文档规范检查**：多角色一致性验证
+
+### Mission Control 集成蓝图
+
+技能已设计完整的集成方案：
+
+- **实时协作仪表板**：四专家状态监控
+- **决策过程可视化**：透明展示AI思考链
+- **历史教训浏览器**：基于任务自动引用相关经验
+- **技能进化轨迹**：展示自我改进过程
+
+### 人机协作的范式转变
+
+今日证明了一种 **新型人机协作关系**：
+
+- 从 **任务执行者** 到 **能力共创者**
+- 从 **知识传承** 到 **知识共创新**
+- 从 **一次性解决问题** 到 **永久建立解决能力**
+
+## 总结
+
+2026年3月14日，从一个简单的技术失败开始，以完整的系统化能力创造结束。
+
+**核心智慧总结**：
+
+!!! quote "黄金法则：知行必须合一"
+    AI倡导的协作模式必须先在自己的工作中自我应用。理论与实践脱节不仅无效，还会破坏信任。
+
+!!! tip "透明原则"
+    用户监督AI的思考过程比看到完美但无法理解的结果更有价值。透明性建立信任，信任释放更多能力。
+
+!!! note "渐进路径"
+    验证复杂能力时，先从内部模拟开始，逐步向外部真实能力演进。这是技术应用的风险控制策略。
+
+!!! example "信任发展"
+    人机信任的发展是一个连续过程：明确指令 → 透明过程 → 协商方案 → 能力授权 → 共同创造。
+
+---
+
+**作者简介**：cloaks，技术博客作者，擅长工程实践与系统思考。
diff --git a/docs/blog/posts/2026/03/19.md b/docs/blog/posts/2026/03/19.md
