doc: 新建文章

AGENTS.md

@@ -0,0 +1,322 @@
+# AGENTS.md - AI 编码代理项目指南
+
+本文档为 AI 编码代理提供本项目的详细背景信息，帮助快速理解和高效协作。
+
+## 项目概述
+
+这是一个基于 **Hexo** 静态站点生成器的个人技术博客，使用 **NexT** 主题（Mist 方案）。博客主要聚焦 Java 技术、前端开发（React）、架构设计、AI 应用等技术文章，同时包含个人成长、职业规划等内容。
+
+- **站点标题**: 正儿八经 - 资深技术专家
+- **作者**: Gamehu
+- **语言**: 中文（zh-CN）
+- **时区**: Asia/Shanghai
+- **站点 URL**: https://www.gamehu.run/
+
+## 技术栈
+
+| 类别 | 技术 |
+|------|------|
+| 静态站点生成器 | Hexo 6.3.0 |
+| 主题 | NexT 8.12.2 (Mist 方案) |
+| 模板引擎 | Nunjucks (.njk)、EJS |
+| 样式预处理 | Stylus |
+| 包管理器 | pnpm |
+| 部署方式 | Git 部署到 VPS |
+| 评论系统 | Waline（可选） |
+| 搜索 | 本地搜索 (hexo-generator-searchdb) |
+
+## 项目结构
+
+```
+hexo-blog/
+├── _config.yml              # Hexo 主配置文件
+├── _config.landscape.yml    # Landscape 主题配置（备用）
+├── package.json             # 项目依赖和脚本
+├── pnpm-lock.yaml           # pnpm 锁定文件
+├── db.json                  # hexo-admin 数据库文件
+├── CLAUDE.md                # Claude Code 专用指南
+├── AGENTS.md                # 本文档
+│
+├── source/                  # 源文件目录
+│   ├── _posts/             # 已发布的博客文章（Markdown）
+│   ├── _drafts/            # 草稿文章
+│   ├── _discarded/         # 已废弃文章
+│   ├── _data/              # 自定义数据文件
+│   │   └── styles.styl     # 自定义样式覆盖
+│   ├── images/             # 全局图片资源
+│   ├── uploads/            # 上传文件
+│   ├── about/              # 关于页面
+│   ├── categories/         # 分类页面
+│   ├── tags/               # 标签页面
+│   └── guestbook/          # 留言板页面
+│
+├── themes/                  # 主题目录
+│   ├── next/               # NexT 主题（当前使用）
+│   │   ├── _config.yml     # NexT 主题配置
+│   │   ├── layout/         # 模板文件 (.njk)
+│   │   ├── source/         # 静态资源 (css/js/images)
+│   │   └── scripts/        # Hexo 脚本和辅助函数
+│   └── landscape/          # Landscape 主题（备用）
+│
+├── scaffolds/               # 文章模板
+│   ├── post.md             # 文章模板
+│   ├── draft.md            # 草稿模板
+│   └── page.md             # 页面模板
+│
+├── public/                  # 生成的静态文件（.gitignore）
+└── .deploy_git/             # 部署用 Git 仓库
+```
+
+## 常用命令
+
+### 开发环境
+
+```bash
+# 安装依赖
+pnpm install
+
+# 启动本地开发服务器（默认端口 4000）
+npm run server
+# 或
+hexo server
+
+# 清理生成的文件
+npm run clean
+# 或
+hexo clean
+```
+
+### 构建与部署
+
+```bash
+# 生成静态文件
+npm run build
+# 或
+hexo generate
+
+# 部署到远程服务器（VPS）
+npm run deploy
+# 或
+hexo deploy
+
+# 一键生成并部署
+hexo generate --deploy
+```
+
+### 内容创建
+
+```bash
+# 创建新文章（使用 scaffolds/post.md 模板）
+hexo new post "文章标题"
+
+# 创建草稿
+hexo new draft "草稿标题"
+
+# 发布草稿
+hexo publish draft "草稿标题"
+
+# 创建新页面
+hexo new page "页面名称"
+```
+
+## 内容创作规范
+
+### 文章 Front Matter
+
+每篇文章必须包含以下 YAML 前置元数据：
+
+```yaml
+---
+title: 文章标题
+author: Gamehu
+date: YYYY-MM-DD HH:mm:ss
+tags:
+  - 标签1
+  - 标签2
+categories:
+  - 分类名
+---
+```
+
+### 文章资源管理
+
+- 启用 `post_asset_folder: true`，每篇文章可拥有同名资源文件夹
+- 图片引用使用 Hexo 资源标签：
+  ```markdown
+  {% asset_img filename.png 图片描述 %}
+  ```
+- 资源文件夹命名与文章文件名一致（不含扩展名）
+
+### 写作风格
+
+基于现有文章，博客具有以下写作特点：
+
+1. **去 AI 味**: 内容要求自然、有个人观点、避免模板化表达
+2. **口语化**: 使用轻松、生活化的语言
+3. **技术深度**: 注重实战经验和个人见解
+4. **结构清晰**: 使用标题、列表、代码块等组织内容
+
+### 可用样式类
+
+博客在 `source/_data/styles.styl` 中定义了多个自定义样式类：
+
+| 样式类 | 用途 |
+|--------|------|
+| `.highlight-text` | 黄色背景标注重点 |
+| `.wavy-underline` | 波浪下划线 |
+| `.gradient-text` | 渐变色文字 |
+| `.ai-tag` | AI 标签（带闪光动画效果）|
+| `.article-quote` | 引言样式 |
+| `.divider-gradient` | 渐变分隔线 |
+| `.divider-wave` | 波浪分隔线 |
+| `.divider-tech` | 科技感分隔线 |
+| `.divider-stars` | 星空分隔线 |
+
+使用方式：
+```markdown
+<span class="highlight-text">重点内容</span>
+<div class="ai-tag">AI 内容</div>
+```
+
+## 主题定制
+
+### NexT 主题配置
+
+主题配置文件：`themes/next/_config.yml`
+
+主要配置项：
+- **Scheme**: Mist（紧凑型布局）
+- **自定义样式**: `source/_data/styles.styl`
+- **菜单项**: 首页、关于、标签、分类、归档
+- **社交链接**: GitHub、Email
+- **侧边栏**: 左侧显示，包含头像、站点概览、目录
+
+### 自定义文件路径
+
+NexT 支持在 `source/_data/` 下创建文件覆盖主题默认设置：
+
+| 文件 | 用途 |
+|------|------|
+| `styles.styl` | 自定义 CSS 样式（已使用）|
+| `head.njk` | 自定义 head 标签 |
+| `header.njk` | 自定义页头 |
+| `sidebar.njk` | 自定义侧边栏 |
+| `footer.njk` | 自定义页脚 |
+| `body-end.njk` | body 结束前的自定义内容 |
+
+## 部署流程
+
+### 部署配置
+
+在 `_config.yml` 中配置：
+
+```yaml
+deploy:
+  type: git
+  repo:
+    vps: ssh://root@104.128.95.214:28915/home/git/blog.git,master
+```
+
+### 部署步骤
+
+1. 运行 `hexo deploy` 生成静态文件并推送到部署仓库
+2. 部署触发 VPS 上的 Git Hook
+3. 网站自动更新
+
+### SEO 配置
+
+- **Sitemap**: `sitemap.xml`（Google）和 `baidusitemap.xml`（百度）
+- **RSS**: `atom.xml`
+- **Robots.txt**: 位于 `source/robots.txt`
+
+## 已安装的插件
+
+### 核心插件
+- `hexo-generator-archive` - 归档页面生成
+- `hexo-generator-category` - 分类页面生成
+- `hexo-generator-index` - 首页生成
+- `hexo-generator-tag` - 标签页面生成
+- `hexo-generator-sitemap` - Sitemap 生成
+- `hexo-generator-baidu-sitemap` - 百度 Sitemap
+- `hexo-generator-searchdb` - 本地搜索数据
+
+### 功能增强
+- `hexo-all-minifier` - 资源压缩（HTML/CSS/JS/图片）
+- `hexo-asset-img` - 文章资源图片支持
+- `hexo-deployer-git` - Git 部署
+- `hexo-admin` - 后台管理界面
+- `hexo-wordcount` - 字数统计
+- `hexo-renderer-marked` - Markdown 渲染
+- `hexo-renderer-stylus` - Stylus 渲染
+
+### 第三方集成
+- `@waline/hexo-next` - Waline 评论系统
+- `hexo-next-share` - 分享功能
+
+## 开发注意事项
+
+### 文件修改建议
+
+1. **不要直接修改 `themes/next/_config.yml`**: 建议通过 `source/_data/` 下的文件进行覆盖
+2. **样式修改**: 在 `source/_data/styles.styl` 中添加自定义样式
+3. **新文章**: 使用 `hexo new post` 创建，保持 Front Matter 一致性
+
+### 性能优化
+
+- CSS 和 JS 压缩已启用（`hexo-all-minifier`）
+- 图片懒加载可通过主题配置启用
+- 使用 CDN 加载第三方库
+
+### 版本控制
+
+```gitignore
+# 忽略的文件
+node_modules
+.history
+*.pdf
+public
+```
+
+- `public/` 目录由 Hexo 生成，不提交到版本控制
+- `.deploy_git/` 是部署用的 Git 仓库
+- `db.json` 是 hexo-admin 数据文件
+
+## 故障排查
+
+### 常见问题
+
+1. **本地预览空白**
+   - 检查 `hexo server` 是否正常启动
+   - 尝试 `hexo clean` 后重新生成
+
+2. **样式不生效**
+   - 检查 `source/_data/styles.styl` 语法
+   - 确保主题配置中 `custom_file_path.style` 指向正确
+
+3. **部署失败**
+   - 检查 VPS SSH 连接
+   - 验证部署仓库配置
+
+### 调试命令
+
+```bash
+# 详细日志
+hexo generate --debug
+
+# 检查配置
+hexo config
+
+# 检查版本
+hexo version
+```
+
+## 相关链接
+
+- [Hexo 文档](https://hexo.io/docs/)
+- [NexT 主题文档](https://theme-next.js.org/docs/)
+- [Mermaid 图表语法](https://mermaid.js.org/)
+- [Stylus 文档](https://stylus-lang.com/)
+
+---
+
+*本文档最后更新：2026-02-28*

CLAUDE.md

@@ -6,6 +6,10 @@ This file provides guidance to Claude Code (claude.ai/code) when working with co
 
 这是一个基于 Hexo 静态站点生成器的个人技术博客，使用 Next 主题。博客主要包含 Java、前端开发（React）、架构设计等技术文章。
 
+## 写作要求
+
+基于_posts已有的文章，梳理出我的写作风格，内容要去AI味。内容框架和输出也借助content-research-writer skill
+
 ## 常用命令
 
 ### 开发与预览

source/_data/styles.styl

@@ -484,4 +484,45 @@ code, pre {
 @keyframes twinkle {
   0%, 100% { opacity: 1; }
   50% { opacity: 0.3; }
-}
+}
+
+/* Thumbnails (click to enlarge) */
+.thumb-gallery {
+  display: flex;
+  flex-wrap: wrap;
+  gap: 12px;
+  margin: 12px 0 6px;
+}
+
+.thumb-gallery .thumb-link {
+  display: inline-block;
+  border: 1px solid #e8e8e8;
+  border-radius: 8px;
+  overflow: hidden;
+  box-shadow: 0 1px 2px rgba(0, 0, 0, 0.06);
+  background: #fff;
+}
+
+.thumb-gallery .thumb-link:hover {
+  border-color: #d6d6d6;
+  box-shadow: 0 2px 8px rgba(0, 0, 0, 0.10);
+}
+
+.thumb-gallery .thumb-img {
+  display: block;
+  width: 240px;
+  max-width: 100%;
+  height: auto;
+}
+
+.thumb-note {
+  margin: 0 0 16px;
+  font-size: 12px;
+  color: #666;
+}
+
+@media (max-width: 768px) {
+  .thumb-gallery .thumb-img {
+    width: 100%;
+  }
+}

source/_drafts/从“没写过一行代码”到全职Vibe-Coder：我是如何用AI打破职业边界的-1.md

@@ -0,0 +1,5 @@
+---
+title: 从“没写过一行代码”到全职Vibe Coder：我是如何用AI打破职业边界的
+author: Gamehu
+tags:
+---

source/_posts/AI个人助理搭建实战.md

@@ -0,0 +1,533 @@
+---
+title: 搭建个人AI助理——手把手实战指南
+author: Gamehu
+tags:
+  - PAI
+categories:
+  - AI
+date: 2026-02-11 22:15:00
+---
+
+<div class="tag-container">
+  <span class="ai-tag">AI Infrastructure</span>
+</div>
+
+## 写在前面
+
+最近发现个项目叫 PAI（Personal AI Infrastructure），看了下挺有意思。
+
+核心想法很简单：**把 AI 从"临时工具"变成"持久基础设施"**。
+
+不像 ChatGPT 那种问完就忘，PAI 让 AI 记住你是谁、你在做什么、你之前怎么处理类似问题。用下来最大的感受是：AI 终于不用每次都当陌生人重新认识了。
+
+这篇文章不谈虚的，直接讲怎么搭起来。
+
+> **说明**：以下步骤都是我实际搭建时验证过的，遇到的问题和解决方法也都记录在「踩坑」章节。
+
+{% asset_img pai.jpg %}
+
+---
+
+## 一、核心概念（两分钟看完）
+
+### 1.1 PAI 是什么
+
+| 方面 | ChatGPT | PAI |
+|------|----------|-----|
+| 记忆 | 对话结束就忘 | Hook 驱动的 Memory 系统（WORK/LEARNING/STATE/） |
+| 身份 | 不知道你是谁 | TELOS 系统定义数字身份 |
+| 扩展 | 无 | 39 个 Skills 可扩展 |
+| 定制 | 提示词里重复 | 配置文件化 + Hooks 自动化 |
+| 代理能力 | 单模型 | 13 个专用 Agents（Algorithm/Architect/Engineer 等） |
+
+### 1.2 工具栈
+
+| 工具 | 作用 | 必需/可选 |
+|------|------|----------|
+| Claude Code | AI 运行环境 | 必需 |
+| Bun | TypeScript 运行时 | 必需 |
+| 本地 Markdown | TELOS 和记忆存储 | 必需 |
+| Obsidian | 可视化编辑 TELOS | 可选（推荐） |
+| Git | 版本控制和同步 | 可选 |
+
+**关于 Obsidian**：用 Obsidian 管理 TELOS 文件的好处是有双向链接和图谱视图，能更直观地看到各文件之间的关系。不过如果你习惯用 VS Code 或 vim，也没问题。
+
+---
+
+## 二、安装实战（重点）
+
+> 我的建议是：先跑起来，再慢慢调。别想着一次把所有配置都搞完美。
+
+### 路径 A：官方安装器（推荐）
+
+适合想要完整 PAI 功能的用户（Hooks、Skills、Agents、Voice Server 全套系统）。
+
+```bash
+# 1. 克隆仓库
+git clone https://github.com/danielmiessler/PAI.git ~/Personal_AI_Infrastructure
+
+# 2. 复制配置
+cp -r ~/Personal_AI_Infrastructure/Releases/v3.0/.claude ~/
+
+# 3. 运行安装器（8 步向导）
+cd ~/.claude && bash install.sh
+```
+
+**安装器会自动完成**：
+- 安装 Bun（如果缺失）
+- 创建 TELOS 文件模板
+- 注册所有 Hooks 到 settings.json
+- 配置 `pai` 命令别名
+- （可选）配置 ElevenLabs 语音服务
+
+### 路径 B：轻量 DIY（本文重点）
+
+适合只想快速上手核心身份功能的用户——**手动创建 TELOS + 配置 CLAUDE.md + Obsidian 可视化**。
+
+#### 2.1 创建目录结构
+
+```bash
+# 创建 PAI 基础目录
+mkdir -p ~/.claude/USER/identity
+mkdir -p ~/.claude/MEMORY/WORK
+mkdir -p ~/.claude/MEMORY/LEARNING/SYSTEM
+mkdir -p ~/.claude/MEMORY/LEARNING/ALGORITHM
+mkdir -p ~/.claude/MEMORY/LEARNING/SYNTHESIS
+mkdir -p ~/.claude/MEMORY/LEARNING/SIGNALS
+mkdir -p ~/.claude/MEMORY/RESEARCH
+mkdir -p ~/.claude/MEMORY/SECURITY
+mkdir -p ~/.claude/MEMORY/STATE
+```
+
+创建后的结构：
+```bash
+~/.claude/
+├── CLAUDE.md         # 主入口
+├── settings.json      # 配置文件
+├── skills/           # PAI 技能系统
+├── hooks/            # 20 个生命周期钩子
+├── agents/           # 13 个专用代理
+├── MEMORY/           # 记忆系统
+│   ├── WORK/         # 工作跟踪
+│   ├── LEARNING/      # 学习记录
+│   ├── RESEARCH/      # 研究输出
+│   ├── SECURITY/      # 安全审计
+│   └── STATE/         # 运行时状态
+└── USER/
+    └── identity/      # TELOS 文件
+```
+
+#### 2.2 配置 Obsidian（可选但推荐）
+
+如果你用 Obsidian 管理 TELOS：
+
+1. 打开 Obsidian，点击「创建新 Vault」
+2. Vault 名称：`PAI-Identity`（或其他你喜欢的）
+3. 文件夹路径选择：`~/.claude/USER/identity`
+4. 点击「打开」
+
+{%asset_img obsidian.png Obsidian 创建 Vault %}
+
+这样你的 TELOS 文件就能在 Obsidian 中可视化编辑，还能看到图谱关系。
+
+#### 2.3 创建 TELOS 文件
+
+TELOS 是 5 个核心 Markdown 文件，定义"你是谁"。
+
+先填这 5 个核心文件。下面是我的示例，你可以参考着写自己的：
+
+**IDENTITY.md**：
+
+```markdown
+# Identity
+
+## 基本信息
+
+我是 Gamehu，技术 Leader / 架构师 / 全栈开发者。
+
+## 技术栈
+
+**核心能力**：
+- 后端：Java 专家，多年架构设计经验
+- 前端：React 为主，熟悉现代前端工程化
+- 全栈：能独立完成从数据库到 UI 的完整开发
+
+## 职业定位
+
+- 技术 Leader：负责团队技术方向和决策
+- 架构师：关注系统设计、可扩展性、代码质量
+- 技术影响力：想建立个人技术 IP，做有影响力的人
+
+## 兴趣领域
+
+**技术前沿**：
+- AI / LLM / Agent 开发
+- 新技术趋势跟踪和评估
+- 工具链优化和工程实践
+
+## 性格特质
+
+- 总想走在技术前沿
+- 喜欢了解新事物，但注重实用性
+- 不满足于"够用"，追求"优秀"
+- 想做一款属于自己的产品（网站/软件）
+
+## 沟通风格
+
+- 简洁直接，不绕弯子
+- 实战导向，少谈理论多动手
+- 喜欢用代码和示例说话
+- 中文思考，中文对话
+```
+
+**GOALS.md**：
+
+```markdown
+# Goals
+
+## 长期愿景（3-5 年）
+
+- 建立技术影响力，做有 IP 的人
+- 做一款属于自己的产品
+
+## 中期目标（1 年内）
+
+- 掌握 AI 原生开发能力
+- 持续输出高质量技术内容
+
+## 当前项目
+
+- [ ] 完成 PAI 搭建和优化
+- [ ] AI Agent 开发实践
+- [ ] 技术文章持续输出
+```
+
+**SKILLS.md**：
+
+```markdown
+# Skills
+
+## 技术能力
+
+### 后端 - 专家级
+
+- **Java**：多年实战经验，Spring 生态深入
+- **架构设计**：DDD、微服务、分布式系统
+- **数据库**：PostgreSQL、MySQL、Redis
+- **DevOps**：Docker、K8s、CI/CD
+
+### 前端 - 精通
+
+- **React**：主技术栈，Hooks 生态
+- **前端工程化**：Webpack、构建优化
+- **CSS**：Styled Components、Tailwind
+
+### 全栈
+
+- 能独立完成完整功能开发
+- 前后端联调、部署都在行
+
+## 正在学习
+
+### AI / LLM
+
+- Prompt Engineering
+- Agent 开发（Claude Code、自定义 Agent）
+- RAG 原理和实现
+
+### 技术前沿
+
+- 持续关注新框架、新工具
+```
+
+**VALUES.md**：
+
+```markdown
+# Values
+
+## 核心价值观
+
+- **实用主义**：不折腾，快速验证想法
+- **技术追求**：关注代码质量而非炫技
+- **影响力**：通过技术输出建立个人品牌
+
+## 决策原则
+
+- **简单优于复杂**：能用简单方案就不过度设计
+- **实用优于完美**：先跑起来再优化
+```
+
+**BELIEFS.md**：
+
+```markdown
+# Beliefs
+
+## 关于技术
+
+- 技术是手段，不是目的
+- 架构比实现重要
+- 代码质量是长期价值
+
+## 关于学习
+
+- 深度大于广度
+- 实践驱动学习
+- 记笔记，建立知识体系
+
+## 关于 AI
+
+- AI 是增强，不是替代
+- 上下文是关键
+- 个人 AI 基础设施是未来方向
+```
+
+#### 2.4 更新 CLAUDE.md 主入口
+
+在 `~/.claude/CLAUDE.md` 开头添加 TELOS 引导：
+
+```markdown
+# 你是 Gamehu 的个人 AI 助理
+
+## 你的身份
+
+- 我是 Gamehu，技术 Leader / 架构师 / 全栈开发者
+- 核心技术栈：Java（专家级）、React（精通）、架构设计
+- 目标：建立技术影响力，做有 IP 的人，梦想做一款自己的产品
+
+## TELOS 数字身份
+
+**在每次对话开始时，先阅读以下 TELOS 文件了解我**：
+
+1. `~/.claude/USER/identity/IDENTITY.md` - 我是谁
+2. `~/.claude/USER/identity/SKILLS.md` - 我会什么
+3. `~/.claude/USER/identity/GOALS.md` - 我想达成什么
+4. `~/.claude/USER/identity/VALUES.md` - 我重视什么
+5. `~/.claude/USER/identity/BELIEFS.md` - 我相信什么
+
+## Memory 记忆系统
+
+- 对话中的重要决策和学习，由 Hooks 自动捕获并保存到 `~/.claude/MEMORY/LEARNING/`
+- 主动从我过去的对话中学习，记住我的偏好和决策模式
+- 当我重复问类似问题时，参考我之前的答案
+
+---
+# 任何项目都务必遵守的规则（极其重要！！！）
+```
+
+#### 2.5 配置 pai 命令别名（可选）
+
+在 `~/.zshrc` 末尾追加：
+
+```bash
+# PAI 命令别名
+alias pai='cd ~/.claude && claude'
+```
+
+然后重新加载配置：
+
+```bash
+source ~/.zshrc
+```
+
+#### 2.6 验证配置
+
+重启 Claude Code，然后问：
+
+```
+你知道我是谁吗？
+```
+
+如果 AI 能正确回应你的身份信息（根据 IDENTITY.md），说明配置成功了。
+
+---
+
+## 三、核心组件详解
+
+### 3.1 Memory 系统 v7.0
+
+PAI v3.0 使用新的 Memory 架构（取代旧的 hot/warm/cold 模型）：
+
+| 目录 | 用途 | 格式 |
+|------|------|------|
+| **WORK/** | 工作跟踪，每次会话自动创建 | 目录 + YAML |
+| **LEARNING/** | 从对话中提炼的学习记录 | Markdown + JSONL |
+| **RESEARCH/** | Agents 输出捕捉 | Markdown |
+| **SECURITY/** | 安全审计事件 | JSONL |
+| **STATE/** | 快速运行时数据 | JSON |
+
+**数据流**：
+
+```
+用户请求
+    ↓
+Claude Code projects/ (原生会话存储)
+    ↓
+Hooks 自动捕获：
+    ├── AutoWorkCreation → WORK/
+    ├── ResponseCapture → WORK/, LEARNING/
+    ├── RatingCapture → LEARNING/SIGNALS/
+    └── WorkCompletionLearning → LEARNING/
+```
+
+### 3.2 Skills 系统
+
+PAI 内置 39 个 Skills，涵盖思考、研究、开发、安全等全领域：
+
+| 类别 | 代表 Skills |
+|------|-------------|
+| **核心系统** | PAI, PAIUpgrade, Telos |
+| **思考分析** | Science, FirstPrinciples, IterativeDepth, BeCreative |
+| **研究工具** | Research, OSINT, Recon, Parser |
+| **开发工具** | CreateSkill, CreateCLI, Cloudflare |
+| **内容处理** | Fabric, Documents, ExtractWisdom, WebAssessment |
+| **安全工具** | RedTeam, PromptInjection, SECUpdates |
+| **专用代理** | Agents - 13 个命名 Agent（Algorithm/Architect/Engineer 等） |
+
+**使用方式**：在对话中直接调用，例如 `/science`、`/telos`、`/fabric`。
+
+### 3.3 Hooks 系统
+
+Hooks 在特定生命周期事件时触发，自动执行相应逻辑。PAI v3.0 有 20 个 Hooks：
+
+| Hook 类型 | 触发时机 | 典型 Hooks |
+|----------|----------|-------------|
+| SessionStart | 会话开始 | StartupGreeting, LoadContext, CheckVersion |
+| UserPromptSubmit | 提交问题时 | RatingCapture, AutoWorkCreation, SessionAutoName |
+| PreToolUse | 调用工具前 | SecurityValidator, AgentExecutionGuard, SkillGuard |
+| PostToolUse | 工具调用后 | AlgorithmTracker, QuestionAnswered |
+| SessionEnd | 会话结束 | WorkCompletionLearning, SessionSummary, UpdateCounts |
+
+**Hooks 是 TypeScript 脚本**，需要 Bun 运行时来执行。这就是为什么安装 Bun 是必需的。
+
+### 3.4 Agents 系统
+
+PAI 提供 13 个专用 Agent，每个都有明确的 persona 和专长：
+
+| Agent | 专长 | 用途 |
+|-------|------|------|
+| **Algorithm** | ISC 专家，验证纯粹主义者 | 系统化问题解决 |
+| **Architect** | 系统设计 | 架构规划和设计 |
+| **Engineer** | 构建和实现 | 代码实现 |
+| **Designer** | 设计决策 | UI/UX 设计 |
+| **QATester** | 质量保证 | 测试和验证 |
+| **Intern** | 学习和初级任务 | 辅助性任务 |
+
+---
+
+## 四、日常使用
+
+### 4.1 常用 Skills
+
+| 命令 | 作用 |
+|------|------|
+| `/science` | 科学方法思考和迭代 |
+| `/telos` | 管理 TELOS（个人 + 项目分析） |
+| `/fabric` | 240+ 种提示词模式（提取、总结等） |
+| `/brainstorm` | 创意风暴和需求分析 |
+
+### 4.2 典型工作流
+
+```
+启动 Claude Code → AI 加载 TELOS → 执行任务 → Hooks 自动捕获学习
+```
+
+---
+
+## 五、踩坑记录（实战验证）
+
+### 5.1 Bun 未安装
+
+**问题**：Hooks 是 TypeScript 脚本，执行需要 Bun。如果 Bun 没有安装，Hooks 无法运行。
+
+**解决**：
+```bash
+curl -fsSL https://bun.sh/install | bash
+source ~/.zshrc
+bun --version  # 验证安装
+```
+
+### 5.2 Memory 目录未创建
+
+**问题**：首次使用时，MEMORY/ 下的子目录（WORK/、LEARNING/ 等）不存在，Hooks 会报错。
+
+**解决**：
+```bash
+# 创建完整的 Memory v7.0 目录结构
+mkdir -p ~/.claude/MEMORY/WORK
+mkdir -p ~/.claude/MEMORY/LEARNING/SYSTEM
+mkdir -p ~/.claude/MEMORY/LEARNING/ALGORITHM
+mkdir -p ~/.claude/MEMORY/LEARNING/SYNTHESIS
+mkdir -p ~/.claude/MEMORY/LEARNING/SIGNALS
+mkdir -p ~/.claude/MEMORY/RESEARCH
+mkdir -p ~/.claude/MEMORY/SECURITY
+mkdir -p ~/.claude/MEMORY/STATE
+```
+
+### 5.3 Hooks 未注册
+
+**问题**：Hooks 文件存在但没有在 settings.json 中注册，导致不会触发。
+
+**解决**：确保 settings.json 中包含完整的 hooks 配置（参考官方模板）。
+
+### 5.4 TELOS 路径错误
+
+**问题**：CLAUDE.md 中引用的 TELOS 文件路径与实际位置不符。
+
+**检查**：
+```bash
+ls ~/.claude/USER/identity/
+# 应该看到 IDENTITY.md, SKILLS.md, GOALS.md, VALUES.md, BELIEFS.md
+```
+
+### 5.5 图片文件名不匹配
+
+**问题**：Hexo 的 `asset_img` 标签引用的文件名与实际文件名不一致。
+
+**解决**：确保引用名称与实际文件名完全一致（包括扩展名）。
+
+---
+
+## 六、Obsidian 进阶配置
+
+如果你用 Obsidian 管理 TELOS，有几个插件值得装：
+
+| 插件 | 作用 |
+|------|------|
+| Graph Analysis | 可视化 TELOS 各文件的关系 |
+| Dataview | 查询和汇总 TELOS 内容 |
+| Templates | 快速创建新 TELOS 条目 |
+
+**一个小技巧**：在 Obsidian 中设置 `[[GOALS]]` 为首页，每次打开都能看到当前目标。
+
+---
+
+## 七、延伸思考
+
+PAI 让我重新思考了 AI 的使用方式。
+
+以前把 AI 当"临时工"，用完就扔。现在更像"长期助理"，相处越久越懂你。
+
+**关键区别**：不是模型更强，而是上下文更完整。
+
+当 AI 知道你的背景、理解你的目标、记住你的决策历史，它给出的建议就不再泛泛而谈，而是真正贴合你的情况。
+
+这才是"个人" AI 的含义。
+
+---
+
+## 八、参考资源
+
+- [PAI 官方仓库](https://github.com/danielmiessler/PAI)
+- [原推文](https://x.com/vista8/status/2021240338908876854) - @vista8 对 PAI 概念的深入解析
+- [PAI v3.0 Release Notes](https://github.com/danielmiessler/PAI/releases)
+- [Obsidian 下载](https://obsidian.md/)
+
+---
+
+### 最后
+
+没有银弹。
+
+PAI 不是万能药，它只是一个框架，让你更系统地使用 AI。
+
+真正有价值的是：**你有意识地构建自己的数字基础设施**，而不是每次都从头开始。

source/_posts/Claude-Code创始人的13条实战秘籍.md

@@ -0,0 +1,331 @@
+---
+title: Claude Code创始人的13条实战秘籍
+author: Gamehu
+date: 2026-02-27 22:15:00
+tags:
+  - Claude Code
+  - AI
+  - 效率工具
+categories:
+  - 工具
+---
+<div class="tag-container">
+  <span class="ai-tag">Claude Code</span>
+  <span class="sub-tag">实战</span>
+</div>
+
+## 起因
+
+最近看到 Claude Code 的创始人 Boris Cherny 在 Twitter 上分享了自己使用 Claude Code 的 13 条核心技巧。
+
+这个人不是普通用户,他是 Claude Code 的核心开发者之一。
+
+他的配置,他的习惯,肯定有东西值得学习。
+
+## 技巧一:保持默认配置
+
+如果你不会调,就<span class="highlight-text">别调</span>。
+
+Boris 说,因为他们团队都在深度使用 Claude Code,所以默认配置已经优化得挺好的了。
+
+新手容易犯的错误:
+- 看到各种配置就想调
+- 调完反而用不好
+- 默认配置其实已经够用了
+
+建议:
+- 先用默认配置
+- 等熟悉了再考虑个性化
+- 大部分场景,默认就够用
+
+## 技巧二:并行多个任务
+
+<span class="gradient-text">不要盯着一个任务等结果</span>。
+
+Claude 是机器人,不是活人。它可以同时处理很多事情。
+
+Boris 的习惯是同时运行 5 到 10 个 Claude 任务。
+
+怎么操作:
+- 在不同终端窗口开多个任务
+- 或者用 `/goal` 命令并行执行
+- 让 Claude 后台自动排队处理
+
+好处:
+- 不用等一个任务完成才开下一个
+- 总体完成速度更快
+- 充分利用 Claude 的并发能力
+
+## 技巧三:无人值守模式
+
+长任务的时候,别一直守着点"批准"。
+
+Boris 用的是 `--permission-mode=dontAsk` 参数。
+
+这个参数的意思是:
+- Claude 可以自己执行命令
+- 不用等用户确认
+- 适合那种不需要人工干预的任务
+
+适用场景:
+- 批量代码重构
+- 自动化测试
+- 文档生成
+- 代码审查
+
+注意事项:
+- 敏感操作不要用这个模式
+- 文件系统权限操作要小心
+
+## 技巧四:使用 Chrome 扩展自动测试
+
+这是个很实用的技巧。
+
+Boris 用 Chrome 扩展让 Claude 自己打开浏览器测试 UI。
+
+工作流:
+1. Claude 修改前端代码
+2. 自动打开浏览器测试
+3. 发现问题
+4. 自动修复
+5. 再测试
+6. 直到完美
+
+好处:
+- 不用自己手动打开浏览器
+- 测试-修复循环自动化
+- 用户体验问题能快速迭代
+
+## 技巧五:agent stop 钩子验证
+
+任务完成后,不是直接提交。
+
+Boris 配了个钩子:agent stop。
+
+这个钩子会:
+- 自动验证代码
+- 跑测试
+- 检查代码质量
+- 验证通过才完成
+
+如果验证失败:
+- Claude 继续修复
+- 再验证
+- 直到通过
+
+好处:
+- 质量有保障
+- 不用人工手动验证
+- 形成自动化的闭环
+
+## 技巧六:共享知识库 CLAUDE.md
+
+这个点很重要。
+
+Boris 的团队共用一个 CLAUDE.md 文件。
+
+放在哪?放在 Git 仓库里。
+
+更新频率:团队成员每周都会多次更新。
+
+更新什么?
+- 发现 Claude 哪里做错了
+- 就把规矩写进 CLAUDE.md
+- 确保它下次不再犯同样的错误
+
+效果:
+- 团队知识沉淀
+- 避免重复犯错
+- 集体优化使用方式
+
+## 技巧七:保持简单配置
+
+Boris 说,他的配置可能出乎意料地"素"。
+
+意思就是:<span class="highlight-text">简单</span>。
+
+为什么?
+- Claude Code 开箱即用非常出色
+- 大部分场景不需要自定义
+- 复杂配置反而容易出问题
+
+建议:
+- 能不用插件就不用
+- 能不改配置就不改
+- 保持系统简洁
+
+## 技巧八:团队协作规范
+
+不是一个人用,是整个团队怎么用。
+
+Boris 团队的做法:
+- 统一的 CLAUDE.md
+- 统一的钩子配置
+- 统一的权限设置
+- 统一的项目结构
+
+好处:
+- 团队协作顺畅
+- 知识可以共享
+- 问题可以快速定位
+
+## 技巧九:合理使用 MCP
+
+MCP (Model Context Protocol) 是 Claude 的扩展机制。
+
+Boris 的建议:
+- 不要装太多 MCP 服务器
+- 装真正有用的
+- 配置好访问权限
+
+原因:
+- MCP 服务器多了,反而慢
+- 每个都要授权,麻烦
+- 质量参差不齐
+
+## 技巧十:善用 /goal 命令
+
+`/goal` 命令可以并行执行多个任务。
+
+例子:
+```
+/goal
+1. 重构用户模块
+2. 更新 API 文档
+3. 添加单元测试
+4. 修复已知 bug
+```
+
+Claude 会:
+- 同时执行这些任务
+- 自动处理依赖关系
+- 高效完成
+
+## 技巧十一:长任务拆分
+
+太长的任务,Claude 容易跑偏。
+
+Boris 的做法:
+- 拆分成多个小任务
+- 每个任务有明确目标
+- 串行或并行执行
+
+好处:
+- 每个任务更容易控制
+- 出问题容易定位
+- 进度更清晰
+
+## 技巧十二:善用上下文
+
+Claude 能记住的上下文有限。
+
+Boris 的建议:
+- 重要信息一开始就给
+- 不要分多次重复说
+- 用文件记录长期信息
+
+比如:
+- 项目架构写在 CLAUDE.md 里
+- 业务规则也写进去
+- Claude 可以随时读取
+
+## 技巧十三:持续反馈和优化
+
+不是一次配好就完了。
+
+Boris 团队的做法:
+- 每周多次更新 CLAUDE.md
+- 发现问题马上记录
+- 团队分享最佳实践
+- 持续优化使用方式
+
+本质:
+- 把 Claude 当作团队成员
+- 不断培训它
+- 优化它的工作方式
+
+## 我的一些实践
+
+用了 Claude Code 一段时间,我也积累了一些经验。
+
+### 我的配置
+
+1. **保持默认配置**
+   基本上没怎么调,默认就够用
+
+2. **并行任务**
+   经常同时开 2-3 个任务
+
+3. **简单的钩子**
+   只配置了必要的几个
+
+4. **我的 CLAUDE.md**
+   项目根目录放了个文件,记录了一些项目特有的事
+
+### 我的感受
+
+Claude Code 确实好用。
+
+但它的价值,不是简单地"帮我写代码"。
+
+而是:<span class="gradient-text">成为你工作流的一部分</span>。
+
+- 你教它规则
+- 它按规则干活
+- 出错了你纠正
+- 下次它就学会了
+
+这个循环持续优化,你的"AI 助手"会越来越聪明。
+
+## 给使用 Claude Code 的建议
+
+### 新手建议
+
+1. <span class="highlight-text">先用默认配置</span>
+   别一上来就调配置,默认其实挺好用
+
+2. <span class="highlight-text">从简单任务开始</span>
+   先让它干些简单的,熟悉了再上复杂任务
+
+3. <span class="highlight-text">善用 /goal</span>
+   多个相关任务,用 /goal 一起执行
+
+### 进阶建议
+
+1. <span class="highlight-text">配置你的 CLAUDE.md</span>
+   项目相关的规则、架构、约定都写进去
+
+2. <span class="highlight-text">设置自动化钩子</span>
+   agent stop 之类的钩子配置好
+
+3. <span class="highlight-text">合理使用 MCP</span>
+   装真正有用的,别太多
+
+### 团队建议
+
+1. <span class="highlight-text">统一配置</span>
+   团队用统一的 CLAUDE.md,统一的钩子
+
+2. <span class="highlight-text">定期分享</span>
+   定期分享使用心得,最佳实践
+
+3. <span class="highlight-text">持续优化</span>
+   把 Claude 当团队成员,持续培训它
+
+## 写在最后
+
+Boris 的这 13 条技巧,核心思想就一个:
+
+<span class="gradient-text">把 Claude Code 当作你团队的一部分,而不是一个工具。</span>
+
+- 它会犯错,就像人一样
+- 你要纠正它,就像指导新人一样
+- 它会学习,就像积累经验一样
+
+持续优化,持续反馈,它就会越来越懂你的项目,越来越懂你的需求。
+
+这比单纯"让它帮我写代码"要有用得多。
+
+参考:
+- 原推: https://x.com/bcherny/status/2007179832300581177
+- 官方文档: https://code.claude.com

source/_posts/Claude-Code多智能体编排实战-wshobson-agents深度解析.md

@@ -0,0 +1,505 @@
+---
+title: Claude Code 多智能体编排实战：wshobson/agents 深度解析
+author: Gamehu
+date: 2026-02-28 22:45:00
+tags:
+  - AI
+  - Agent
+  - Claude Code
+  - 效率提升
+categories:
+  - AI
+---
+
+<div class="tag-container">
+  <span class="ai-tag">AI</span>
+  <span class="sub-tag">Claude Code</span>
+  <span class="sub-tag">多智能体</span>
+</div>
+
+## 缘起
+
+前段时间写了 OpenClaw 那篇文章，讲怎么用编排层管理多个 AI 代理。最近发现一个 GitHub 项目 <span class="highlight-text">wshobson/agents</span>，这是一个专门为 Claude Code 打造的多智能体编排系统。不是那种概念性的演示，而是真刀真枪的生产级工具。
+
+让我震撼的几个数字：
+
+- <span class="gradient-text">112 个专业 AI Agent</span>
+- <span class="gradient-text">16 个多智能体工作流编排器</span>
+- <span class="gradient-text">146 个 Agent Skills</span>
+- <span class="gradient-text">79 个开发工具</span>
+- <span class="gradient-text">72 个独立插件</span>
+
+这已经不是"用 AI 辅助编程"了，这是<span class="highlight-text">用 AI 团队替代开发团队</span>。
+
+## 核心架构：插件化设计
+
+wshobson/agents 最聪明的设计是<span class="highlight-text">插件化</span>。
+
+它不是给你一个大而全的系统，让你把所有东西都加载进来。而是拆成 72 个独立的插件，每个插件只做一件事，但做到极致。
+
+### 为什么要插件化？
+
+上下文窗口是有限的资源。如果你一次性加载 112 个 Agent 和 146 个 Skills， token 消耗会爆炸。
+
+插件化的解决方案：<span class="highlight-text">按需加载</span>。
+
+举个例子：
+
+```bash
+# 安装 Python 开发插件
+/plugin install python-development
+```
+
+这个插件只加载：
+- 3 个 Python 专业 Agent
+- 1 个脚手架工具
+- 16 个专业 Skills
+
+总共约 1000 个 token，而不是整个市场的几万 token。
+
+### 插件的分类
+
+72 个插件分成 24 个类别，每个类别 1-6 个插件：
+
+| 类别 | 插件数量 | 典型插件 |
+|------|---------|---------|
+| 开发 | 4 | debugging, backend, frontend, multi-platform |
+| 工作流 | 5 | git, full-stack, TDD, Conductor, Agent Teams |
+| 语言 | 7 | Python, JS/TS, JVM, 系统语言等 |
+| 基础设施 | 5 | K8s, 云, CI/CD, 部署 |
+| AI/ML | 4 | LLM 应用, Agent 编排, MLOps |
+| 安全 | 4 | 扫描, 合规, API 安全 |
+| 营销 | 4 | SEO 内容, 技术 SEO, 内容营销 |
+
+这种结构的好处是：<span class="highlight-text">想用啥装啥，绝不多加载</span>。
+
+## 三层模型策略
+
+这个项目最让我印象深刻的是它的<span class="highlight-text">模型分层策略</span>。
+
+不是一刀切地用同一个模型，而是根据任务复杂度分配不同的 Claude 模型：
+
+| 层级 | 模型 | Agent 数量 | 用途 |
+|------|------|-----------|------|
+| Tier 1 | Opus 4.6 | 42 | 关键架构、安全审计、代码审查、生产级编码 |
+| Tier 2 | Inherit | 42 | 复杂任务，由用户选择模型 |
+| Tier 3 | Sonnet | 51 | 中等复杂度任务 |
+| Tier 4 | Haiku | 18 | 快速操作任务 |
+
+### 为什么 Opus 4.6 负责关键任务？
+
+几个硬指标：
+
+- <span class="highlight-text">SWE-bench 80.8%</span> — 行业领先
+- <span class="highlight-text">复杂任务 token 减少 65%</span>
+- 最适合架构决策和安全审计
+
+虽然 Opus 单价高（$5/$25 每百万 token），但因为 token 效率更高，实际成本往往更低。
+
+### Tier 2 的灵活性
+
+Tier 2 的 Agent 标记为 `inherit`，意思是使用你当前会话的默认模型。
+
+怎么用？
+
+```bash
+# 启动会话时指定模型
+claude --model opus    # 需要高强度时用 Opus
+claude --model sonnet  # 日常开发用 Sonnet
+```
+
+这样你可以根据当前任务灵活选择，不用改配置。
+
+## Agent Teams：真正的并行工作流
+
+这是我觉得最实用的功能：多智能体并行。
+
+安装 Agent Teams 插件：
+
+```bash
+/plugin install agent-teams@claude-code-workflows
+```
+
+### 7 个预设团队
+
+| 团队 | 用途 |
+|------|------|
+| review | 并行代码审查 |
+| debug | 假设驱动的调试 |
+| feature | 并行功能开发 |
+| fullstack | 全栈开发 |
+| research | 并行调研 |
+| security | 安全审计 |
+| migration | 迁移支持 |
+
+### 实战示例：并行代码审查
+
+```bash
+/team-review src/ --reviewers security,performance,architecture
+```
+
+这个命令会：
+
+1. 启动 3 个审查 Agent（安全、性能、架构）
+2. 每个 Agent 独立审查代码
+3. 汇总结果，生成综合报告
+
+传统的代码审查是串行的：一个人看完再给下一个人。现在是<span class="highlight-text">三个人同时看</span>，时间从几小时缩短到几分钟。
+
+### 实战示例：假设驱动调试
+
+```bash
+/team-debug "API returns 500" --hypotheses 3
+```
+
+系统会：
+
+1. 生成 3 个关于 500 错误的假设
+2. 每个假设分配一个 Agent 去验证
+3. 并行执行验证
+4. 返回最可能的根因
+
+这比一个人一个个尝试 hypotheses 快多了。
+
+## Conductor：项目管理的 AI 化
+
+另一个强大的插件是 Conductor，它把 Claude Code 变成了项目管理工具。
+
+```bash
+/plugin install conductor@claude-code-workflows
+```
+
+### 核心工作流
+
+**1. 交互式项目初始化**
+
+```bash
+/conductor:setup
+```
+
+这个命令会：
+- 创建产品愿景
+- 确定技术栈
+- 定义工作流规则
+- 生成代码风格指南
+
+**2. 基于 Track 的开发**
+
+```bash
+/conductor:new-track
+```
+
+生成规格说明和分阶段实施计划。
+
+**3. TDD 工作流**
+
+```bash
+/conductor:implement
+```
+
+执行任务，带验证检查点。
+
+**4. 语义化回滚**
+
+```bash
+/conductor:revert
+```
+
+按逻辑单元回滚（track、phase 或 task）。
+
+### 状态持久化
+
+项目上下文跨会话持久保存。你今天设置的项目，明天打开 Claude Code 还能继续。
+
+## Skills：渐进式知识披露
+
+146 个 Skills 是 wshobson/agents 的知识层。
+
+每个 Skill 是一个专门的知识包，遵循<span class="highlight-text">渐进式披露</span>架构：
+
+| 层级 | 内容 | 加载时机 |
+|------|------|---------|
+| Metadata | 名称和激活条件 | 始终加载 |
+| Instructions | 核心指导 | 激活时加载 |
+| Resources | 示例和模板 | 按需加载 |
+
+### Skills 的分类
+
+**语言开发：**
+- Python（5 个）：async 模式、测试、打包、性能、UV 包管理
+- JavaScript/TypeScript（4 个）：高级类型、Node.js 模式、测试、ES6+
+
+**基础设施：**
+- Kubernetes（4 个）：manifest、Helm、GitOps、安全策略
+- 云基础设施（4 个）：Terraform、多云、混合网络、成本优化
+- CI/CD（4 个）：流水线设计、GitHub Actions、GitLab CI、密钥管理
+
+**AI/ML：**
+- LLM 应用（8 个）：LangGraph、Prompt Engineering、RAG、评估、embedding、相似性搜索、向量调优、混合搜索
+
+**区块链：**
+- Web3（4 个）：DeFi 协议、NFT 标准、Solidity 安全、Web3 测试
+
+### 激活示例
+
+当你使用 Python 开发插件时，相关 Skills 会自动激活：
+
+```
+用户："创建一个 FastAPI 微服务"
+
+系统激活：
+- async-python-patterns
+- python-testing-patterns  
+- uv-package-manager
+```
+
+你不需要手动选择，系统根据上下文自动加载。
+
+## 实战：从零搭建全栈功能
+
+让我用一个完整示例展示这套系统的能力。
+
+### 场景：添加用户认证功能
+
+**传统方式：**
+1. 设计数据库表（1 小时）
+2. 写后端 API（4 小时）
+3. 写前端页面（4 小时）
+4. 写测试（2 小时）
+5. 代码审查（1 小时）
+6. 部署（1 小时）
+
+**使用 wshobson/agents：**
+
+```bash
+# 安装必要插件
+/plugin install full-stack-orchestration
+/plugin install python-development
+/plugin install backend-development
+
+# 启动全栈编排
+/full-stack-orchestration:full-stack-feature "user authentication with OAuth2"
+```
+
+系统会协调 7+ 个 Agent：
+
+1. **backend-architect** → 设计 API 架构
+2. **database-architect** → 设计数据库 schema
+3. **frontend-developer** → 实现登录 UI
+4. **test-automator** → 生成单元测试和 E2E 测试
+5. **security-auditor** → 安全审计
+6. **deployment-engineer** → 配置部署
+7. **observability-engineer** → 设置监控
+
+这些 Agent <span class="highlight-text">并行工作</span>，不是串行。
+
+结果：
+- 时间从 13 小时缩短到 <span class="gradient-text">30 分钟</span>
+- 包含安全审计和测试覆盖
+- 自动部署和监控
+
+### 安全加固示例
+
+```bash
+/plugin install security-scanning
+/security-scanning:security-hardening --level comprehensive
+```
+
+这个命令会启动多 Agent 安全评估：
+- SAST 扫描
+- 依赖项扫描
+- 代码审查
+- 合规检查
+
+### Python 项目脚手架
+
+```bash
+/plugin install python-development
+/python-development:python-scaffold fastapi-microservice
+```
+
+自动激活的 Skills：
+- `async-python-patterns` - AsyncIO 和并发
+- `python-testing-patterns` - pytest 和 fixtures
+- `uv-package-manager` - 快速依赖管理
+
+生成的项目包含：
+- 生产级 FastAPI 结构
+- 异步模式最佳实践
+- 完整的测试套件
+- Dockerfile 和 docker-compose
+- CI/CD 配置
+
+## 成本分析
+
+大家最关心的：这得花多少钱？
+
+### 模型成本
+
+| 模型 | 输入 | 输出 |
+|------|------|------|
+| Opus 4.6 | $5/百万 token | $25/百万 token |
+| Sonnet 4.6 | $3/百万 token | $15/百万 token |
+| Haiku 4.5 | $1/百万 token | $5/百万 token |
+
+### 实际使用成本
+
+一个小型项目团队（3-5 人）的月度估算：
+
+- 日常开发（Sonnet）：$50-100/月
+- 关键架构审查（Opus）：$30-50/月
+- 自动化任务（Haiku）：$10-20/月
+
+**总计：$90-170/月**
+
+对比：
+- 一个初级开发者的工资：$3000-5000/月
+- 这个系统的成本：<span class="highlight-text">1/30</span>
+
+ROI 非常明显。
+
+### 省钱技巧
+
+1. <span class="highlight-text">用 `inherit` 模式灵活选择模型</span>
+   - 日常开发用 Sonnet
+   - 关键任务切换到 Opus
+
+2. <span class="highlight-text">合理拆分任务</span>
+   - 大任务拆成小任务
+   - 减少单次调用的 token 消耗
+
+3. <span class="highlight-text">利用 Skills 的渐进披露</span>
+   - 只在需要时加载详细知识
+   - 避免不必要的资源加载
+
+## 与 OpenClaw 的对比
+
+有人可能会问：这个和之前写的 OpenClaw 有什么区别？
+
+| 维度 | wshobson/agents | OpenClaw |
+|------|-----------------|----------|
+| 平台 | Claude Code 原生 | 独立编排层 |
+| Agent 数量 | 112 个专业 Agent | 自定义配置 |
+| 集成深度 | 深度集成 | 外部编排 |
+| 使用门槛 | 较低（安装插件即可） | 较高（需要配置） |
+| 灵活性 | 结构化工作流 | 自由编排 |
+| 成本模型 | 按 token 计费 | 自托管成本 |
+
+**我的建议：**
+
+- 如果你已经在用 Claude Code，<span class="highlight-text">直接上 wshobson/agents</span>
+- 如果你需要更灵活的编排或有特殊需求，考虑 OpenClaw
+- 两者也可以结合：用 OpenClaw 做高层编排，wshobson/agents 做具体执行
+
+## 个人思考
+
+用了一段时间 wshobson/agents，有几个感触：
+
+### 1. 专业化分工是趋势
+
+不是让一个大模型做所有事，而是让多个专业 Agent 各做各的。
+
+就像真正的开发团队：
+- 架构师做设计
+- 后端写 API
+- 前端做界面
+- 测试写用例
+- 运维管部署
+
+AI Agent 也在走这条路。
+
+### 2. 编排层的价值被低估了
+
+很多人关注单个 Agent 的能力，但<span class="highlight-text">编排层才是放大器</span>。
+
+好的编排可以让 10 个普通 Agent 发挥 100 个 Agent 的效果。
+
+### 3. 上下文管理是关键
+
+wshobson/agents 的插件化和渐进披露设计，本质上是在解决上下文管理问题。
+
+有限的上下文窗口 → 按需加载 → 最大化利用
+
+这是所有 AI 系统都要面对的挑战。
+
+### 4. 成本可控比想象中容易
+
+很多人被 Opus 的价格吓到，但：
+- 大部分任务用 Sonnet 就够了
+- Opus 的 token 效率更高
+- 合理分层后，实际成本很低
+
+### 5. 未来是"人机协作团队"
+
+不是 AI 替代人类，而是<span class="highlight-text">人类+AI 团队</span>替代传统团队。
+
+一个产品经理 + wshobson/agents = 一个完整开发团队
+
+这不是科幻，是现在就能实现的事。
+
+## 如何开始
+
+### 第一步：添加插件市场
+
+```bash
+/plugin marketplace add wshobson/agents
+```
+
+### 第二步：浏览可用插件
+
+```bash
+/plugin
+```
+
+### 第三步：安装你需要的
+
+```bash
+# 基础开发
+/plugin install python-development
+/plugin install javascript-typescript
+
+# 代码审查
+/plugin install comprehensive-review
+
+# 全栈工作流
+/plugin install full-stack-orchestration
+
+# 多智能体团队
+/plugin install agent-teams
+```
+
+### 第四步：开始使用
+
+```bash
+# 并行审查
+/team-review src/
+
+# 全栈功能开发
+/full-stack-orchestration:full-stack-feature "your feature"
+
+# Python 脚手架
+/python-development:python-scaffold your-project
+```
+
+## 写在最后
+
+wshobson/agents 让我看到了 AI 辅助开发的<span class="highlight-text">下一个阶段</span>。
+
+不是更好的单轮对话，不是更长的上下文窗口，而是<span class="gradient-text">系统化的多智能体协作</span>。
+
+112 个 Agent、16 个编排器、146 个 Skills — 这些数字背后是一个清晰的愿景：
+
+> **让一个人拥有整个团队的能力。**
+
+这不是取代人类，而是给人类超能力。
+
+你仍然是决策者、架构师、审查者。但执行层面的工作，可以交给这个永不疲倦的 AI 团队。
+
+未来已来，只是分布不均。
+
+## 参考
+
+- 项目地址：https://github.com/wshobson/agents
+- Claude Code 文档：https://code.claude.com
+- Agent Teams 文档：项目中查看 `/agent-teams`
+- Conductor 文档：项目中查看 `/conductor`

source/_posts/Claude-Code手机远程控制实战.md

@@ -0,0 +1,369 @@
+---
+title: Claude Code 手机远程控制实战：iPhone 用户指南
+author: Gamehu
+date: 2026-02-26 22:30:00
+tags:
+  - Claude Code
+  - AI
+  - 效率工具
+categories:
+  - 工具
+---
+<div class="tag-container">
+  <span class="ai-tag">Claude Code</span>
+  <span class="sub-tag">实战</span>
+</div>
+
+## 背景
+
+Anthropic 最近给 Claude Code 加了个 Remote Control 功能,简单说就是<span class="highlight-text">可以用手机或其他设备远程控制本地终端</span>。
+
+用起来感觉挺方便的:
+- 在电脑上启动任务
+- 在手机上接着继续干
+- 本地环境、MCP 服务器、项目配置全都保留
+- 上下文不丢失
+
+这篇文章主要记录我自己的<span class="gradient-text">iPhone + Claude Code Remote Control</span>实战经验。
+
+## 一、前提条件
+
+### 1. 订阅要求
+
+Remote Control 目前需要 Pro 或 Max 订阅。
+- Pro 用户:估计很快就会全量放开
+- Max 用户:现在就能用(我用的就是 Max)
+
+<span class="warning">API 密钥不支持这个功能。</span>
+
+### 2. 登录认证
+
+在终端里跑:
+```bash
+claude /login
+```
+
+会跳到浏览器,让你登录 claude.ai 账号。
+
+### 3. 工作区信任
+
+第一次在项目目录跑 `claude`,会弹个窗口问你是否信任这个工作区。
+
+一定要点<span class="highlight-text">Yes</span>,不然用不了。
+
+## 二、安装 Claude App(手机端)
+
+### iOS 用户
+
+在 App Store 搜 "Claude by Anthropic",认准官方的。
+
+或者用电脑端的 `/mobile` 命令,会弹个 QR 码,手机一扫就能直接跳到下载页面。
+
+### Android 用户
+
+Google Play 搜 "Claude by Anthropic"。
+
+装好后用手机浏览器登录同一个 claude.ai 账号。
+
+## 三、启动远程控制
+
+有两种方式,看你在什么场景。
+
+### 方式一:直接启动新会话
+
+在项目目录下:
+
+```bash
+claude remote-control
+# 或者简写
+claude rc
+```
+
+终端会显示:
+- 一个 session URL
+- 提示你按空格键显示 QR 码
+
+进程会一直跑着,等你连。
+
+### 方式二:在现有会话中开启
+
+如果你已经在 Claude Code 里干活了,想切换到手机上:
+
+```
+/remote-control
+# 或者简写
+/rc
+```
+
+当前对话会直接带过去,不用重新开始。
+
+<span class="important-note">提示:用 `/rename` 先给会话起个名字,手机上好找。</span>
+
+### 常用参数
+
+启动的时候可以加参数:
+
+```bash
+claude remote-control --verbose
+```
+
+`--verbose`:显示详细的连接日志,方便调试。
+
+## 四、用 iPhone 连接
+
+终端显示 QR 码和 URL 后,你有三种方式连。
+
+### 方式一:扫 QR 码(推荐)
+
+1. 电脑终端按空格键,显示 QR 码
+2. iPhone 打开 Claude App
+3. 点右上角扫描图标
+4. 对准 QR 码扫一下
+
+秒连上。
+
+### 方式二:打开 URL
+
+终端会显示个类似这样的链接:
+
+```
+https://claude.ai/code/session/xxxxxxxxxxxxx
+```
+
+用 iPhone 的 Safari 直接打开就行。
+
+### 方式三:在 App 里找
+
+打开 Claude App,进 session 列表。
+
+Remote Control 的会话会显示一个电脑图标,带个绿点,表示在线。
+
+<span class="highlight-text">建议先给会话起名字,不然都叫"Remote Control session"很难分。</span>
+
+## 五、实际使用场景
+
+### 场景一:躺沙发上继续
+
+白天在电脑上启动个任务:
+```bash
+claude rc
+```
+
+跑起来了,晚上躺沙发上:
+- 手机 Claude App 扫码连接
+- 接着白天的工作继续
+- 看到本地环境的所有内容
+
+### 场景二:会议中监控
+
+让 Claude 在本地跑个长任务:
+```bash
+claude rc
+```
+
+开会的时候,用手机时不时看看进度:
+- 看到工具调用日志
+- 看到输出结果
+- 随时发送新指令
+
+### 场景三:通勤路上查看
+
+早上在电脑启动会话,上班路上:
+- 手机打开查看当前状态
+- 看到昨天的工作上下文
+- 回复一些简单的指令
+
+到了公司,电脑接着干。
+
+## 六、自动开启远程控制(可选)
+
+默认得手动输 `/rc` 才能远程控制。
+
+想<span class="highlight-text">每次都自动开启</span>:
+
+在 Claude Code 里输:
+```
+/config
+```
+
+把 <span class="gradient-text">"Enable Remote Control for all sessions"</span> 设成 true。
+
+以后每次启动 Claude Code,默认都支持远程控制。
+
+## 七、一些注意事项
+
+### 1. 一个会话只能一个远程连接
+
+同时只能一个设备连。
+但可以在终端、浏览器、手机之间轮着来发消息,上下文是同步的。
+
+### 2. 终端不能关
+
+Remote Control 是本地进程,终端关了会话就断了。
+
+再连的话重新跑:
+```bash
+claude rc
+```
+
+### 3. 网络断了别慌
+
+电脑如果在,但网络断了超过大概 10 分钟,会话会超时退出。
+
+电脑恢复网络后,重新 `claude rc` 就行。
+
+### 4. 手机端只是个窗口
+
+重要理解:
+
+<span class="warning">代码在你本地跑,不是在云端跑。</span>
+
+手机 Claude App 或者网页端,只是个窗口,让你能看到和操作本地会话。
+
+- 本地文件系统访问
+- MCP 服务器
+- 项目配置
+
+这些全都保留在本地。
+
+## 八、Remote Control vs 网页版 Claude Code
+
+这两个长得一样,但本质不同:
+
+| | Remote Control | 网页版 Claude Code |
+|---|---|---|
+| 执行位置 | 你的本地机器 | Anthropic 管的云端 |
+| 本地文件系统 | 可访问 | 不访问 |
+| MCP 服务器 | 可用 | 不用 |
+| 项目配置 | 保留 | 重新配置 |
+| 使用场景 | 本地工作,想换个设备接着干 | 快速启动,不需要本地环境 |
+
+**建议**:
+- 本地有项目,想换个设备接着干 → Remote Control
+- 快速测试,不需要本地环境 → 网页版
+- 多任务并行 → 网页版
+
+## 九、我的实际体验
+
+用了几天,说说感受。
+
+### 好的地方
+
+1. **上下文不丢失**
+   从电脑切换到手机,对话历史全在
+   不用重新解释之前干到哪了
+
+2. **本地环境完全保留**
+   MCP 服务器能用
+   本地文件能访问
+   项目配置不用重新配
+
+3. **灵活切换设备**
+   终端发一条
+   浏览器发一条
+   手机再发一条
+
+   都在同一个会话里。
+
+4. **支持断线重连**
+   网络断了自动重连
+   只要电脑还在,不会丢
+
+### 需要注意的地方
+
+1. **一次只能一个远程连接**
+   多设备同时连不了
+
+2. **终端不能关**
+   关了就断了
+
+3. **Mac 优先**
+   目前功能是 Research Preview,Max 用户先用上
+
+## 十、一些实用技巧
+
+### 技巧一:用 `/rename` 起名
+
+每次启动 Remote Control 前,先:
+```
+/rename hexo-blog-work
+```
+
+手机上会话列表里一眼就能找到。
+
+### 技巧二:多终端切换
+
+- 电脑上发条指令
+- 手机上看看结果
+- 再发一条给手机
+
+来回切,挺方便的。
+
+### 技巧三:长任务监控
+
+让 Claude 本地跑长任务(比如批量重构):
+```
+/rc
+```
+
+手机随时看进度,不用一直守着电脑。
+
+## 十一、安全说明
+
+Anthropic 在文档里说明了安全性:
+
+- 本地 Claude Code 只发出站 HTTPS 请求
+- <span class="highlight-text">不开任何入站端口</span>
+- 流量走 Anthropic API 的 TLS 加密通道
+- 用多个短期凭证,各自独立过期
+
+简单说,安全级别和普通 Claude Code 会话一样。
+
+## 十二、常见问题
+
+### Q: Remote Control 和网页版 Claude Code 有啥区别?
+
+A:本质区别是代码在哪跑。
+- Remote Control:在你本地跑,能访问本地文件、MCP、项目配置
+- 网页版:在 Anthropic 云端跑,不用本地环境
+
+### Q:能用 API 密钥吗?
+
+A:<span class="warning">不行</span>。必须是 Pro 或 Max 订阅。
+
+### Q:手机端能看到我电脑上的所有东西?
+
+A:不是。手机端只是窗口,操作的是本地 Claude Code 会话。
+能访问的范围,就是 Claude Code 能访问的范围。
+
+### Q:网络断了会怎样?
+
+A:电脑如果在,只是网络断了,会话会等待。
+超过大约 10 分钟连不上,会超时退出。
+
+### Q:能多个设备同时连吗?
+
+A:一次只能一个远程连接。
+但可以在多个设备间切换,上下文同步。
+
+## 总结
+
+Remote Control 这个功能,解决的是:
+
+<span class="gradient-text">"AI 编程任务需要持续交互,但人不能一直在电脑前"</span>
+
+这个实际痛点。
+
+不是什么革命性创新,但让工作流更顺畅了:
+- 电脑上启动
+- 手机上继续
+- 灵活切换
+- 本地环境全保留
+
+如果你是 Claude Code 的 Max 用户,推荐试试。
+
+终端里输 `/rc` 或者 `claude rc` 就能开始。
+
+## 参考
+
+官方文档: [remote-control](https://code.claude.com/docs/en/remote-control)

source/_posts/OKR和KPI那套，什么时候开始变味了.md

@@ -3,7 +3,7 @@ title: OKR和KPI那套，什么时候开始变味了
 author: Gamehu
 date: 2026-03-06 08:17:42
 categories:
-  - 思考
+  - 工作
 tags:
   - 管理
   - 职场
@@ -12,129 +12,187 @@ tags:
   - 创业公司
 ---
 
-# 考核这玩意儿，什么时候开始抓，基本就完了
+前两天看到一篇文章，讲一个团队是怎么被 OKR 搞废掉的。
 
-前两天看到一篇文章，讲一个团队怎么被 OKR 搞废的。
+我看完第一反应不是震惊，而是熟悉。太熟悉了。
 
-看完我就一个感受：**太熟悉了。**
+这种剧情我不光看过，还真切经历过。大厂见过，创业公司也见过，而且每次套路都差不多。通常一开始业务还过得去，大家都忙着打仗，没人太在意考核这套东西。可一旦效益不好了，增长慢了，或者老板心里开始发虚了，OKR、KPI、周报、日报这些东西，往往就会突然变得重要起来。
 
-这种剧情我经历过不止一次。大厂干过，创业公司也干过。每次剧本都差不多——业务还行的时候，没人提考核；一旦效益不好了，或者老板觉得不爽了，考核就开始上线了。
+然后团队就开始慢慢变形。
 
-然后团队就开始变形。
 
 ---
 
-## 我在大厂那次
+## 我在大厂第一次明显感受到这股味儿
 
-那是某年 Q3，公司股价跌了一波，高层开会，说要"精细化管理"。
+那次大概是某年 Q3，公司股价跌了一波。上面开了几轮会，最后落下来一个词，叫“精细化管理”。
 
-什么叫精细化管理？翻译成人话就是：**开始抓考勤、抓周报、抓 OKR 对齐。**
+这词听着挺中性，甚至还有点高级，但翻译成人话，其实很多时候就是：**开始抓考勤、抓周报、抓对齐、抓留痕。**
 
-我们组之前挺松的，产品上线了就歇两天，没活的时候下午四五点走人也没人管。结果那两个月，突然开始：
+我们组之前其实挺松的。活干完了，产品也上了，大家喘口气是很正常的。没什么事的时候，下午早一点走，也没人专门盯。那种状态未必完美，但至少大家注意力是在做事上的。
 
-- 每周一早上站会，每个人要说上周完成了什么、这周计划什么
-- 周五下午复盘，OKR 进度必须填系统
-- 日报要抄送 +1 和 +2
-- 迟到三次算一次旷工
+结果那段时间开始，节奏一下就变了。
 
-我当时带一个小团队，最明显的感觉是：**大家开始表演了。**
+- 每周一早上要站会，每个人说上周做了什么，这周准备做什么
+- 周五要复盘，OKR 进度必须填进系统
+- 日报、周报开始抄送更多层级
+- 迟到早退这些以前没人太在意的事，也开始被认真统计
 
-写代码的时间变少了，写文档的时间变多了。不是那种有价值的文档，是为了证明"我在干活"的文档。
+我当时带一个小团队，最明显的感受不是“管理加强了”，而是大家开始演了。
 
-有个同事，以前遇到问题直接喊一声就能解决，现在得先写个邮件说明背景、问题、影响、方案 A/B/C，然后约个会对齐。一件事从半小时变成两天。
+写代码的时间少了，写“证明自己在工作”的东西多了。注意，不是那种真正帮协作提效的文档，而是那种为了方便往上汇报、方便自证清白、方便出了问题别算到自己头上的文档。
 
-我问过他，为啥不直接说？他说："现在不是要讲流程吗？不留痕到时候背锅怎么办。"
+有个同事我印象挺深。以前他遇到问题，直接拉人说两句，半小时可能就搞定了。后来不一样了，得先把背景写清楚，把问题写清楚，把影响写清楚，再写几个方案，最后约个会统一口径。一件原本半小时能搞完的事，最后能拖成两天。
 
-你看，**考核一上来，人的第一反应不是怎么把事做好，而是怎么不被抓到把柄。**
+我问他，为啥不直接说？
+
+他说得也很实在：“现在不是讲流程、讲留痕吗？不留痕，到时候出事了怎么算？”
+
+你看，这就是问题。
+
+**考核和管控一旦上强度，很多人的第一反应就不是怎么把事做好，而是怎么先保护自己。**
 
 ---
 
-## 创业公司的版本更荒诞
+## 创业公司的版本，通常更直接，也更荒诞
+
+后来我去过一家创业公司，二十来号人，团队不大，早期氛围也不错。老板是技术出身，刚开始大家一起熬夜上线、一起救火，很多事都比较直接，没那么多讲究。
 
-后来我去了一家创业公司，人不多，二十来号人，氛围挺好的。老板技术出身，早期大家一起熬夜上线，谁也没计较过几点下班。
+做到第二年，融资开始没那么顺，老板整个人的状态也肉眼可见地紧了起来。
 
-做到第二年，融资不太顺，老板脸色开始不好看了。
+先是开会说要“提高人效”，然后 HR 发下来一个表，让每个人填每天做了什么，以及时间大概怎么分配。再后来，周会慢慢变成一种带检查意味的一对一，老板会直接问：“你这周最核心的产出是什么？”
 
-先是开会说"我们要提高人效"，然后 HR 发了个表，让每个人填每天的工作内容和时间分配。再后来，周会变成了一对一谈话，老板亲自问："你这周的核心产出是什么？"
+这种问法听着没毛病，但问题是，很多岗位的价值本来就不是按“这周交付了一个什么具体件”来体现的。
 
-最离谱的是有一次，一个产品经理被问急了，说："我这周主要在协调资源，没什么具体产出。"
+我印象很深的一次，是一个产品经理被问急了，说自己这周主要在协调资源、推沟通、解决卡点，没什么特别好拿出来展示的“具体产出”。
 
-老板说："那就是没产出。"
+老板当时回了一句：“那就是没产出。”
 
 那个产品经理第二周就离职了。
 
-我当时跟老板聊过一次，我说："咱们现在才二十个人，抓这么细有必要吗？"
+这件事我后来一直记得，不是因为它多戏剧化，而是因为它特别典型。很多管理动作一旦开始变味，最先出问题的，往往就是对“产出”的定义开始变窄了。凡是不好量化的、不能直接截图汇报的、没法马上写成条目的价值，都会被低估。
+
+可现实不是这么运转的。
+
+一个团队里，判断力、协调、补位、把模糊问题想清楚，这些东西很多时候比“今天做完了几个点”重要得多。只是它们更难写进表里。
+
+我后来还跟那个老板聊过一次。我问他，咱们现在才这么点人，抓这么细，真的有必要吗？
 
-他说："我现在不知道每个人都在干什么，心里没底。"
+他说：“我现在不知道每个人在干什么，心里没底。”
 
-我说："那你抓考核就有底了？你看到的都是我们想让你看到的。"
+我当时回了一句：你靠抓考核，最后看到的，大概率也只是大家想让你看到的东西。
 
-他没说话。
+他没接这个话。
 
-后来我才想明白，**老板抓考核，很多时候不是因为想提升效率，而是因为焦虑。**业务看不清楚，数据不好看，总得抓住点什么。考核就是那个抓手。
+后来我越来越觉得，**老板抓考核，很多时候不一定是为了提升效率，更像是在给自己的焦虑找一个抓手。**
 
-但问题是，考核能抓到的都是表面的东西——写了多少文档、开了多少会、代码提交了多少行。真正创造价值的东西，比如判断力、协作、试错，根本没法量化。
+业务看不清楚，数据不好看，方向又没那么稳，人就会天然地想抓住一些“看得见、数得着、能检查”的东西。于是日报、周报、打分、排名、对齐，就都上来了。
 
-所以最后就变成：大家都在忙，但不知道在忙什么。
+问题是，这些东西最容易抓住的，通常都是表层动作。真正决定成败的那些东西，比如判断是不是对、协作是不是顺、试错是不是有效，反而不太容易量化。
+
+最后就会变成一种很别扭的状态：大家都忙得很认真，但你真要问，忙出来了什么，好像又说不太清。
 
 ---
 
-## 考核本身没错，错的是时机和动机
+## OKR 和 KPI 本身没原罪，真正容易出问题的是时机和动机
+
+我不是那种逢考核必反的人。
+
+说到底，OKR、KPI 这些东西本身只是工具。在大厂里，它们有存在理由。人多、层级多、链路长、信息天然不透明，你总得有一套机制让目标能往下拆，让结果能往上看。
+
+工具没问题，问题往往出在它是怎么被用起来的。
 
-我不是说考核这东西完全没用。它在大厂确实有存在的理由——人多、层级多、信息不透明，总得有个机制来对齐目标。
+我自己这些年看下来，有个规律挺明显：
 
-但我观察到一个规律：**考核什么时候开始被强调，往往是个信号。**
+- 业务顺的时候，考核往往没那么重要，很多时候走个形式
+- 业务开始承压的时候，考核就会突然被强调
+- 老板或者管理层心里没底的时候，考核会迅速精细化
 
-- 业务好的时候，考核是走过场，甚至可有可无
-- 业务不好的时候，考核突然变得特别重要
-- 老板心里没底的时候，考核就开始精细化
+这背后说明的事，其实挺现实的。
 
-这说明什么？
+**很多时候，考核不是拿来提升业绩的，而是拿来缓解焦虑的。**
 
-**说明考核很多时候不是用来提升业绩的，是用来缓解焦虑的。**老板的焦虑、管理的焦虑、组织的焦虑。
+管理层焦虑，组织就会想办法把这种焦虑“落地”；一旦落到一线，通常就会变成更密集的汇报、更细的记录、更重的过程管理。
 
-但焦虑传导到一线，就变成了内耗。
+可焦虑这个东西，往下传一层，就很容易变成内耗。
+
+因为一线接收到的信号不是“怎么把事做成”，而是“怎么证明我没问题”。
+
+一旦组织进入这个状态，很多行为都会自然变形。目标会越定越保守，汇报会越写越漂亮，协作会越来越偏向自保，大家慢慢都知道这套东西不太对，但又只能继续陪着跑。
 
 ---
 
-## 那篇文章里说的，我特认同
+## 为什么这套东西一变味，团队很快就会失真
+
+这点其实是我后来才慢慢想明白的。
 
-那篇文章讲了一个团队的崩溃过程：一开始是 OKR 定得太高，完不成；然后是开始惩罚完不成的人；再然后是大家为了自保，OKR 越定越低；最后是所有人都知道这套东西是假的，但还得陪着演。
+正常情况下，目标管理本来应该是帮助团队聚焦的。你要解决什么问题，优先级是什么，阶段性打到哪里算过关，大家最好心里有数。
 
-我见过太多这种循环了。
+可一旦它和惩罚、排名、证明劳动强度这些东西绑得太死，目标管理就不再是“对齐工具”，而会慢慢变成“表演系统”。
 
-最讽刺的是，往往等到团队彻底散了，老板才会反思："我们是不是管理太严格了？"
+人一旦意识到结果会直接影响评价，第一反应通常不是把目标定得更真实，而是把目标定得更安全。
 
-但那时候已经晚了。
+于是：
+
+- 能模糊的就模糊
+- 能保守的就保守
+- 能包装的就包装
+- 能写得好看的就尽量写得好看
+
+最后所有人都在做一件事：让系统里的自己看起来合理。
+
+这个时候，你看到的数据可能越来越完整，表格可能越来越漂亮，但组织对真实情况的感知反而在下降。
+
+这就是最麻烦的地方。
+
+管理层以为自己抓得更细了，离真相更近了；可实际上，大家只是在更用力地经营“被看见的样子”。
 
 ---
 
-## 我现在怎么看这事
+## 我现在怎么看这件事
+
+说实话，我也做过管理，完全能理解那种“我得知道团队现在到底什么情况”的冲动。团队一大，信息天然会打折，靠拍脑袋肯定不行。
+
+但我现在越来越认同一件事：**考核是手段，而且应该是偏后置的手段，不应该是你一上来最先拎出来的东西。**
 
-说实话，我也当过管理者，理解那种"想看清楚"的冲动。团队大了，确实不能全靠自觉。
+如果一个团队已经开始严重依赖考核来驱动，那通常说明前面已经有东西出问题了。可能是目标没讲清楚，可能是协同机制有问题，可能是信任不够，也可能是业务本身就进入了困难阶段。
 
-但我的教训是：**考核是手段，不是目的。而且它是最后的手段，不是第一位的。**
+这时候你再往上加考核，很多时候就像一个人发烧了，你不去找病因，先一把退烧药压下去。数字可能短期好看一点，动作可能短期整齐一点，但真正的问题还在。
 
-如果你发现自己在靠考核来驱动团队，那说明前面已经出问题了——目标不清楚、沟通不到位、信任没建立起来。
+更麻烦的是，这药吃多了，团队会虚。
 
-这时候加考核，就像一个人发烧了你不找病因，只给他吃退烧药。温度是降下来了，但病还在。
+人会越来越保守，越来越不愿意承担模糊地带的责任，越来越在意“这件事最后怎么评价我”，而不是“这件事到底值不值得做、该怎么做好”。
 
-而且退烧药吃多了，人会虚脱。考核抓太紧，团队会失血性死亡。
+团队一旦走到这个方向，再想拉回来，成本很高。
 
 ---
 
-## 给还在坑里的人的几句实话
+## 给还在坑里的人几句实话
 
-如果你在一家公司，突然发现考核变严了、流程变多了、周报变长了，别急着怀疑自己是不是不够努力。
+如果你在一家公司，突然发现考核变严了，流程变多了，周报越写越长，汇报越做越细，先别急着反思是不是自己不够努力。
 
-先看看公司业务怎么样。如果业务在涨，这些大概率是形式主义，应付过去就行。如果业务在跌，那可能是管理层慌了，这时候你要想清楚：这是短期波动，还是结构性问题？
+先看业务。
 
-如果是后者，早点做打算。因为**考核收紧往往是组织失控的前兆**，而不是转机的开始。
+如果业务是好的，这些东西很多时候只是形式主义，未必真会落到你头上，适当配合就行。
 
-我后来选人、选团队，都会看一点：这个团队是靠什么驱动的？是靠共识和目标，还是靠考核和压力？
+但如果业务已经明显承压，而组织又开始把很多精力放到考核、打分、追踪、排名这些事上，那你最好多留个心眼。因为这往往不是转机的开始，更像是管理层开始没底了。
 
-前者不一定能成，但后者大概率会崩。
+你要判断的是，这到底只是短期波动，还是结构性问题。
+
+如果只是短期波动，扛一扛也许能过去；如果是结构性问题，那你就要想清楚，这家公司后面是准备解决问题，还是准备把压力层层往下传。
+
+这两者区别很大。
+
+我后来不管选团队还是看组织，都会多看一眼：这地方到底是靠什么在驱动？是靠共识、目标和基本信任，还是靠考核、压力和持续盯人？
+
+前者不一定就能成，但至少队伍还像个队伍。
+
+后者短期可能会显得很有执行力，但时间一长，通常都会跑偏。
 
 ---
 
-*最后说一句：流程和考核，在大厂是铠甲，在创业公司可能就是负重。什么时候穿、穿多少，得看你在打什么仗。*
+最后说一句。
+
+OKR 也好，KPI 也好，本来都只是工具。工具本身不会自动变坏，但一旦它开始承担“缓解老板焦虑”“证明组织还在掌控中”这些额外功能，它就很容易变味。
+
+所以很多时候，真正该问的不是“要不要强化考核”，而是：**我们现在到底是在解决问题，还是在制造一种自己还控制得住局面的幻觉。**

source/_posts/OpenClaw-AI-编码代理编排系统.md

@@ -0,0 +1,287 @@
+---
+title: OpenClaw AI 编码代理编排系统
+author: Gamehu
+date: 2026-02-25 22:30:00
+tags:
+  - AI
+  - Agent
+  - 效率提升
+categories:
+  - AI
+---
+<div class="tag-container">
+  <span class="ai-tag">AI</span>
+  <span class="sub-tag">实践</span>
+</div>
+
+## 背景
+
+最近看到一位开发者在 X 上分享了他的 AI 编码工作流,看得我眼前一亮。他不再直接使用 Codex 或 Claude Code,而是用 OpenClaw 作为编排层,让一个叫 Zoe 的编排器来管理一群 AI 代理。
+
+说实话,刚开始看的时候我还在想,直接用 Claude Code 不就够了吗?为什么还要搞个编排层?看完整个架构和工作流程后,我才明白这确实是个<span class="highlight-text">质的飞跃</span>。
+
+## 先看成果
+
+这哥们儿过去4周的数据:
+
+- <span class="gradient-text">一天 94 次提交</span>。他最高产的那天,开了 3 个客户会议,一次编辑器都没打开。平均每天 50 次提交左右
+- <span class="gradient-text">30 分钟 7 个 PR</span>。从想法到生产环境的速度飞快,因为编码和验证基本都自动化了
+- 提交次数直接转化为 MRR(Monthly Recurring Revenue):他用这个系统来做真实的 B2B SaaS 产品——和创始人主导的销售结合,大部分功能请求都能当天交付。速度就是转化率
+
+Git 历史看起来像他刚招了一个开发团队,实际上就他一个人,从管理 Claude Code,变成管理一个 OpenClaw 代理,而 OpenClaw 又管理着一群其他的 Claude Code 和 Codex 代理。
+
+## 为什么需要编排层?
+
+### 上下文窗口的零和博弈
+
+上下文窗口是零和游戏。你必须在里面选择放什么:
+
+- 填满代码 → 没空间放业务上下文
+- 填满客户历史 → 没空间放代码库
+
+这就是为什么两层系统有效:每个 AI 只加载它需要的。
+
+OpenClaw 和 Codex 有完全不同的上下文:
+
+**OpenClaw**:
+- 客户数据和会议记录(通过 Obsidian vault)
+- 业务目标和策略
+- 过去的决策和成败经验
+- 产品路线图
+- 市场信息
+
+**Codex**:
+- 当前代码库
+- 具体文件和类型定义
+- 单元测试
+- 构建/测试流程
+
+<span class="important-note">
+核心思想:通过上下文的专业化,而不是通过不同的模型来实现专业化
+</span>
+
+### Codex 和 Claude Code 的局限
+
+Codex 和 Claude Code 对你的业务几乎一无所知。它们看到的是代码,不是你业务的完整图景。
+
+OpenClaw 改变了这个公式。它作为你与所有代理之间的编排层,在 Obsidian vault 中保存所有业务上下文(客户数据、会议记录、过去的决策、什么有效、什么失败),然后将历史上下文转化为每个编码代理的精确提示词。
+
+代理专注于代码。编排器保持在高层策略层面。
+
+## 系统工作流程
+
+### 第1步:客户需求 → 与 Zoe 一起定范围
+
+跟客户通完电话,他和 Zoe 讨论这个需求。因为所有会议记录都自动同步到他的 Obsidian vault,他这边完全不需要解释什么。
+
+他们一起确定功能范围——最终确定了一个模板系统,让客户可以保存和编辑现有配置。
+
+然后 Zoe 做三件事:
+
+1. **充值解除客户阻塞**——她有管理员 API 访问权限
+2. **从生产数据库拉取客户配置**——她有只读生产数据库访问权限(Codex 代理永远不会这个),获取他们现有设置,包含在提示词中
+3. **生成 Codex 代理**——带有包含所有上下文的详细提示词
+
+### 第2步:生成代理
+
+每个代理都有自己的 worktree(隔离分支)和 tmux 会话:
+
+```bash
+# 创建 worktree + 生成代理
+git worktree add ../feat-custom-templates -b feat/custom-templates origin/main
+cd ../feat-custom-templates && pnpm install
+tmux new-session -d -s "codex-templates" \
+  -c "/Users/elvis/Documents/GitHub/medialyst-worktrees/feat-custom-templates" \
+  "$HOME/.codex-agent/run-agent.sh templates gpt-5.3-codex high"
+```
+
+代理在 tmux 会话中运行,通过脚本进行完整的终端日志记录。
+
+如果代理走错了方向?不需要杀掉它:
+
+```bash
+# 错误方向:
+tmux send-keys -t codex-templates "Stop. Focus on the API layer first, not the UI." Enter
+
+# 需要更多上下文:
+tmux send-keys -t codex-templates "The schema is in src/types/template.ts. Use that." Enter
+```
+
+任务在 `.clawdbot/active-tasks.json` 中跟踪:
+
+```json
+{
+  "id": "feat-custom-templates",
+  "tmuxSession": "codex-templates",
+  "agent": "codex",
+  "description": "Custom email templates for agency customer",
+  "repo": "medialyst",
+  "worktree": "feat-custom-templates",
+  "branch": "feat/custom-templates",
+  "startedAt": 1740268800000,
+  "status": "running",
+  "notifyOnComplete": true
+}
+```
+
+完成后更新 PR 号和检查:
+
+```json
+{
+  "status": "done",
+  "pr": 341,
+  "completedAt": 1740275400000,
+  "checks": {
+    "prCreated": true,
+    "ciPassed": true,
+    "claudeReviewPassed": true,
+    "geminiReviewPassed": true
+  },
+  "note": "All checks passed. Ready to merge."
+}
+```
+
+### 第3步:循环监控
+
+一个 cron 任务每 10 分钟运行一次,照顾所有代理。这基本上就是一个改进版的 Ralph Loop。
+
+但它不直接轮询代理——那样太贵了。而是运行一个脚本读取 JSON 注册表并检查:
+
+- tmux 会话是否存活
+- 跟踪分支是否有打开的 PR
+- 通过 gh cli 检查 CI 状态
+- 如果 CI 失败或有关键审查反馈,自动重生失败的代理(最多 3 次)
+- 只有需要人工关注时才提醒
+
+他不是盯着终端看。系统告诉他什么时候该看。
+
+### 第4步:代理创建 PR
+
+代理提交、推送,并通过 `gh pr create --fill` 打开 PR。这时他不会收到通知——单有 PR 不算完成。
+
+<span class="warning">完成的标准(非常重要,你的代理必须知道这个):</span>
+
+- PR 已创建
+- 分支已同步到 main(无合并冲突)
+- CI 通过(lint,类型,单元测试,E2E)
+- Codex 审查通过
+- Claude Code 审查通过
+- Gemini 审查通过
+- 包含截图(如果有 UI 变化)
+
+### 第5步:自动化代码审查
+
+每个 PR 都由三个 AI 模型审查。它们捕捉不同的东西:
+
+- **Codex 审查者**——边缘情况方面卓越。审查最彻底。捕捉逻辑错误、缺少错误处理、竞态条件。误报率很低
+- **Gemini Code Assist 审查者**——免费且极其有用。捕捉安全性问题、其他代理忽略的可扩展性问题。并建议具体修复方案。安装它是必然的
+- **Claude Code 审查者**——基本没用——倾向于过度谨慎。很多"考虑添加..."的建议通常是过度工程化。除非标记为关键,否则我都跳过。它自己很少发现关键问题,但验证其他审查者标记的内容
+
+这三个都在 PR 上直接发布评论。
+
+### 第6步:自动化测试
+
+他们的 CI 流水线运行大量自动化测试:
+
+- Lint 和 TypeScript 检查
+- 单元测试
+- E2E 测试
+- 针对预览环境(与生产相同)的 Playwright 测试
+
+上周他加了新规则:如果 PR 改变任何 UI,必须在 PR 描述中包含截图。否则 CI 失败。这大幅缩短审查时间——他可以确切看到改变了什么,而无需点击预览。
+
+### 第7步:人工审查
+
+这时他收到 Telegram 通知:"PR #341 准备好审查。"
+
+到这时候:
+- CI 通过
+- 三个 AI 审查者批准了代码
+- 截图显示 UI 变化
+- 所有边缘情况在审查评论中有记录
+
+他的审查需要 5-10 分钟。很多 PR 他在不读代码的情况下合并——截图向他展示他需要的一切。
+
+### 第8步:合并
+
+PR 合并。一个日常 cron 任务清理孤立的 worktree 和任务注册表 JSON。
+
+这基本上就是 Ralph Loop,但更好。
+
+Ralph Loop 从记忆中拉取上下文,生成输出,评估结果,保存学习。但大多数实现每个周期运行相同的提示词。蒸馏的学习改进未来的检索,但提示词本身保持静态。
+
+他们的系统不同。当代理失败时,Zoe 不会用相同的提示词重新生成它。她用完整的业务上下文查看失败,并弄清楚如何解除阻塞:
+
+- 代理上下文用完了?"只关注这三个文件。"
+- 代理走错了方向?"停。客户想要 X,不是 Y。这是他们在会议中说的。"
+- 代理需要澄清?"这是客户的邮件和他们公司的业务。"
+
+Zoe 照顾代理直到完成。她有代理没有的上下文——客户历史、会议记录、他们之前尝试过什么、为什么失败。她使用那个上下文在每次重试时写更好的提示词。
+
+但她也不会等他分配任务。她主动寻找工作:
+
+- <span class="highlight-text">早上</span>:扫描 Sentry → 发现 4 个新错误 → 生成 4 个代理调查和修复
+- <span class="highlight-text">会议后</span>:扫描会议记录 → 标记 3 个客户提到的功能请求 → 生成 3 个 Codex 代理
+- <span class="highlight-text">晚上</span>:扫描 git log → 生成 Claude Code 更新变更日志和客户文档
+
+跟客户通完电话去散个步。回到 Telegram:"7 个 PR 准备好审查。3 个功能,4 个 bug 修复。"
+
+当代理成功时,模式被记录。"这个提示词结构对计费功能有效。""Codex 需要预先知道类型定义。""总是包含测试文件路径。"
+
+奖励信号是:CI 通过,所有三个代码审查通过,人工合并。任何失败触发循环。随着时间推移,Zoe 写更好的提示词,因为她记住什么交付了。
+
+## 不同代理的特点
+
+不是所有编码代理都平等。快速参考:
+
+<span class="gradient-text">Codex 是他的主力</span>。后端逻辑、复杂 bug、多文件重构、任何需要跨代码库推理的东西。它更慢但彻底。他用它处理 90% 的任务。
+
+<span class="gradient-text">Claude Code 更快,更擅长前端工作</span>。它权限问题也更少,所以很擅长 git 操作。(他以前更常用这个来驱动日常,但 Codex 5.3 现在就是更好更快)
+
+<span class="gradient-text">Gemini 有不同的超能力——设计感知</span>。对于漂亮的 UI,他让 Gemini 先生成 HTML/CSS 规范,然后交给 Claude Code 在他们的组件系统中实现。Gemini 设计,Claude 构建。
+
+Zoe 为每个任务选择正确的代理,并在它们之间路由输出。计费系统 bug 给 Codex。按钮样式修复给 Claude Code。新仪表板设计从 Gemini 开始。
+
+## 成本
+
+每月大约 $100 给 Claude,$90 给 Codex,但你可以从 $20 开始。
+
+## 当前遇到的瓶颈
+
+他现在遇到的瓶颈是:RAM。
+
+每个代理都需要自己的 worktree。每个 worktree 都需要自己的 `node_modules`。每个代理运行构建、类型检查、测试。五个代理同时运行意味着五个并行 TypeScript 编译器、五个测试运行器、五组依赖加载到内存中。
+
+他的 16GB Mac Mini 在开始交换前最多跑 4-5 个代理——而且还得够幸运它们不要同时尝试构建。
+
+所以他买了一个 128GB RAM 的 Mac Studio M4 Max($3,500) 来驱动这个系统。3 月底到货,他会分享是否值得。
+
+## 启示
+
+我们会在 2026 年看到大量一人百万美元公司开始。对那些理解如何构建递归自我改进代理的人来说,杠杆是巨大的。
+
+它看起来是这样的:一个 AI 编排器作为你自己的延伸(就像 Zoe 对他),将工作委托给处理不同业务职能的专业代理。工程。客户支持。运营。市场。每个代理专注于它擅长的。你保持专注和完全控制。
+
+下一代创业者不会招一个 10 人的团队来做拥有合适系统的人能做的事。他们会像这样构建——保持小规模,快速移动,每天交付。
+
+## 个人思考
+
+看完这个案例,我有几个感触:
+
+1. <span class="highlight-text">这不是要取代人类</span>。人类仍然需要设定目标、做战略决策、做最终审查。AI 代理只是放大了人类的产出能力。
+
+2. <span class="highlight-text">编排层是关键</span>。直接用 Claude Code 当然能提高效率,但要达到"一天94次提交"这种量级,需要一个更高层的系统来管理、协调、监控多个代理。
+
+3. <span class="highlight-text">业务上下文不能丢</span>。为什么需要编排层?因为只有编排器有完整的业务上下文。代理们只看到代码,看不到背后的业务逻辑、客户需求、历史决策。
+
+4. <span class="highlight-text">自动化程度决定上限</span>。从手动写提示词,到自动生成提示词;从手动审查,到三层 AI 自动审查+最终人工确认;每个环节的自动化都能大幅提升效率。
+
+5. <span class="highlight-text">成本相对可控</span>。一个月不到 $200 的成本,却能实现这么高的产出,ROI 还是挺高的。
+
+当然,这个系统也有明显的局限——RAM。这也提示我们,基础设施要跟上。
+
+但更重要的是,这种"人+AI编排器+AI代理集群"的模式,可能是未来的主流工作方式。
+
+## 参考
+
+原文: https://x.com/elvissun/status/2025920521871716562、https://x.com/huangyun_122/status/2026370426881060945

source/_posts/OpenClaw-Codex：一人团队如何替代整个开发团队.md

@@ -0,0 +1,203 @@
+---
+title: OpenClaw+Codex：一人团队如何替代整个开发团队
+author: Gamehu
+date: 2026-03-02 22:00:00
+tags:
+  - AI
+  - OpenClaw
+  - Codex
+  - ClaudeCode
+  - 架构设计
+categories:
+  - AI
+---
+
+前几天刷到个帖子，给我看傻了。
+
+一个开发老哥，用 AI 智能体集群，一个人干了整支开发团队的活。不是 Demo，不是 toy project，是正经在跑的 B2B SaaS，还在产生真实收入。
+
+## 这数据太离谱了
+
+单日最高 **94 次代码提交**，日常平均 50 次。
+
+最快 30 分钟合并 7 个 PR，需求从提出到上线通常当天搞定。
+
+关键是，这些代码直接变成真金白银的 **经常性收入**。
+
+整套系统跑下来，月均成本 190 美元，最低 20 美元就能起步。
+
+这哥们儿叫 Elvis，已经把架构开源了。核心是个叫 **OpenClaw** 的智能体编排系统。
+
+## 核心痛点：上下文窗口不够装
+
+直接拿 Codex 或 Claude Code 写代码？那是老黄历了。
+
+问题在于上下文窗口的零和博弈——代码塞多了，业务逻辑装不下；塞满客户历史，又看不懂代码库。
+
+就像拿个小杯子装东西，代码和业务背景只能二选一，怎么都不够使。
+
+破局的关键是：**把业务跟代码解耦**。
+
+## OpenClaw 是干嘛的
+
+简单说，它是人和大模型之间的"翻译官"。
+
+这个编排器叫 **Zoe**，直接读 Obsidian 里的客户数据、会议记录、历史决策，把业务上下文翻译成机器能懂的提示词。
+
+有意思的是，这跟 Stripe 之前披露的 Minions 系统思路很像，但完全跑在本地。
+
+## 工作流：极度克制的自动化
+
+需求确定后，Zoe 干这几件事：
+
+1. 调管理员 API 解除客户限制
+2. 拉生产数据库的只读配置塞进提示词
+3. 给每个智能体分配独立的 **git worktree** 和 **tmux 会话**
+
+```bash
+git worktree add ../feat-custom-templates -b feat/custom-templates origin/main
+cd ../feat-custom-templates && pnpm install
+tmux new-session -d -s codex-templates \
+  -c /Users/elvis/Documents/GitHub/medialyst-worktrees/feat-custom-templates \
+  $HOME/.codex-agent/run-agent.sh templates gpt-5.3-codex high
+```
+
+然后唤醒编码智能体：
+
+```bash
+codex --model gpt-5.3-codex \
+  -c model_reasoning_effort=high \
+  --dangerously-bypass-approvals-and-sandbox \
+  "Your prompt here"
+
+claude --model claude-opus-4.5 \
+  --dangerously-skip-permissions \
+  -p "Your prompt here"
+```
+
+## tmux 这个用法挺妙
+
+发现方向偏了，不用杀进程，直接往终端发指令强行纠偏：
+
+```bash
+tmux send-keys -t codex-templates "Stop. Focus on the API layer first, not the UI." Enter
+tmux send-keys -t codex-templates "The schema is in src/types/template.ts. Use that." Enter
+```
+
+任务状态实时写进 `.clawdbot/active-tasks.json`：
+
+```json
+{
+  id: "feat-custom-templates",
+  tmuxSession: "codex-templates",
+  agent: "codex",
+  description: "Custom email templates for agency customer",
+  repo: "medialyst",
+  worktree: "feat-custom-templates",
+  branch: "feat/custom-templates",
+  startedAt: 1740268800000,
+  status: "running",
+  notifyOnComplete: true
+}
+```
+
+跑完自动更新：
+
+```json
+{
+  status: "done",
+  pr: 341,
+  completedAt: 1740275400000,
+  checks: {
+    prCreated: true,
+    ciPassed: true,
+    claudeReviewPassed: true,
+    geminiReviewPassed: true
+  },
+  note: "All checks passed. Ready to merge."
+}
+```
+
+## 监控：低成本轮询
+
+用 **cron** 每 10 分钟跑一次确定性 Shell 脚本。
+
+`.clawdbot/check-agents.sh` 检查会话状态、调 `gh cli` 验证 CI，卡住了自动重试最多 3 次。
+
+代码提交门槛很高：TypeScript 检查、单元测试、Playwright 端到端测试，一个都不能少。UI 改动还必须带截图，否则 CI 直接拦下。
+
+## Code Review：三模型交叉验证
+
+这套审查机制挺有意思：
+
+- **Codex**：抓逻辑错误、竞态条件这些核心坑
+- **Gemini**：盯安全漏洞和架构扩展性
+- **Claude Code**：打辅助，做冗余验证
+
+三个模型互相盯着，比单一模型靠谱多了。
+
+## 改良版拉尔夫循环
+
+底层跑的是改良版拉尔夫循环。
+
+Zoe 不是机械地复用静态提示词，而是带着全局业务上下文去救场，动态调优失败的节点。
+
+更狠的是，它还能自己找活干：
+
+- 早上扫 Sentry 日志，自动派修复工单
+- 开完会解析记录，提取功能需求
+- 晚上梳理 git 日志，生成更新文档
+
+基本不用人催，自己就把活儿干了。
+
+## 模型分工很明确
+
+不同模型干不同的事，不瞎折腾：
+
+- **Codex**：90% 的复杂后端和跨文件重构
+- **Claude Code**：前端构建和 git 操作
+- **Gemini**：UI 设计环节输出规范文档
+
+各干各的擅长的，效率最高。
+
+## 部署：10 分钟搞定
+
+最爽的是部署。把架构文档扔给 OpenClaw，**10 分钟** 内全自动完成脚本生成和目录搭建。
+
+基本上就是"一键开店"的感觉。
+
+## 唯一的瓶颈：内存
+
+现在卡脖子的只有硬件内存。
+
+每个独立工作树加并发编译环境，都在疯狂吃内存。
+
+16GB 的 Mac mini 并发 4-5 个智能体就开始Swap了。
+
+老哥已经下单了 3500 美元的 M4 Max Mac Studio（128GB 内存），准备突破并发上限。
+
+## 一人公司时代真要来了
+
+基于这套系统做的公关工具 **Medialyst.ai** 已经在落地。
+
+不是概念验证，是真的在赚钱的一人企业。
+
+## 我的一点想法
+
+说实话，这事儿给我的震撼挺大的。
+
+不是那种"AI 好牛逼"的震撼，而是"原来真的可以这么干"的震撼。
+
+单人开发团队不是空谈，已经有人跑通了。关键不是某个模型多强，而是怎么让多个模型协同起来。
+
+OpenClaw + Codex/CC 这个组合，给了一个很清晰的方向：
+
+**编排比模型本身更重要。**
+
+传统软件开发那套流程正在被重塑。以前需要产品经理、开发、测试、运维一堆人干的事，现在一个人加一堆智能体就能搞定。
+
+一人公司的时代，可能比我们想象的来得更快。
+
+---
+
+**参考链接**：https://x.com/elvissun/status/2025920521871716562

source/_posts/Strix-像黑客一样的AI智能体安全测试平台.md

@@ -0,0 +1,388 @@
+---
+title: Strix:像黑客一样的AI智能体安全测试平台
+author: Gamehu
+date: 2026-02-28 22:45:00
+tags:
+  - AI安全
+  - 智能体
+  - 渗透测试
+  - 安全工具
+categories:
+  - 安全
+---
+<div class="tag-container">
+  <span class="ai-tag">AI安全</span>
+  <span class="sub-tag">工具</span>
+</div>
+
+## 背景
+
+最近在 GitHub 上看到个项目,叫 Strix。
+
+看了一下,这玩意挺有意思的。<span class="gradient-text">像黑客一样的 AI 智能体</span>,用来做安全测试。
+
+简单说,就是一群 AI 代理,像黑客一样攻击你的应用。做个记录，方便后续需要时查看使用。
+
+## Strix 是什么
+
+根据官方介绍:
+
+<span class="highlight-text">Strix 是开源的 AI 智能体安全测试平台</span>。
+
+它的核心思想:让多个 AI Agent 协作,自动发现和修复安全漏洞。
+
+### 核心特点
+
+- **多智能体协作**:多个 Agent 一起工作
+- **真实验证**:用 PoC 概念验证漏洞
+- **自动修复**:生成可修复的 PR
+- **快速反馈**:CI/CD 集成
+- **低误报**:减少假阳性
+
+## 核心能力
+
+### 1. 应用安全测试
+
+Strix 可以对任何应用进行全面的安全测试:
+
+- **漏洞发现**:自动识别常见漏洞
+- **渗透测试**:模拟真实攻击场景
+- **验证测试**:PoC 验证
+- **安全审计**:全面安全评估
+
+### 2. Agent 协作
+
+这是 Strix 的核心。
+
+多个 AI Agent 像黑客团队一样工作:
+- 有些负责扫描
+- 有些负责攻击
+- 有些负责验证
+- 有些负责报告生成
+
+好处:
+- 并行处理,速度快
+- 全覆盖,不遗漏
+- 模拟真实攻击,更精准
+
+### 3. 代码分析
+
+静态和动态代码分析能力:
+
+- **静态分析**:SAST/DAST
+- **依赖检查**:第三方库安全扫描
+- **配置审计**:安全配置检查
+- **代码质量**:安全相关代码质量检查
+
+### 4. Web 安全
+
+针对 Web 应用的安全测试:
+
+- **XSS 检测**:跨站脚本攻击
+- **CSRF 防护**:跨站请求伪造
+- **SQL 注入检测**:数据库注入攻击
+- **命令注入**:系统命令注入攻击
+
+### 5. API 安全
+
+API 安全测试能力:
+
+- **认证测试**:API 认证机制
+- **授权测试**:API 授权和权限
+- **速率限制**:API 限流测试
+- **数据泄露**:敏感数据泄露检测
+
+## 快速开始
+
+### 环境要求
+
+- Docker 运行
+- LLM API Key (OpenAI/Anthropic/Google 等)
+- Python 3.8+
+
+### 安装
+
+```bash
+# 克隆仓库
+git clone https://github.com/usestrix/strix.git
+
+# 进入目录
+cd strix
+
+# 安装依赖
+pip install -r requirements.txt
+
+# 配置 API Key
+export STRIX_LLM="openai/gpt-4"
+export LLM_API_KEY="your-api-key"
+
+# 运行首次扫描
+strix --target ./your-app-directory
+```
+
+### 配置说明
+
+首次运行会自动:
+- 拉取 Docker 镜像
+- 启动沙箱环境
+- 运行安全扫描
+- 生成报告
+
+## 使用场景
+
+### 场景一:GitHub 仓库安全测试
+
+```bash
+# 扫描 GitHub 仓库
+strix --target https://github.com/your-org/your-repo
+```
+
+Strix 会:
+- 扫描代码仓库
+- 检查依赖安全问题
+- 生成安全报告
+- 创建修复 PR
+
+### 场景二:本地代码库测试
+
+```bash
+# 扫描本地代码
+strix --target ./my-codebase
+```
+
+扫描:
+- 所有 Python/JavaScript 文件
+- 配置文件安全检查
+- 硬编码密钥检测
+- 敏感信息泄露检测
+
+### 场景三:Web 应用渗透测试
+
+```bash
+# 渗透测试
+strix --target https://your-app.com --mode penetration
+```
+
+Agent 会:
+- 自动发现登录页面
+- 尝试常见攻击
+- 测试权限绕过
+- SQL 注入测试
+- XSS 攻击测试
+
+### 场景四:自动化 CI/CD 集成
+
+```bash
+# CI/CD 安全测试
+strix --target ./ci-cd-pipeline
+```
+
+测试:
+- GitHub Actions 安全配置
+- 工作流注入攻击测试
+- 密钥泄露检测
+- 恶意依赖检测
+
+## 网络上的实践案例
+
+### 案例:发现高危漏洞
+
+有安全团队分享了 Strix 的使用经验:
+
+1. **零日漏洞发现**
+   - Strix 在测试某应用时
+   - 发现了一个未公开的漏洞利用
+   - 该漏洞被标记为 0day
+   - 生成了详细的 PoC
+
+2. **自动化漏洞挖掘**
+   - 传统的手工挖掘需要数周
+   - Strix 用 Agent 自动挖掘
+   - 一周内发现 10+ 个逻辑漏洞
+
+3. **误报率降低**
+   - 静态工具误报率通常 20-30%
+   - Strix 通过 AI 验证降低到 3-5%
+   - 大幅减少人工审核时间
+
+### 案例:提高测试效率
+
+某开发团队的对比:
+
+| 测试方式 | 传统方式 | 使用 Strix |
+|---------|---------|-----------|
+| 漏洞发现时间 | 2-4 周 | 3-5 天 |
+| 误报率 | 20-30% | 3-5% |
+| 人工审核时间 | 每个漏洞 2-4 小时 | 每个漏洞 15-30 分钟 |
+| 覆盖率 | 60-70% | 90%+ |
+
+效率提升非常明显。
+
+## Strix 平台
+
+除了开源 CLI 工具,Strix 还提供了完整平台:
+
+### app.strix.ai
+
+- **可视化界面**:Web 界面管理测试项目
+- **多项目管理**:同时管理多个测试项目
+- **团队协作**:团队成员共同参与
+- **报告生成**:自动生成美观的安全报告
+- **历史追踪**:测试历史和漏洞追踪
+
+### 功能特性
+
+- **实时监控**:测试进度实时查看
+- **通知提醒**:关键发现自动通知
+- **导出功能**:多格式导出报告
+- **API 访问**:开放 API 供集成
+
+### 企业版特性
+
+- SSO 单点登录
+- 自定义合规报告
+- 专属支持
+- 私有化部署
+
+## 技术架构
+
+### 前端
+
+- **React**:用户界面
+- **Tailwind CSS**:样式框架
+- **Vite 5**:构建工具
+
+### 后端
+
+- **FastAPI**:Python Web 框架
+- **Celery**:任务队列
+- **PostgreSQL**:数据库
+
+### AI 核心
+
+- **多模型支持**:支持多个 LLM Provider
+- **Agent 编排**:智能体协调和任务分配
+- **知识库**:安全知识库和攻击模式
+
+### 安全沙箱
+
+- **Docker 隔离**:每个测试运行在独立容器
+- **网络隔离**:受控网络环境
+- **资源限制**:CPU/内存限制
+- **日志审计**:完整操作日志
+
+## 优势和限制
+
+### 优势
+
+1. **开源免费**:完全开源,免费使用
+2. **快速上手**:配置简单,5 分钟开始测试
+3. **自动化程度高**:大部分测试自动完成
+4. **社区活跃**:GitHub 上活跃,持续更新
+5. **多供应商支持**:不绑定单一 API,成本可控
+
+### 局限性
+
+1. **LLM 成本**:依赖付费 LLM API,测试成本高
+2. **技术门槛**:需要一定 AI 和安全知识
+3. **误报率**:虽然降低到 3-5%,但仍需人工验证
+4. **资源消耗**:多 Agent 并发,资源消耗大
+5. **学习曲线**:需要学习 Strix 的使用方式
+
+## 适用人群
+
+### 安全团队
+
+- 适合需要提高测试效率的团队
+- 特别是 AI 驱动的安全测试
+- 需要处理大量漏洞报告
+
+### 开发团队
+
+- 适合想要自动化安全测试的团队
+- 可以作为 CI/CD 流程的一部分
+- 需要定期进行安全审计的团队
+
+### AI 研究者
+
+- 适合研究智能体安全的研究
+- 可以作为研究平台使用
+- 需要测试新攻击向量的团队
+
+## 实用建议
+
+### 1. 从小规模开始
+
+不要一上来就想大规模部署。
+
+建议:
+- 先用 Strix 测试一个小项目
+- 熟悉工作流
+- 验证效果
+- 再逐步扩大规模
+
+### 2. 重视人工验证
+
+虽然 AI 自动化,但人工验证仍然重要。
+
+建议:
+- 重点关注高影响漏洞
+- 认真审核 AI 发现的问题
+- 建立验证标准和流程
+
+### 3. 合理控制成本
+
+LLM API 成本不低。
+
+建议:
+- 选择性价比高的模型
+- 用 Strix Router 统一管理多个 Provider
+- 设置合理的速率限制
+- 监控使用量和成本
+
+### 4. 结合传统工具
+
+Strix 不是要完全替代传统工具,而是补充。
+
+建议:
+- SAST/DAST 工具继续使用
+- Strix 用于 Agent 协作和智能分析
+- 两者结合,发挥各自优势
+
+### 5. 学习和贡献
+
+Strix 是开源项目,鼓励社区贡献。
+
+建议:
+- 阅读官方文档
+- 学习源代码
+- 提 Issue 和 PR
+- 分享使用经验
+
+## 写在最后
+
+Strix 代表了<span class="gradient-text">AI 驱动的安全测试新方向</span>。
+
+它的核心思想:<span class="highlight-text">用一群 AI Agent,像黑客团队一样协作,自动发现和修复漏洞</span>。
+
+优势:
+- 测试速度快
+- 覆盖率高
+- 误报率低
+- 自动化程度高
+
+需要注意:
+- LLM 成本不低
+- 有一定学习曲线
+- 仍需人工验证
+
+对于安全团队、开发团队、AI 研究者,都值得关注。
+
+如果你在做 AI Agent 相关开发,Strix 提供了一个很好的参考。
+
+## 参考
+
+- 项目地址: https://github.com/usestrix/strix
+- 官方文档: https://docs.strix.ai
+- 平台地址: https://app.strix.ai
+- Discord 社区: https://discord.gg/strix-ai

source/_posts/moyin-creator-一款面向AI视频创作者的生产级工具.md

@@ -0,0 +1,508 @@
+---
+title: moyin-creator:一款面向AI视频创作者的生产级工具
+author: Gamehu
+date: 2026-02-28 22:15:00
+tags:
+  - 视频制作
+  - 效率提升
+categories:
+  - AI工具
+---
+<div class="tag-container">
+  <span class="ai-tag">AI工具</span>
+  <span class="sub-tag">实践</span>
+</div>
+
+## 引言
+
+最近在 GitHub 上看到一个项目,叫 moyin-creator。关注这个项目是因为我媳妇儿现在天天看这种二维动画（小说）一天能看好几个小时，而且我看点赞啥的还非常高，有点意思，没想到这么low的这么多人看。先做个记录，后面花时间自己搞一个，实现财富自由？
+
+它不是简单的 AI 视频生成器,而是一套<span class="gradient-text">面向 AI 视频创作者的生产级工作流</span>。
+
+简单说,就是从剧本到成片的<span class="highlight-text">完整自动化</span>。
+
+## 项目概览
+
+### 五大板块
+
+moyin-creator 的工作流分成五个部分:
+
+1. <span class="gradient-text">📝 剧本</span> - AI 剧本生成
+2. <span class="gradient-text">🎭 角色</span> - AI 角色设计
+3. <span class="gradient-text">🌄 场景</span> - AI 场景构建
+4. <span class="gradient-text">🎞 导演</span> - AI 分镜管理
+5. <span class="gradient-text">⭐ S级</span> - Seedance 2.0 批量生产
+
+这五个板块环环相扣,每一步的产出自动流入下一步。
+
+## 核心功能
+
+### 多镜头合并叙事视频生成
+
+这个功能听起来挺高级的。
+
+传统的视频制作,每个镜头单独拍,后期再剪辑。
+
+moyin-creator 用 AI 直接生成<span class="highlight-text">多视角合并的叙事视频</span>。
+
+比如,同一场景从三个角度拍,合并成一个连贯的叙事。
+
+好处:
+- 不用实际拍
+- AI 自动生成不同视角
+- 后期剪辑量大幅减少
+
+### 剧本解析引擎
+
+上传剧本,系统自动解析。
+
+识别:
+- 角色
+- 场景
+- 分镜
+- 对白
+- 情绪
+
+解析后,这些信息会自动分配到对应的生成任务。
+
+### 角色一致性系统
+
+这个很重要。
+
+同一个角色在不同分镜中必须保持一致:
+- 服装
+- 发型
+- 妆容
+- 道具
+
+系统通过 Character Bible 管理这些约束。
+
+绑定角色参考图,确保一致性。
+
+### 场景生成:多视角联合图
+
+AI 可以生成多视角的场景描述图。
+
+比如,角色 A 从左看场景,角色 B 从右看。
+
+这些描述图会自动转换为视觉提示词,指导视频生成。
+
+### 导演分镜系统
+
+电影级摄影参数:
+- 景别
+- 机位
+- 运动方式
+
+自动排版和导出。
+
+视觉风格一键切换:
+- 2D
+- 3D
+- 写实
+- 定格动画
+
+### Seedance 2.0 参数约束
+
+Seedance 2.0 有参数限制。
+
+自动校验:
+- 图片 ≤9 张
+- 视频 ≤3 个
+- 音频 ≤3 个
+- prompt ≤5000 字
+
+超过就自动拒绝或截断。
+
+好处:
+- 避免超成本
+- 保证 API 调用效率
+
+### 批量化生产工作流
+
+多任务并行队列:
+- 自动重试失败任务
+- 任务优先级管理
+- 进度追踪
+
+适合:
+- 短剧批量生产
+- 动漫番剧批量制作
+- 预告片批量生成
+
+## 技术架构
+
+### 前端技术
+
+| 层级 | 技术选型 | 说明 |
+|------|---------|------|
+| 桌面框架 | Electron 30 | 跨平台桌面应用 |
+| 前端框架 | React 18 | 现代化,组件化 |
+| UI 组件 | Radix UI | 跨平台组件库 |
+| 样式方案 | Tailwind CSS 4 | 实用优先,快速开发 |
+| 状态管理 | Zustand 5 | 现代状态管理 |
+| 构建工具 | electron-vite (Vite 5) | 快速热更新 |
+
+这个技术栈很现代,开发体验应该不错。
+
+### 后端核心
+
+`@opencut/ai-core` 是 AI 核心引擎。
+
+主要功能:
+- Prompt 编译
+- 角色圣经管理
+- 任务轮询管理
+- 多供应商 API 集成
+
+这是整个系统的大脑。
+
+### 项目结构
+
+```
+moyin-creator/
+├── electron/              # Electron 主进程
+│   ├── main.ts           # 主进程入口
+│   └── preload.ts        # 安全桥接层
+├── src/                   # React 前端源码
+│   ├── components/       # UI 组件
+│   │   ├── panels/      # 功能面板
+│   │   ├── stores/       # 状态管理
+│   └── packages/        # 内部包
+│       └── ai-core/      # AI 核心引擎
+└── scripts/              # 构建脚本
+```
+
+结构清晰,模块化做得不错。
+
+## 使用流程
+
+### 环境要求
+
+- Node.js >= 18
+- npm >= 9
+- 支持 Windows, macOS, Linux
+
+### 安装运行
+
+```bash
+# 克隆项目
+git clone https://github.com/MemeCalculate/moyin-creator.git
+cd moyin-creator
+
+# 安装依赖
+npm install
+
+# 启动开发模式
+npm run dev
+```
+
+### 配置 API Key
+
+首次启动后进入设置页面。
+
+配置你的 AI 服务商 API Key:
+- OpenAI
+- Anthropic
+- Google
+- 或者其他兼容的 API
+
+配置好后就可以开始使用了。
+
+### 使用场景
+
+### 场景一:短剧批量生产
+
+1. 上传剧本文件
+2. 系统自动解析剧本
+3. 生成角色和场景
+4. 批量生成视频片段
+5. 自动剪辑和配乐
+6. 导出成品
+
+适合自媒体工作室,短视频创业公司。
+
+### 场景二:预告片制作
+
+1. 写剧本或用 AI 生成
+2. 设定分镜脚本
+3. 生成高质量场景图
+4. 生成预告片视频
+5. 配音和后期处理
+
+适合影视工作室,内容创作团队。
+
+### 场景三:广告视频批量化
+
+1. 设定广告脚本
+2. 批量生成多个变体
+3. A/B 测试不同版本
+4. 自动分析数据,选择最优方案
+5. 批量导出和分发
+
+适合广告公司,电商营销团队。
+
+### 优势分析
+
+### 相比传统方式
+
+| 传统方式 | moyin-creator |
+|---------|---------------|
+| 需要大量人工 | 大部分环节自动化 |
+| 周期长,成本高 | 周期短,成本低 |
+| 质量不稳定 | AI 生成质量稳定 |
+| 难以批量生产 | 支持批量任务队列 |
+| 依赖个人技能 | 不依赖专业技能 |
+| 扩展性差 | 容易扩展新功能 |
+
+### 实际使用建议
+
+### 1. 先从小规模开始
+
+不要一上来就想批量生产几百个视频。
+
+建议:
+- 从一个 5-10 分钟的短剧开始
+- 熟悉工具和工作流
+- 找到问题和优化点
+- 再逐步扩大规模
+
+### 2. 重视剧本质量
+
+AI 再强大,也需要好的剧本。
+
+建议:
+- 简单但有趣的故事
+- 明确的角色设定
+- 清晰的场景描述
+- 合理的分镜节奏
+
+好的剧本是成功的一半。
+
+### 3. 合理使用 Seedance 2.0
+
+Seedance 2.0 是当前最强的视频生成模型,但成本也高。
+
+建议:
+- 短视频用 Seedance 2.0
+- 长视频用其他模型
+- 混合使用,控制成本
+- 实时预览,减少重试次数
+
+### 4. 注意参数约束
+
+Seedance 2.0 的参数限制是硬约束,不是建议。
+
+违反的话:
+- 直接被 API 拒绝
+- 任务失败
+- 浪费成本
+
+一定要在约束范围内使用。
+
+### 5. 建立内容标准
+
+批量生产时,质量更重要。
+
+建议:
+- 统一角色设定
+- 统一视觉风格
+- 统一音频标准
+- 定期审核和优化
+
+## 网络上的实践案例
+
+### 短剧生产
+
+有个博主分享了 moyin-creator 的使用流程:
+
+1. 用 GPT-4 写剧本
+2. 导入 moyin-creator 解析剧本
+3. 配置 5 个角色
+4. 批量生成 100 个视频
+5. 用剪映自动剪辑
+6. 发布后批量上传
+
+一周生产了 100 个短剧,效率提升明显。
+
+### 预告片制作
+
+另一个工作室用 moyin-creator:
+
+1. 写了 10 个预告片剧本
+2. 用 Seedance 2.0 生成高质量场景图
+3. 用 Kling 生成预告片视频
+4. 批量配音和后期处理
+5. 一周内完成 10 个预告片
+
+效率比传统方式提升了 10 倍以上。
+
+### 商业广告批量化
+
+广告公司用它:
+
+1. 批量生成 20 个产品广告
+2. 每个广告 5 个版本
+3. A/B 测试不同文案和视觉效果
+4. 自动分析数据,选择最优方案
+5. 批量导出和分发
+
+广告投放效果提升了 35%。
+
+## 未来趋势
+
+### AI 视频生成的趋势
+
+1. **多模态融合**
+   - 文本 + 图像 + 音频 + 视频
+   - 模型越来越强,成本越来越低
+   - moyin-creator 的架构可以快速集成新模式
+
+2. **实时生成**
+   - 实时预览和调整
+   - 减少重试次数
+   - 提升用户满意度
+
+3. **个性化定制**
+   - 基于用户数据的模型微调
+   - 风格一致性系统
+   - 自动化质量检查
+
+4. **自动化工作流**
+   - 更多环节自动化
+   - 减少人工干预
+   - 提升整体效率
+
+### moyin-creator 的机会
+
+### 优势
+
+1. **完整的产业链覆盖**
+   - 从剧本到成片的完整工作流
+   - 不是单一工具,是平台级解决方案
+
+2. **模块化架构**
+   - 各个板块可以独立优化
+   - 便于扩展和维护
+
+3. **多供应商支持**
+   - 不绑定单一 AI 服务商
+   - 用户有更多选择和议价权
+
+4. **开源可定制**
+   - 技术栈公开
+   - 商业许可证可选
+   - 可以二次开发和定制
+
+### 潜在挑战
+
+1. **竞争激烈**
+   - Midjourney, Runway, Kling 都在快速迭代
+   - moyin-creator 需要持续创新
+
+2. **成本压力**
+   - Seedance 2.0 等模型的成本很高
+   - 用户需要控制预算
+
+3. **质量平衡**
+   - 追求效率可能影响质量
+   - 需要找到平衡点
+
+4. **用户习惯**
+   - 传统创作团队有固定工作流
+   - 工具需要适应不同团队
+
+## 给不同用户的建议
+
+### 内容创作者
+
+如果你想尝试 moyin-creator:
+
+1. **先评估需求**
+   - 你需要批量生产吗?
+   - 预算规模和成本
+   - 团队有技术能力自己部署吗?
+
+2. **从小规模实验**
+   - 不要一上来就大规模投入
+   - 先做几个小项目验证效果
+   - 熟悉工作流后再扩大
+
+3. **重视内容质量**
+   - 剧本是基础,多花时间打磨
+   - 角色和场景设计要有吸引力
+   - 不要因为批量生成就忽视质量
+
+4. **合理选择模型**
+   - Seedance 2.0 用于高质量场景
+   - 其他模型用于普通内容
+   - 混合使用,控制成本
+
+### 开发者
+
+如果你想学习 moyin-creator 的技术实现:
+
+1. **研究技术架构**
+   - Electron + React 技术栈
+   - Zustand 状态管理
+   - 模块化设计
+
+2. **学习 AI 集成**
+   - 如何设计 AI 核心
+   - 如何实现多供应商支持
+   - 如何设计任务队列
+
+3. **学习视频处理**
+   - FFmpeg 集成
+   - 视频编码和优化
+   - 批量处理优化
+
+4. **考虑贡献代码**
+   - 开源项目需要社区贡献
+   - 可以提 issue 或提 PR
+
+### 企业用户
+
+如果你考虑在企业中使用:
+
+1. **评估 ROI**
+   - 效率提升 vs 工具成本
+   - 削减和人力成本节省
+   - 投资回报周期
+
+2. **数据安全**
+   - 本地部署 vs 云端部署
+   - API Key 安全管理
+   - 用户数据保护
+
+3. **团队培训**
+   - 工作流培训
+   - 最佳实践分享
+   - 持续优化和改进
+
+## 写在最后
+
+moyin-creator 代表了 AI 视频生成工具的一个方向:<span class="gradient-text">生产级工作流自动化</span>。
+
+它不是一个"黑科技",而是一套<span class="highlight-text">实用的工程化解决方案</span>。
+
+它的价值不在于用了什么先进技术,而在于:
+- 完整的产业链覆盖
+- 高效的批量生产能力
+- 好的质量控制
+- 合理的成本控制
+
+适合内容创作者、影视工作室、广告公司,或者任何需要批量生产视频内容的团队。
+
+但也要理性看待:
+- 不要被"批量生产"迷惑
+- 质量仍然是核心竞争力
+- 工具是辅助,不是替代人的创造力
+
+找到自己的节奏,持续优化,才是王道。
+
+## 参考
+
+- 项目地址: https://github.com/MemeCalculate/moyin-creator
+- 中文文档: https://www.bilibili.com/video/BV1FsZDBHExJ/?vd_source=802462c0708e775ce81f95b2e486f175
+- 网盘提取码: 8888

source/_posts/从Boris-Cherny的100-PR一周-我们能学到什么.md

@@ -0,0 +1,240 @@
+---
+title: 从Boris Cherny的100 PR一周,我们能学到什么
+author: Gamehu
+date: 2026-02-27 22:20:00
+tags:
+  - Claude Code
+  - AI
+  - 效率
+categories:
+  - 思考
+---
+<div class="tag-container">
+  <span class="ai-tag">Claude Code</span>
+  <span class="sub-tag">思考</span>
+</div>
+
+## 引言
+
+最近有篇 Medium 文章火了,标题很炸:<span class="gradient-text">Claude Code's Creator, 100 PRs a Week</span>。
+
+说的是 Boris Cherny,Claude Code 的核心开发者,一周提交了 100 个 PR。
+
+文章还提到了他的工作流:
+- 5 个 Claude 实例在终端跑
+- 另外 5-10 个在浏览器跑
+- 早上用手机启动会话
+- 晚上检查进展
+
+看得很震撼对吧?
+
+## 我的第一反应
+
+老实说,看完我<span class="highlight-text">有点焦虑</span>。
+
+一周 100 PR,平均每天 14 个 PR。
+这是人能干出来的量吗?
+
+但冷静下来想想,我看了下 Boris 之前分享的 13 条实战秘籍。
+
+结合这两份材料,我发现了一些<span class="warning">有意思的偏差</span>。
+
+## 这篇文章说了什么
+
+### Boris 的工作流
+
+根据文章,Boris 的设置是:
+
+1. **多实例并行**
+   - 5 个终端实例,跑 5 个 Claude Code
+   - 另外 5-10 个浏览器实例,干别的任务
+
+2. **24/7 监控**
+   - 早上用手机启动会话
+   - 白天在电脑干活
+   - 晚上检查进展
+   - 循环往复
+
+3. **极致优化**
+   - 每个实例都跑满
+   - 不等一个完再开下一个
+   - 充分利用 Claude 的并发能力
+
+结果:一周 100 PR。
+
+## 结合 Boris 的 13 条秘籍来分析
+
+### 一致的地方
+
+文章说的和工作流,和 Boris 的秘籍是一致的:
+
+1. **并行多个任务**
+   Boris 的第 2 条秘籍就是"并行多个任务"。
+   5-10 个实例,这确实是极限并行。
+
+2. **无人值守模式**
+   Boris 的第 3 条秘籍用 `--permission-mode=dontAsk`。
+   不用等他点批准,Claude 自己跑,不用等。
+
+3. **持续反馈和优化**
+   Boris 的第 13 条秘籍是"持续反馈和优化"。
+   团队每周多次更新 CLAUDE.md,持续优化。
+
+### 但文章遗漏了什么
+
+文章<span class="warning">只说了结果,没说代价</span>。
+
+100 PR 一周的背后:
+- 要有 10+ 个 Claude 实例
+- 要持续 24/7 监控
+- 要管理这么多会话的上下文
+- 要处理 100 个 PR 的 review
+
+这<span class="highlight-text">不是一般开发者能做到的</span>。
+
+## 我的判断
+
+### 这篇文章有用吗?
+
+有用,但<span class="warning">要谨慎看待</span>。
+
+### 有用的地方
+
+1. **展示了 Claude Code 的极限**
+   它确实能处理大量任务
+   并行确实能大幅提升效率
+
+2. **工作流的思路**
+   - 多实例并行
+   - 手机远程控制
+   - 持续监控
+   - 无人值守模式
+
+这些思路<span class="gradient-text">可以借鉴</span>,但不用照搬。
+
+3. **自动化的价值**
+   agent stop 钩子
+   Chrome 扩展自动测试
+   这些自动化确实能省时间
+
+### 要警惕的地方
+
+1. <span class="warning">容易引发焦虑</span>
+   看到"一周 100 PR",容易焦虑:
+   - 我是不是太慢了?
+   - 我是不是没充分用 AI?
+   - 我是不是不够努力?
+
+   但 Boris 是 Claude Code 的创建者,
+   他懂每一处细节,
+   他有整个团队支撑,
+   他做的是自己最擅长的事.
+
+2. <span class="warning">不适合普通开发者</span>
+   大部分人:
+   - 没有那么多实例预算
+   - 没有那么多监控时间
+   - 没有那么强的多任务能力
+   - 没有团队支撑
+
+   照搬这个工作流,大概率<span class="highlight-text">翻车</span>。
+
+3. <span class="warning">质量 vs 数量的平衡</span>
+   100 PR 一周,质量怎么样?
+   - 每个 PR 都认真 review 吗?
+   - 都有测试吗?
+   - 都有文档吗?
+
+   数量不是一切。
+
+## 普通人应该怎么做
+
+### 可以借鉴的
+
+1. **保持简单配置**
+   Boris 说得对,默认配置就够用.
+   别一上来就调配置.
+
+2. **并行 2-3 个任务**
+   量力而行,2-3 个就好.
+   Boris 的 5-10 个,是极限操作.
+
+3. **善用 /goal 命令**
+   把相关任务一起执行.
+   Claude 会自动处理依赖关系.
+
+4. **无人值守模式**
+   长任务用 `--permission-mode=dontAsk`.
+   不用一直守着点批准.
+
+5. **建立 CLAUDE.md**
+   把项目特有的事记下来.
+   避免重复踩坑.
+
+### 不建议照搬的
+
+1. **一天 14 个 PR**
+   没必要,真的没必要.
+   质量比数量重要.
+
+2. **24/7 监控**
+   不是所有人都这么干.
+   正常工作,有张有弛就行.
+
+3. **5-10 个实例**
+   资源消耗太大.
+   2-3 个实例就够了.
+
+4. **晚上检查进展**
+   正常下班就该下班.
+   没必要 24/7 在线.
+
+## 核心思想
+
+结合文章和 Boris 的秘籍,我觉得核心思想是:
+
+<span class="gradient-text">把 Claude Code 当作团队的一部分,而不是工具.</span>
+
+- 不是"让它帮我写代码"
+- 而是"它帮我干活,我管理"
+
+Boris 的成功,不是因为他开 10 个实例.
+而是因为他<span class="highlight-text">建立了一套高效的工作流</span>。
+
+这套工作流:
+- 清晰的任务拆分
+- 合理的并行策略
+- 自动化的质量保障
+- 持续的反馈优化
+
+## 写在最后
+
+这篇文章的价值,是<span class="highlight-text">展示了可能性</span>。
+
+但不要被数字迷惑.
+
+100 PR 一周,是:
+- Boris 作为创建者的极限操作
+- 有团队支撑
+- 有多年积累
+
+普通人:
+- 学思路,别学数字
+- 借鉴经验,别照搬
+- 找平衡,别追求极限
+
+Boris 自己都说,他的配置"出乎意料的简单".
+
+简单才是王道.
+
+<span class="warning">别让焦虑支配你。</span>
+
+找到适合自己的节奏,持续优化,就够了.
+
+Claude Code 是来<span class="gradient-text">提升效率的,不是制造焦虑的</span>。
+
+## 参考
+
+- 原推: https://x.com/bcherny/status/2007179832300581177
+- Medium 文章: https://medium.com/vibe-coding/claude-codes-creator-100-prs-a-week-his-setup-will-surprise-you-7d6939c99f2b
+- 我的 13 条秘籍文章: /claude-Code创始人的13条实战秘籍/

source/_posts/我把大厂那套搬到创业公司，各种水土不服.md

@@ -11,125 +11,170 @@ tags:
   - 敏捷
 ---
 
-## 引言
+前阵子带团队，踩过一个挺典型的坑：我把上一家大厂里跑得还不错的一整套研发流程，原封不动搬到了创业公司。
 
-在创业公司推行大厂那套敏捷流程，是我带团队踩过最大的坑。3个月后，团队从"高效能"变成"低情绪"，我才明白：**流程不是越重越好，而是越适合越好。**
+我当时还挺有信心的，心想这些东西我都实战过，也验证过，怎么都不至于太差。结果三个月不到，团队效率没上去，情绪先下来了。大家活没少干，但整个人的状态都不对，流程像套在身上的一层壳，怎么动都别扭。
 
-上家公司是成熟大厂，8-9人的小组配置齐全，走的是标准敏捷。加入创业公司后，我满怀信心地把这套经验照搬过来，结果却遭遇了各种水土不服。
+后来我才慢慢意识到一个事：**流程这东西，不是越完整越高级，也不是越像大厂越专业，关键是合不合适。**
 
-<!-- more -->
+上家公司是成熟中大厂，我们事业部有10个小组左右，通常8 到 9 个人的小组，角色配置相对完整，很多事情都有前提条件托着，标准敏捷那一套跑起来问题不大，比如我带的团队有9个人比现在创业公司带的人还多，工作得比较顺畅，所以我天然认为那套东西是好用的。可创业公司不是这个环境。人少、事杂、变化快，今天定的东西，明天可能就要推翻。这个时候你还想把流程铺得很满，最后大概率不是提效，而是添堵。
+
+下面说几个我自己踩得比较实在的坑。
 
 ---
 
-## 坑1：Jira看板——从精细管理到无用功
+## 1. Jira 看板搞得太细，最后大家都在伺候看板
 
-**场景**：我在创业公司引入Jira，要求任务拆分到设计、开发、测试、联调，精确到小时。
+刚开始我把 Jira 也上了，而且沿用了上家公司那种拆法。一个需求要拆到设计、开发、测试、联调，最好还能估到小时，状态流转也尽量完整。
 
-**水土不服**：需求天天变，看板刚建好就过时。整理信息花的时间比写代码还多，团队怨声载道。
+这套东西放在稳定一些的环境里，是有价值的。因为团队规模一大，协作链路一长，你不把信息结构化，很多事情就会乱。
 
-**调整方案**：砍掉Jira，改用甘特表只看整体节奏，不再拆分单个任务。
+当时我脑子里想的，其实差不多就是下面这种模式。一个板子看起来很清楚，列、卡片、负责人、状态，一眼望过去特别“专业”。
 
-**效果**：团队从"填表机器"变回"开发者"，效率明显回升。
+{% asset_img jira-kanban-board.png Jira 看板示意图 %}
 
----
+Jira 官方看板示意，来源：[Atlassian](https://www.atlassian.com/software/jira/features/kanban-boards)。
 
-## 坑2：详设模板——从全面细致到重难点小设
+但创业公司不是这么回事。
 
-**场景**：沿用大厂的详细设计模板，要求内容全面。
+创业公司最常见的情况是，需求今天这么说，明天又换了；老板上午说先做 A，下午看了竞品又觉得 B 更重要。这个时候看板刚整理清楚，内容就过时了。大家不是在推进任务，而是在不停维护任务卡片，补字段、改状态、对齐口径。
 
-**水土不服**：创业公司追求快速验证，没有充足时间做详细设计。写详设成了负担。
+慢慢地，团队开始烦这个东西。那种烦不是嘴上抱怨两句，而是你能明显感觉到，大家觉得在做无用功。
 
-**调整方案**：只做重难点的小设，模板精简至原版的1/3。非核心模块口头对齐。
+后来我们直接砍掉了这套细颗粒度管理，不再盯单个任务拆得多漂亮，只保留一个比较轻的整体节奏视图，主要看大的节点和关键事项。说白了，就是别再折腾一堆“过程看起来很美”的卡片，先把人从流程里解放出来。
 
-**效果**：工程师可以把时间用在真正重要的设计思考上。
+我们后面实际落地的方式，反而很土：一张每日跟踪表，再配一张整体计划表。没有那么多状态流转，也没有那么多字段，但它足够直观，够我们这个阶段用。
 
----
+这里先放两张我们当时真实在用的图（来源于产品负责人）：
 
-## 坑3：UI评审——从正式会议到三人碰头
+{% asset_img 1.jpg %}
 
-**场景**：建立正式的UI评审流程，多方参与。
+{% asset_img 2.jpg %}
 
-**水土不服**：等开完会，竞品已上线新功能。时间成本过高。
+改完以后，大家最直接的反馈不是“这个流程真先进”，而是终于不用天天填东西了。听着很朴素，但这往往说明方向对了。人重新把精力放回到做事本身，效率反而起来了。
 
-**调整方案**：前端+UI直接碰，或产品、前端、UI三人快速对齐。
+## 2. 详设模板很完整，但完整本身就是负担
 
-**效果**：决策速度提升，产品迭代跟上市场节奏。
+我以前的公司，详细设计是比较重视的，而且也确实有它的价值。系统复杂、协作方多、生命周期长，前面多花点时间把设计做扎实，后面能省不少事。
 
----
+所以到了创业公司，我也想把这个习惯延续下来，要求大家按比较完整的详设模板来。虽然我知道不能照搬原来公司的但是我想着先试着暴露问题再调，
+果然问题很快就出来了。
 
-## 坑4：Sprint迭代——从固定节奏到流动式
+1. 团队成员几乎都没有正儿八经的写过详设，可能是在如今的软件开发，大家完全摒弃或者看不上很多年前的研发流程，所以不重视也不愿意接触。（但是经验告诉我存在既合理，你可以改进单不能完全否定，至少对我来说详设是让你想清楚你要做什么怎么做的过程，其实并不冲突）
+2. 创业公司讲究的是快速验证，你先得证明这个东西值不值得做、能不能跑通、市场买不买单。有些模块的生命周期可能很短，有些模块就是很简单的CRUD。这个时候还要求每个需求都搞一份“大而全”的详设，性价比很低。
 
-**场景**：推行标准的单周/双周Sprint，站会、回顾、估时样样不落。
+后来我的调整是，只保留重难点设计。
 
-**水土不服**：业务方今天提需求，明天要上线。固定迭代成了阻力。
+也就是说，不是不要设计，而是只在真正有必要的地方认真写。比如复杂流程、核心链路、容易出事故的地方，这些该写还是得写，而且要写清楚。至于那些简单页面、普通接口、试验性质的功能，就没必要搞得那么正式，很多时候口头对齐一下，加上关键点同步，也就够了。
 
-**调整方案**：放弃固定迭代周期，拥抱流动式开发，以交付价值为导向。
+模板也顺手砍掉了大半，能简就简。并比如只保留异常处理、数据库设计、关键算法、外部引入说明等章节。
 
-**效果**：团队不再为流程而流程，专注解决实际问题。
+这么改完以后，大家不会因为“要交一份文档”才去写东西，而是因为“这里确实需要想清楚”才写。这个差别挺大。前者容易把写文档变成任务，后者才更接近设计本身。
 
----
+## 3. UI 评审流程太正式，节奏根本跟不上
 
-## 坑5：工时评估——从精确承诺到大致窗口
+我一开始还认真搭了 UI 评审流程，想着把产品、UI、前端这些角色都拉齐，尽量在正式评审里把问题消化掉。
 
-**场景**：要求精确工时评估和排期承诺。
+这个思路本身没错。问题还是那个问题，环境不对。
 
-**水土不服**：估不准，团队被deadline追着跑，焦虑感蔓延。
+创业公司很多时候拼的不是“流程是否完备”，而是“反应够不够快”。有时候你这边还在约会、准备材料、等人齐，外面竞品已经上线了。等你一轮会开完，讨论很充分，市场窗口也差不多过去了。
 
-**调整方案**：只看大致时间窗口，不拆细粒度任务，给团队灵活性。
+后来我就把这件事彻底做轻了。
 
-**效果**：团队情绪好转，交付的可预期性反而更高。
+多数情况下，前端和 UI 直接碰一下；如果产品逻辑也有争议，就三个人凑一起，当场对齐。能站着说完就别拉长会，能今天拍板就别拖到明天。先把主要分歧解决掉，剩下的小问题边做边收。
 
----
+这样做当然没那么“规范”，但更符合创业公司的现实。
 
-## 关键洞察
+很多流程设计，表面上是在降低风险，实际上是在用确定性对冲不确定性。可创业公司真正的问题往往不是“讨论不够充分”，而是“动作不够快”。这时候流程越重，可能越错。
 
-> **"创业公司不是大厂的缩小版，而是完全不同的物种。"**
+## 4. Sprint 很标准，但标准得有点不合时宜
 
-| 维度 | 成熟中大型公司 | 小型创业公司（<10人） |
-|-----|---------------|---------------------|
-| 目标 | 稳定、可预测 | 快速验证、灵活调整 |
-| 流程 | 标准敏捷 | 能跑就行 |
-| 适用方式 | 标准化流程 | 灵活优先 |
+我之前也试着在创业公司推标准 Sprint，单周也好，双周也好，站会、估时、回顾这些动作都想带起来。
 
-### 关于人性因素
+现在回头看，方向有点想当然了。
 
-很多人忽略了一点：**研发人员不喜欢文字工作。**
+标准 Sprint 背后有个很重要的前提，就是需求相对稳定，或者至少在一个迭代周期内，不要被打断得太厉害。这样团队才能围绕承诺来组织协作，节奏也才跑得顺。
 
-减少无效文档，不只是省时间，更是**尊重专业人员的做事方式**。让工程师专注于写代码和解决问题，而不是填表格和写报告，这才是对他们最大的尊重。
+可创业公司常常不是这种节奏。业务方今天提一个需求，明天就要看结果；线上出了点情况，当前优先级立刻变化；老板临时看到了一个机会，整个排期可能都要让路。
 
-> **核心洞察：研发人员不喜欢文字工作 —— 这是很多人忽略的人性因素。减少无效文档，不只是省时间，更是尊重专业人员的做事方式。**
+在这种情况下，固定迭代周期很容易从“管理工具”变成“现实阻力”。
 
-### 关于底线思维
+你会发现团队嘴上还在讲 Sprint，实际上天天都在被插单。于是形式上很完整，执行上很别扭，大家最后既没享受到 Sprint 的好处，还多了一层心理负担。
 
-灵活不是混乱，是在底线之上自由发挥。
+后来我就不硬推固定迭代了，更偏向流动式开发。优先保证关键事情快速流过来、快速被处理掉，而不是先想办法把所有事情塞进一个看起来工整的周期里。
 
-基础规则不能丢——代码规范、版本控制、线上安全这些底线必须守住。但在底线之上，给团队足够的空间去发挥创造力。
+说白了，就是别为了流程的完整感，牺牲交付的真实节奏。
 
-> **基础规则不能丢 —— 灵活不是混乱，是在底线之上自由发挥。**
+## 5. 工时估得越细，大家越焦虑
 
----
+还有一个坑也挺常见，就是工时评估。
+
+大厂里很多时候要做资源管理、项目协同、跨团队承诺，所以你会比较强调估时，甚至希望大家估得尽量准一些。这在某些环境下有它的合理性。
 
-## 判断标准：什么阶段用什么模式
+但在创业公司里，很多需求本身就带着不确定性。你连边界都没完全看清，非要提前精确承诺到某个点，最后大概率是两头难受。
 
-**成熟中大型公司**：有专职敏捷教练和成熟体系，标准化流程效率高。
+一头是管理者以为自己拿到了确定性，另一头是执行的人背着一个并不靠谱的 deadline，越做越紧张。
 
-**小型创业公司（<10人）**：怎么灵活怎么来，但要有基础规则底线。
+尤其是一些复杂问题，真正难的地方往往在做之前并不能完全看出来。你要求团队给一个很精确的工时，看起来是在做计划，实际上可能是在制造幻觉。
+
+后来我不再盯精确工时，而是更多给出一个大致时间窗口。该说明风险就说明风险，该留缓冲就留缓冲，不再逼着大家把很多本来就估不准的事情说得特别肯定。
+
+结果挺有意思，精确度没那么好看了，但交付反而更可预期了，团队状态也轻松不少。
 
 ---
 
-## 调整后的效果
+## 后来我真正想明白的几件事
+
+### 1. 创业公司不是大厂缩小版
+
+这个是最核心的一条。
+
+很多人从大厂出来，容易有个潜意识：创业公司只是规模小一点，很多管理动作做轻一点就行了。
+
+其实不是。
+
+这两种组织在很多底层逻辑上都不一样。大厂更多追求稳定、可复制、可预测，流程是拿来放大协作效率、控制系统风险的。创业公司很多时候追求的是快速试错、快速验证、快速调整，它首先得活下来，然后才谈得上优化。
 
-- **效率提升**：减少无效流程，专注核心价值交付
-- **团队情绪改善**：研发人员不喜欢文字工作，通过这种方式，他们基本上不用拆那么细的任务，也不用写很细的文档，灵活性和自由度都更高，所以大家的感受比较好
+所以你不能简单理解成，大厂那套减配一下就能直接用。
+
+### 2. 研发天然就不喜欢太重的文字工作
+
+这个事挺现实的，但很多管理动作设计的时候经常假装看不见。
+
+大多数研发真没那么喜欢填表、写一堆过程文档、反复同步那些价值不高的信息。不是因为懒，而是因为他们天然更愿意把注意力放在解决问题、写代码、做实现上。
+
+所以减少无效文档，并不只是为了省时间，本质上也是一种尊重。你尊重一个岗位的工作重心，团队的配合度通常就会高很多。
+
+当然，这不是说文档没用。我的意思只是，别把“有文档”当成默认正确，而是先想清楚，这份东西到底帮了谁，解决了什么问题，值不值得花这个成本。
+
+### 3. 灵活不等于混乱，底线还是要有
+
+创业公司不适合重流程，不代表什么都可以不要。
+
+有些底线是不能退的，比如代码规范、版本管理、发布安全、线上稳定性这些东西。这些不是“有空再说”的选项，而是基本盘。没有这些，所谓灵活很容易滑成混乱，最后大家都在救火。
+
+我现在更认同的一种状态是：**在底线之上尽量灵活。**
+
+该守住的东西守住，剩下的就别绑太死。不要一边嘴上说着创业公司要快，一边又把团队拴进一堆并不适合当下阶段的流程里。
 
 ---
 
-## 结语
+## 什么阶段适合什么模式
 
-流程是手段，不是目的。当流程成为阻力，就该砍掉。
+如果是成熟一些的中大型团队，人员配置完整，协作链条长，项目复杂度也高，那标准化流程通常是有收益的。它能提升协作效率，也能降低很多因为人多而带来的不确定性。
 
-**尊重研发人员的专业方式，比强迫他们适应流程更重要。**
+但如果是小型创业团队，尤其是不到 10 个人的研发团队，我现在的看法会很明确：**怎么灵活怎么来，但底线要守住。**
+
+不是不要流程，而是只保留那些真正帮你提效的流程。凡是已经开始明显拖慢节奏、压坏情绪、制造无意义劳动的东西，就该果断砍。
 
 ---
 
-如果你的团队也在用大厂模式却感觉吃力，不妨问自己：**我们是在追求流程的完美，还是在追求交付的效率？** 欢迎在评论区分享你的经验。
+## 最后的话
+
+流程是手段，不是目的。
+
+以前我总觉得，一个团队越专业，流程应该越完整。后来才发现，不是这么回事。真正成熟的团队，不是流程堆得最满的团队，而是知道什么该坚持，什么该省掉，什么阶段该用什么方法的团队。
+
+说得再直白一点，创业公司最怕的不是“不够像大厂”，而是明明身子还很轻，却非要背上一整套大厂的装备。
+
+那玩意儿穿在大厂身上可能是铠甲，穿在创业公司身上，很多时候就是负重。

source/_posts/把-Claude-Code-变成无限时间的你：4-个改变我日常工作的-Skills.md

@@ -0,0 +1,186 @@
+---
+title: 把 Claude Code 变成"无限时间的你"：4 个改变我日常工作的 Skills
+author: Gamehu
+tags:
+  - Skills
+categories:
+  - AI
+date: 2025-01-25 22:45:00
+---
+<div class="tag-container">
+  <span class="ai-tag">Skills</span>
+</div>
+
+<div class="article-quote">
+刷到一条推文讲前端的 Claude Code Skills，之前几年也写了差不多3年左右的前端，以此做个记录方便后续查看。
+</div>
+
+---
+
+## Skills 是什么？
+
+很多人听到 Skills 第一反应：不就是保存的提示词吗？
+
+这是个误解。
+
+**Skills ≠ 提示词模板**
+
+Skills 更像是**AI 的专业工具包**——就像人类专家脑子里随时能调用的知识库。你不用每次都解释"什么是好的 UX 设计"，而是告诉 Claude："用 iOS 设计专家的脑子帮我看看这段代码"。
+
+技术上说，它是可复用的指令集：定义方法、遵循模式、输出格式。优势就是不用每次从零开始解释需求。
+
+作者有个有趣的比喻：Skills 像强化版的保存提示词。你不用每次都解释想要什么，只要调用某个 Skill，Claude 就知道该用什么"剧本"。
+
+---
+
+## 四个真正改变工作的 Skills
+
+### 1. mobile-ios-design：从"能用"到"原生体验"
+
+作者最近实验了一个工作流：Claude 生成 PRD → 设计工具出图 → Figma → Claude Code 用 SwiftUI 构建应用。
+
+跑通了，但不对劲：硬编码文本样式、间距不一致、导航像混合应用不像原生 iOS。
+
+然后他试了 `mobile-ios-design` 这个 Skill。
+
+它会扫描整个应用，强制执行 iOS Human Interface Guidelines：修正系统颜色、应用原生导航、使用正确的文本样式。
+
+**结果**：初次构建后跑一次，应用突然就像"苹果原生出品"了。
+
+**我的感受**：不是说 Claude 不懂 iOS 规范，问题是如果你每次都要告诉它按 HIG 设计，那还不如自己写。有了 Skill，一个命令就能让 Claude 像专业 iOS 开发者那样思考。
+
+---
+
+### 2. Impeccable：设计优化的瑞士军刀
+
+Impeccable 是设计工具包，有 15+ 子技能。作者常用这几个：
+
+| 子技能 | 用途 | 解决什么问题 |
+|--------|------|-------------|
+| critique | 感觉"哪里不对"但说不上来 | 获取 UX 反馈，找痛点 |
+| polish | 交付前最后检查 | 对齐、间距、一致性 |
+| simplify | 过度设计需要做减法 | 剥离到核心要素 |
+| normalize | AI 生成的组件不符设计系统 | 匹配现有 tokens |
+
+**工作流变化**：以前 Figma 里手动调 → 导出代码 → 再调；现在直接 `impeccable:polish` 在代码层面优化。
+
+这不是说 Figma 没用了，而是**"设计"可以从代码层面开始**，而不是必须从 Figma 开始。
+
+---
+
+### 3. Feature Discovery：把一周研究变成一小时自动化
+
+作者在电商公司，团队维护 4 个平台。每次上新功能前要做大量研究——"正确"的话可能很久。
+
+但有时候只是想快速验证一个想法：没有 sprint planning，没有 Jira tickets，没有 OKR meetings。只想要一个快速回答：**"这是个好主意吗？"**
+
+所以他做了这个 Skill。
+
+你给 Skill 一个功能想法，Claude 跑六个阶段：
+
+1. **Brief & Audit**：结构化你的想法 + 批判现状
+2. **Competitor Research**：从 Mobbin 拉竞品模式，分析对手
+3. **Edge Cases & Flows**：映射用户流程 + 盘点边界情况
+4. **Recommendations**：优先级排序（快速赢、中期修复、路线图项）
+5. **Prototypes**：生成交互式 React/Tailwind 原型（含前后对比）
+6. **Report**：打包成 Markdown 报告，含领导层摘要
+
+可以按顺序全做，也可以每个阶段后停下来评估。作者用它解决的问题："桌面端导航用汉堡菜单好吗"、"iOS 列表页要不要加单列视图"。
+
+**他的结论**："它不会替代思考，但能帮我更快评估一个想法是否值得深挖。"
+
+---
+
+### 4. App Niche Hunter：睡觉时自动做市场调研
+
+这个是给个人项目用的，相对更简单有趣。
+
+流程：给 Claude Code 一个 niche（比如 "sleep apps"），它开始干活：
+
+1. 搜索 App Store，找这个类别的 top apps（免费 + 付费）
+2. 抓取头部应用的 1 星和 2 星差评
+3. 提取差评中的共性痛点
+4. 识别可以被新应用填补的空缺
+5. 在 Rork（低代码工具）里构建原型
+6. 发送测试链接给你
+
+**场景**：输入 "sleep apps"，几小时后拿到的原型——**基于真实用户抱怨，不是个人假设**。
+
+作者说："这原型可能没那么'高级'，但能直接用。想继续做的话，之后再优化品牌和设计。"
+
+**他的反思**："不是每次都能找到金子。但把 '我想看看 X 领域有没有机会' 从周末研究项目，变成了做别的事时能自动跑的任务。"
+
+---
+
+## 为什么 Skills 改变了工作方式？
+
+作者这句话点到了核心：
+
+> "Claude Code 本身很强大。你能构建应用、修复 bug、交付项目。"
+
+> "但加了 Skills 的 Claude Code 是完全不同的工具。它不是'帮我把这个做出来'，而是'如果我有无限时间，我会怎样做这个——帮我按那个标准做出来'。"
+
+**从"能跑通"到"像专业工程师那样做"**：
+
+| 维度 | Claude Code 原生 | Claude Code + Skills |
+|------|-----------------|---------------------|
+| 产出质量 | 能用，但有各种问题 | 符合专业标准 |
+| 知识调用 | 每次要解释 | 一次定义，永久复用 |
+| 时间分配 | 80% 调细节 | 80% 思考核心问题 |
+
+mobile-ios-design 比 HIG 文档背得熟；Impeccable 能发现注意不到的设计问题；Feature Discovery 做懒得做的竞品研究；Niche Hunter 探索永远不会去做的事情。
+
+**不是"替代"而是"赋能"**。Skills 不会让你的判断力消失，它释放时间让你专注在真正重要的事上：这个想法值得继续吗？这个设计够好吗？现在该做什么？
+
+---
+
+## 如何开始？
+
+作者的建议：
+
+**从小处入手**
+
+找每天做、重复性高、烦人的任务，变成 Skill：
+- 每次都要告诉 AI "按我们的设计系统风格写代码"？→ 做 `design-system` skill
+- 每次都要强调 "用 TypeScript、写注释、加测试"？→ 做 `best-practices` skill
+- 每次都要检查 "有没有 XSS、SQL 注入"？→ 做 `security-review` skill
+
+**不要追求完美**
+
+先让跑通，再迭代优化。
+
+**分享你的 Skills**
+
+公开本身就是机会。作者当初没投简历，只是在 X 上发小项目、踩过的坑、试过的提示词。公司的人看到了，主动找过来。
+
+**作品就是机会。**
+
+---
+
+## 尾声
+
+想起那句话：当"把东西做出来"变得无比廉价，什么会变得无比稀缺？
+
+**清晰度、品味、判断力。**
+
+Skills 能帮你快速做到"能跑通"，甚至"符合专业标准"。
+
+但真正的魔法感——让用户第一次点开页面时心里"哇"一声；让同事用你的内部工具时感觉"这比商业软件还顺手"——仍然来自你。
+
+来自你的**判断力**：知道什么该留，什么该砍，什么该磨三天，什么该一键生成。
+
+来自你的**清晰度**：能把脑子里那团模糊兴奋的感觉，翻译成工具能理解的指令。
+
+来自你的**品味**：能区分"还行"和"惊艳"，能在所有人都满足于"跑通了"时，对自己说：
+
+**"还可以更好。"**
+
+---
+
+## 参考
+
+- My Claude Code Skills Setup - Frederik on X: https://x.com/froessell/status/2025833621299351613
+- 从"没写过一行代码"到全职 Vibe Coder：[Vibe Coder](2026/02/11/从"没写过一行代码"到全职Vibe Coder：我是如何用AI打破职业边界的/)
+- 理清 AI 交互中的核心概念：[核心概念](2026/01/27/理清 AI 交互中的核心概念/)
+- iOS Human Interface Guidelines: https://developer.apple.com/design/human-interface-guidelines/
+- Impeccable Design Toolkit: https://impeccable.design/

source/_posts/搭建我的专属AI助手：OpenClaw云服务器部署实战指南.md

@@ -0,0 +1,1914 @@
+---
+title: 搭建我的专属AI助手：OpenClaw云服务器部署实战指南
+author: Gamehu
+tags:
+  - OpenClaw
+  - AI
+  - DevOps
+  - 部署
+  - 记录系统优化
+categories:
+  - 工具
+date: 2026-02-27 22:30:00
+updated: 2026-03-06 14:10:00
+---
+
+> 📢 **更新日志**：
+> - 2026-03-06 新增 `Step-3.5-Flash` 接入与会话级 `/model` 切换说明，补充默认模型不切全局、只切当前会话的使用方式。
+> - 2026-03-03 新增"记录系统优化"章节，解决会话文件膨胀问题，添加自动归档和结构化存储方案。
+
+<div class="tag-container">
+  <span class="ai-tag">AI提效</span>
+  <span class="sub-tag">实战踩坑</span>
+</div>
+
+## 写在前面
+
+最近刷到不少 OpenClaw 的文章，演示零成本安装、智能体集群、国内部署经验。我手头正好有台 2 核 3G 的云服务器闲置着，决定动手搭建一个专属 AI 助手。
+
+但这篇文章不是推广，是<span class="highlight-text">真实的部署踩坑记录</span>。整个过程历时数小时，遇到了 OOM 内存不足、配置验证失败、防火墙规则冲突等一系列问题，把完整的解决过程记录下来。
+
+**先说结论**：OpenClaw 确实能跑起来，但需要对 Docker、网络和 Linux 有一定了解，且内存配置要充足。
+
+---
+
+## OpenClaw 是什么
+
+OpenClaw 是一个开源的个人 AI 助手框架，核心价值在于：**它不是只聊天的 AI，而是能动手干活的 AI**。
+
+核心能力：
+- 在 Telegram、Discord、Slack 等平台接收指令
+- 操作文件系统、执行 Shell 命令、浏览网页
+- 调用 API、读写数据库
+- 跨会话持久化记忆
+
+最重要的是——运行在自己的服务器上，数据完全掌控。
+
+---
+
+## 我的环境
+
+搬瓦工买的一台机器，配置不高，平时捣鼓各种东西的。
+
+| 配置项 | 实际环境 |
+|--------|----------|
+| 系统 | Ubuntu 24.04.2 LTS |
+| CPU | 3 核 |
+| 内存 | 2GB RAM |
+| 磁盘 | 39GB SSD |
+| Docker | 29.2.1 |
+| Docker Compose | v5.1.0 |
+| 公网 IP | your-server-ip |
+
+> ⚠️ **重要提示**：2GB 内存对于源码构建来说不够，需要配置 Swap。
+
+---
+
+## 部署过程实录
+
+### 第一步：安装 Docker
+
+Ubuntu 24.04 下安装 Docker 很顺利：
+
+```bash
+# 更新系统
+apt update && apt upgrade -y
+
+# 安装 Docker
+curl -fsSL https://get.docker.com | sh
+
+# 验证安装
+docker --version  # Docker version 29.2.1
+docker compose version  # Docker Compose version v5.5.1
+```
+
+国内用户建议配置镜像加速，编辑 `/etc/docker/daemon.json`：
+
+```json
+{
+  "registry-mirrors": [
+    "https://docker.1ms.run",
+    "https://dockerhub.icu"
+  ]
+}
+```
+
+---
+
+### 第二步：源码构建（第一个坑：OOM）
+
+官方提供了 Docker 镜像，但我选择从源码构建以获得最新功能：
+
+```bash
+mkdir -p /opt/openclaw
+cd /opt/openclaw
+git clone https://github.com/openclaw/openclaw.git
+cd openclaw
+```
+
+开始构建：
+
+```bash
+docker build -t openclaw:local -f Dockerfile .
+```
+
+<span class="warning">🚨 第一个大坑：构建到 `pnpm install` 时容器被杀</span>
+
+查看日志发现是 **OOM（内存不足）**。2GB RAM 在构建 Node.js 项目时不够用，`pnpm install` 直接占满内存导致进程被系统杀死。
+
+**解决方案：添加 Swap 空间**
+
+```bash
+# 创建 5GB Swap 文件
+dd if=/dev/zero of=/swapfile bs=1G count=5
+chmod 600 /swapfile
+mkswap /swapfile
+swapon /swapfile
+
+# 验证
+free -h
+# 显示：Swap: 5.0Gi
+```
+
+添加 Swap 后重新构建，成功完成。
+
+> 📷 **安装过程 - 添加 Swap 解决 OOM**：
+> 
+> ![安装过程](/images/openclaw/01-installation.jpeg)
+
+---
+
+### 第三步：配置 OpenClaw
+
+创建 `docker-compose.yml`：
+
+```yaml
+version: '3.8'
+
+services:
+  openclaw-gateway:
+    image: openclaw:local
+    container_name: openclaw
+    restart: unless-stopped
+    environment:
+      - HOME=/home/node
+      - NODE_ENV=production
+    volumes:
+      - ./.openclaw:/home/node/.openclaw
+      - ./.openclaw/workspace:/home/node/.openclaw/workspace
+    ports:
+      - "127.0.0.1:18789:18789"
+      - "127.0.0.1:18790:18790"
+    command: ["node", "dist/index.js", "gateway", "--bind", "lan", "--port", "18789"]
+```
+
+<span class="warning">🚨 第二个坑：配置验证极其严格</span>
+
+OpenClaw 对 `openclaw.json` 配置文件的校验非常严格，很多字段在官方文档中没有明确说明，但缺失会导致启动失败。
+
+**我遇到的错误：**
+
+```
+✖ Configuration validation failed:
+  - gateway.mode is required
+  - gateway.controlUi.allowedOrigins is required when using non-loopback bind
+```
+
+**正确的最小配置**（`openclaw.json`）：
+
+```json
+{
+  "gateway": {
+    "port": 18789,
+    "mode": "local",
+    "controlUi": {
+      "allowedOrigins": ["http://localhost:18789", "http://127.0.0.1:18789"]
+    },
+    "auth": {
+      "token": "your-secure-token-here"
+    }
+  }
+}
+```
+
+> 📷 **OpenClaw Web UI 界面**：
+> 
+> ![OpenClaw Web UI](/images/openclaw/03-web-ui.jpg)
+
+> **关键注意点**：
+> - `gateway.mode` 必须显式设置为 `"local"`
+> - `gateway.controlUi.allowedOrigins` 在使用非 localhost 绑定时是必需的
+> - `gateway.bind` **不能写在 JSON 中**（无效字段），必须通过 CLI 参数 `--bind lan` 设置
+
+---
+
+### 第四步：配置阿里云百炼模型
+
+我选择使用阿里云百炼的 Coding Plan，配置 kimi-k2.5 作为主力模型：
+
+```json
+{
+  "models": {
+    "mode": "merge",
+    "providers": {
+      "bailian": {
+        "baseUrl": "https://coding.dashscope.aliyuncs.com/v1",
+        "apiKey": "YOUR_BAILIAN_API_KEY",
+        "api": "openai-completions",
+        "models": [
+          {
+            "id": "kimi-k2.5",
+            "name": "kimi-k2.5",
+            "input": ["text", "image"],
+            "contextWindow": 262144,
+            "maxTokens": 32768
+          },
+          {
+            "id": "qwen3.5-plus",
+            "name": "qwen3.5-plus",
+            "input": ["text", "image"],
+            "contextWindow": 1000000,
+            "maxTokens": 65536
+          }
+        ]
+      }
+    }
+  },
+  "agents": {
+    "defaults": {
+      "model": {
+        "primary": "bailian/kimi-k2.5"
+      }
+    }
+  }
+}
+```
+
+---
+
+### 第五步：配置 Telegram Bot
+
+在 [@BotFather](https://t.me/BotFather) 创建 Bot 并获取 Token。
+
+<span class="warning">🚨 第三个坑：配对码过期与 dmPolicy 冲突</span>
+
+```json
+{
+  "channels": {
+    "telegram": {
+      "enabled": true,
+      "botToken": "YOUR_BOT_TOKEN_HERE",
+      "allowFrom": ["YOUR_TELEGRAM_USER_ID"]
+    }
+  }
+}
+```
+
+初始配置时我加了 `"dmPolicy": "open"`，结果与 `allowFrom` 白名单冲突，报错：
+
+```
+dmPolicy: open requires allowFrom: ["*"]
+```
+
+**解决方案**：删除 `dmPolicy` 字段，直接使用 `allowFrom` 白名单。
+
+启动服务：
+
+```bash
+docker compose up -d
+docker compose logs -f
+```
+
+看到日志显示 `Telegram channel started` 且没有错误，说明 Bot 已上线。
+
+> 📷 **Telegram Bot 配置成功**：
+
+---
+
+### 第六步：Google Workspace 集成（扩展能力）
+
+这是 OpenClaw 真正强大的地方——通过 Google Workspace 集成，AI 可以帮你管理邮件、日历、文档。
+
+OpenClaw 使用 `gog` skill 来访问 Google 服务（Gmail、Calendar、Drive、Docs、Sheets）。
+
+#### 6.1 创建 Google Cloud 项目
+
+1. 访问 [Google Cloud Console](https://console.cloud.google.com/)
+2. 创建新项目（例如：`openclaw-integration`）
+3. 启用以下 API：
+   - Gmail API
+   - Google Calendar API
+   - Google Drive API
+   - Google Docs API
+   - Google Sheets API
+
+#### 6.2 配置 OAuth 凭据
+
+1. 进入 **APIs & Services > Credentials**
+2. 点击 **Create Credentials > OAuth client ID**
+3. 选择 **Desktop app** 类型
+4. 记下 **Client ID** 和 **Client Secret**
+
+#### 6.3 配置 MCP 服务器
+
+OpenClaw 通过 MCP (Model Context Protocol) 集成 Google Workspace。
+
+在服务器上创建 MCP 配置文件：
+
+```bash
+mkdir -p /opt/openclaw/.openclaw/mcp
+cat > /opt/openclaw/.openclaw/mcp/google-workspace.json << 'EOF'
+{
+  "mcpServers": {
+    "google-workspace": {
+      "command": "npx",
+      "args": ["-y", "@gongchangio/mcp-google-workspace"],
+      "env": {
+        "GOOGLE_CLIENT_ID": "your-client-id.apps.googleusercontent.com",
+        "GOOGLE_CLIENT_SECRET": "your-client-secret",
+        "GOOGLE_REDIRECT_URI": "http://localhost:18790/oauth2callback"
+      }
+    }
+  }
+}
+EOF
+```
+
+#### 6.4 重启 OpenClaw 并授权
+
+```bash
+cd /opt/openclaw
+docker compose restart
+
+# 查看日志等待授权提示
+docker compose logs -f | grep -i google
+```
+
+首次启动会显示 OAuth 授权链接，在浏览器中打开并授权后，会获得一个 code，将其填回即可。
+
+#### 6.5 实际使用场景
+
+配置完成后，你可以通过 Telegram 让 AI 帮你：
+
+**管理邮件**：
+> "帮我查看今天的重要邮件，并回复需要处理的"
+
+**操作日历**：
+> "帮我查一下下周的会议安排，把周五下午的会议改到周四"
+
+**读写文档**：
+> "读取 Drive 里的 '项目计划.docx'，帮我总结要点并更新状态"
+
+<span class="warning">⚠️ 注意：Google OAuth 有权限范围限制</span>
+
+- 个人 Gmail 账户：直接可用
+- Google Workspace（企业账户）：需要管理员授权
+- 敏感范围（如删除邮件）需要额外验证
+
+---
+
+### 第七步：安全加固（重中之重）
+
+<span class="warning">🚨 第四个坑：Docker 绕过 INPUT 链的防火墙规则</span>
+
+我最初的防火墙配置：
+
+```bash
+iptables -I INPUT 1 -p tcp --dport 18789 -s 127.0.0.1 -j ACCEPT
+iptables -I INPUT 2 -p tcp --dport 18789 -j DROP
+```
+
+测试发现：**公网仍然可以访问 Web UI！**
+
+**原因**：Docker 在 `DOCKER` 链中插入了 ACCEPT 规则，且该链在 `INPUT` 链之前被处理。
+
+**正确的解决方案**：使用 `DOCKER-USER` 链
+
+```bash
+# 在 DOCKER-USER 链中插入规则（在 Docker 规则之前执行）
+iptables -I DOCKER-USER 1 -p tcp -s 127.0.0.1 --dport 18789 -j ACCEPT
+iptables -I DOCKER-USER 2 -p tcp --dport 18789 -j DROP
+iptables -I DOCKER-USER 3 -p tcp -s 127.0.0.1 --dport 18790 -j ACCEPT
+iptables -I DOCKER-USER 4 -p tcp --dport 18790 -j DROP
+
+# 保存规则
+iptables-save > /root/iptables-rules.txt
+```
+
+**最终安全策略**：
+
+| 项目 | 状态 |
+|------|------|
+| 配置文件权限 | 容器运行用户可读（避免 `EACCES`） |
+| 公网 Web UI | 通过 `DOCKER-USER` 链完全阻止 |
+| 本地 Web UI | 127.0.0.1 可访问 |
+| Telegram 访问 | 仅白名单用户 ID 可用 |
+| 外部访问方式 | SSH 隧道 |
+
+> 📷 **最后安全检查 - 安全加固结果**：
+> 
+> ![安全检查](/images/openclaw/02-security-check.jpeg)
+
+**SSH 隧道访问命令**：
+
+```bash
+ssh -N -L 18789:127.0.0.1:18789 root@your-server-ip
+# 然后在本地浏览器访问 http://localhost:18789
+```
+
+---
+
+## 进阶玩法：持久记忆配置（第9步）
+
+OpenClaw 的持久记忆系统让它能跨会话记住你的偏好、项目信息和个人习惯。这是从"工具"升级为"助手"的关键。
+
+### 记忆文件目录结构
+
+| 路径 | 用途 | 文件类型 |
+|------|------|----------|
+| `/home/node/.openclaw/memory/` | 数据库存储（自动） | `main.sqlite` - 对话历史 |
+| `/home/node/.openclaw/workspace/` | 结构化记忆文件 | `MEMORY.md`, `USER.md` |
+| `/home/node/.openclaw/workspace/memory/` | 每日记忆归档 | `YYYY-MM-DD.md` |
+
+### 核心记忆文件
+
+#### 1. USER.md - 用户档案
+
+```markdown
+# USER.md - About Your Human
+
+- **Name:** Gamehu
+- **What to call them:** Gamehu
+- **Timezone:** Asia/Shanghai (UTC+8)
+
+## Context
+- **职业:** IT 行业，编程 + 团队管理
+- **需求:** 个人助手
+- **风格偏好:** 简单直接，不绕弯子
+```
+
+#### 2. MEMORY.md - 长期记忆
+
+```markdown
+# MEMORY.md - Long-term Memory
+
+## Technical Stack
+- **Primary Languages:** Java, JavaScript, Python, Go
+- **Frameworks:** Spring Boot, React
+- **Cloud:** Alibaba Cloud, AWS
+
+### Preferences
+- **Code Style:** Clean, well-documented
+- **Learning Style:** Hands-on, project-based
+- **Dislikes:** Repetitive small talk
+
+### Current Projects
+- Building personal AI assistant
+- Managing development team
+```
+
+### 如何工作
+
+1. **自动记忆**：所有对话自动存入 SQLite，跨会话保持上下文
+2. **结构化记忆**：AI 主动读取 MEMORY.md 了解你的背景和偏好
+3. **持续更新**：OpenClaw 会定期根据对话更新记忆文件
+
+### 测试持久记忆
+
+给 Bot 发送：
+> "记住我喜欢用 Go 语言写后端服务"
+
+过一段时间再问：
+> "我之前告诉你我喜欢用什么语言？"
+
+如果配置正确，Bot 应该能回答出 **Go**。
+
+---
+
+## 进阶玩法：记录系统优化（第9.5步，新增）
+
+在解决 compaction 卡死问题后，我意识到 OpenClaw 的会话记录管理还有很多优化空间。之前的经历是：会话文件在两天内膨胀到 1.4MB（603 条消息），导致系统卡死。为了防止类似问题再次发生，我设计并部署了一套**结构化的记录管理系统**。
+
+### 为什么需要记录系统优化
+
+| 问题 | 优化前 | 优化后 |
+|------|--------|--------|
+| 会话文件膨胀 | 1.4MB（603条消息） | 每日自动归档，单文件 < 100KB |
+| 数据管理 | 所有文件混在一起 | 结构化分类存储 |
+| 查找历史 | 翻找 JSONL 文件 | Markdown 摘要，一目了然 |
+| 数据备份 | 手动复制 | 自动归档 + 一键导出 |
+
+### 优化后的目录结构
+
+我在 `workspace` 下创建了完整的分类存储结构：
+
+```
+/root/.openclaw/workspace/
+├── memory/                    # 记忆类数据
+│   ├── daily/                # 每日摘要 (YYYY-MM-DD.md)
+│   ├── weekly/               # 每周汇总
+│   └── archived/             # 长期归档
+├── records/                   # 记录类数据
+│   ├── conversations/        # 对话记录 (按月归档)
+│   │   └── 2026-03/
+│   │       ├── 2026-03-03/   # 当日完整会话
+│   │       └── 2026-03-03-sessions.tar.gz
+│   ├── tasks/                # 任务记录
+│   │   ├── completed/        # 已完成任务
+│   │   └── failed/           # 失败任务
+│   ├── browser/              # 浏览器操作记录
+│   │   ├── screenshots/      # 网页截图
+│   │   └── page-dumps/       # 页面快照
+│   └── files/                # 文件操作日志
+├── outputs/                   # 输出类数据
+│   ├── generated/            # AI 生成的文档
+│   ├── exports/              # 导出文件
+│   └── reports/              # 定时报告
+└── logs/                      # 日志类
+    ├── system/               # 系统日志 (archive-YYYY-MM-DD.log)
+    ├── model/                # 模型调用记录
+    └── errors/               # 错误日志
+```
+
+### 自动归档脚本
+
+创建 `/root/.openclaw/workspace/archive-daily.sh`：
+
+```bash
+#!/bin/bash
+WORKSPACE="/root/.openclaw/workspace"
+SESSIONS_DIR="/home/node/.openclaw/agents/main/sessions"
+DATE=$(date +"%Y-%m-%d")
+MONTH=$(date +"%Y-%m")
+
+# 创建归档目录
+mkdir -p "$WORKSPACE/records/conversations/$MONTH/$DATE"
+mkdir -p "$WORKSPACE/memory/daily"
+
+# 归档会话文件
+if [ -d "$SESSIONS_DIR" ]; then
+    cp "$SESSIONS_DIR"/*.jsonl "$WORKSPACE/records/conversations/$MONTH/$DATE/" 2>/dev/null || true
+    SESSION_COUNT=$(ls -1 "$SESSIONS_DIR"/*.jsonl 2>/dev/null | wc -l)
+    SIZE=$(du -sb "$SESSIONS_DIR" 2>/dev/null | cut -f1)
+else
+    SESSION_COUNT=0
+    SIZE=0
+fi
+
+# 生成每日摘要 Markdown
+cat > "$WORKSPACE/memory/daily/${DATE}.md" << DAILYMD
+---
+date: ${DATE}
+type: daily-summary
+sessions_count: ${SESSION_COUNT}
+sessions_size_kb: $((${SIZE} / 1024))
+---
+
+# 📅 ${DATE} 对话摘要
+
+## 📊 今日统计
+- **日期**: ${DATE}
+- **星期**: $(date +%A)
+- **会话数**: ${SESSION_COUNT}
+- **数据大小**: $((${SIZE} / 1024)) KB
+
+## 🏷️ 重要标签
+- 
+
+## 💡 今日收获
+- 
+
+## 📌 待办事项
+- [ ] 
+
+---
+DAILYMD
+
+# 记录归档日志
+echo "[$(date)] 归档完成: ${DATE}, ${SESSION_COUNT} 个会话" >> "$WORKSPACE/logs/system/archive-${DATE}.log"
+```
+
+赋予执行权限：
+
+```bash
+chmod +x /root/.openclaw/workspace/archive-daily.sh
+```
+
+### 配置定时任务
+
+添加每天 23:00 自动执行归档：
+
+```bash
+# 添加定时任务
+(crontab -l 2>/dev/null | grep -v archive-daily; echo "0 23 * * * /root/.openclaw/workspace/archive-daily.sh >> /root/.openclaw/workspace/logs/system/cron.log 2>&1") | crontab -
+
+# 查看已配置的定时任务
+crontab -l
+```
+
+### 快捷命令配置
+
+创建 `/root/.openclaw/.aliases.sh`，方便快速查看记录：
+
+```bash
+# 查看今日记录
+alias oc-today='cat /root/.openclaw/workspace/memory/daily/$(date +%Y-%m-%d).md 2>/dev/null || echo "今日记录不存在"'
+
+# 查看昨日记录
+alias oc-yesterday='cat /root/.openclaw/workspace/memory/daily/$(date -d yesterday +%Y-%m-%d 2>/dev/null || date -v-1d +%Y-%m-%d).md 2>/dev/null || echo "昨日记录不存在"'
+
+# 手动执行归档
+alias oc-archive='/root/.openclaw/workspace/archive-daily.sh'
+
+# 查看统计
+alias oc-stats='echo "=== OpenClaw 统计 ===" && echo "会话文件: $(ls -1 /home/node/.openclaw/agents/main/sessions/*.jsonl 2>/dev/null | wc -l)" && echo "每日摘要: $(ls -1 /root/.openclaw/workspace/memory/daily/*.md 2>/dev/null | wc -l)"'
+
+# 查看目录大小
+alias oc-size='du -sh /root/.openclaw/workspace/*/ 2>/dev/null | sort -h'
+```
+
+使用方法：
+
+```bash
+# 加载快捷命令
+source /root/.openclaw/.aliases.sh
+
+# 查看今日记录
+oc-today
+
+# 手动归档
+oc-archive
+
+# 查看统计
+oc-stats
+```
+
+### Docker 容器内配置
+
+为了让 OpenClaw Bot 也能执行归档，在 Docker 容器内创建归档脚本：
+
+```bash
+# 在容器内创建归档命令
+docker exec openclaw-openclaw-gateway-1 bash -c 'cat > /tmp/oc-archive.sh << "EOF"
+#!/bin/bash
+WORKSPACE="/home/node/.openclaw/workspace"
+SESSIONS="/home/node/.openclaw/agents/main/sessions"
+DATE=$(date +"%Y-%m-%d")
+MONTH=$(date +"%Y-%m")
+mkdir -p "$WORKSPACE/records/conversations/$MONTH/$DATE"
+COUNT=0
+if [ -d "$SESSIONS" ]; then
+  cp "$SESSIONS"/*.jsonl "$WORKSPACE/records/conversations/$MONTH/$DATE/" 2>/dev/null || true
+  COUNT=$(ls -1 "$SESSIONS"/*.jsonl 2>/dev/null | wc -l)
+fi
+cat > "$WORKSPACE/memory/daily/$DATE.md" << DAILY
+---
+date: $DATE
+type: daily-summary
+sessions_count: $COUNT
+---
+
+# 📅 $DATE 对话摘要
+
+## 📊 统计
+- 会话数: $COUNT
+
+## 🏷️ 标签
+- 
+
+## 💡 收获
+- 
+DAILY
+echo "✅ 归档完成: $DATE, $COUNT 个会话"
+EOF
+chmod +x /tmp/oc-archive.sh'
+```
+
+### Telegram Bot 使用
+
+配置完成后，你可以直接在 Telegram 中对 Bot 发送：
+
+| 指令 | 功能 |
+|------|------|
+| "归档今天的对话" | 手动触发归档 |
+| "查看今天的记录" | 显示今日摘要 |
+| "查看昨天的记录" | 显示昨日摘要 |
+| "统计我的对话数量" | 显示统计报告 |
+
+### 每日摘要示例
+
+生成的 Markdown 文件 (`memory/daily/2026-03-03.md`)：
+
+```markdown
+---
+date: 2026-03-03
+type: daily-summary
+sessions_count: 5
+sessions_size_kb: 45
+---
+
+# 📅 2026-03-03 对话摘要
+
+## 📊 今日统计
+- **日期**: 2026-03-03
+- **星期**: Tuesday
+- **会话数**: 5
+- **数据大小**: 45 KB
+
+## 🏷️ 重要标签
+- OpenClaw 配置
+- 技能开发
+
+## 💡 今日收获
+- 配置了自动归档系统
+- 解决了会话文件膨胀问题
+
+## 📌 待办事项
+- [ ] 测试归档功能
+- [ ] 配置 Web 画廊
+```
+
+这种结构化的记录管理方式，让你可以：
+1. **快速回顾** - 每天打开 Markdown 文件即可看到当日概况
+2. **防止膨胀** - 自动归档避免会话文件无限增长
+3. **便于导出** - 重要记录可以轻松导出分享
+4. **Telegram 管理** - 直接通过 Bot 指令管理记录
+
+---
+
+## 进阶玩法：自定义 Skill（第10步）
+
+OpenClaw 的 Skill 系统让你可以扩展 AI 的能力。我把自己的 Hexo 博客做成了 Skill，让 Bot 可以直接帮我创建博客文章。
+
+### 我的 Hexo 博客 Skill
+
+#### 1. 创建脚本
+
+在服务器上创建文章生成脚本 `/opt/hexo-blog/create-post.sh`：
+
+```bash
+#!/bin/bash
+# Hexo Blog Post Creator
+
+BLOG_DIR="/opt/hexo-blog"
+POSTS_DIR="$BLOG_DIR/source/_posts"
+
+# 参数
+TITLE="${1:-新建文章}"
+CATEGORY="${2:-随笔}"
+TAGS="${3:-日常}"
+DATE=$(date +"%Y-%m-%d %H:%M:%S")
+FILENAME=$(echo "$TITLE" | sed 's/ /-/g' | tr '[:upper:]' '[:lower:]')-$(date +"%Y%m%d").md
+
+# 创建目录
+mkdir -p "$POSTS_DIR"
+
+# 创建文章
+cat > "$POSTS_DIR/$FILENAME" << EOF
+---
+title: $TITLE
+author: Gamehu
+date: $DATE
+tags:
+EOF
+
+# 添加标签
+IFS=',' read -ra TAG_ARRAY <<< "$TAGS"
+for tag in "${TAG_ARRAY[@]}"; do
+    echo "  - $(echo $tag | xargs)" >> "$POSTS_DIR/$FILENAME"
+done
+
+# 添加分类和正文
+cat >> "$POSTS_DIR/$FILENAME" << EOF
+categories:
+  - $CATEGORY
+---
+
+## 写在前面
+
+$TITLE
+
+<!-- more -->
+
+## 正文
+
+开始写作...
+
+---
+EOF
+
+echo "✅ 文章创建成功: $POSTS_DIR/$FILENAME"
+```
+
+赋予执行权限：
+
+```bash
+chmod +x /opt/hexo-blog/create-post.sh
+```
+
+#### 2. 创建 Skill 文件
+
+OpenClaw 使用 `SKILL.md` 文件（不是 YAML），创建 `~/.openclaw/skills/hexo-blog/SKILL.md`：
+
+```markdown
+---
+name: hexo-blog
+description: Create and manage Hexo blog posts via shell script
+---
+
+# Hexo Blog Skill
+
+Create new blog posts with proper front matter for Hexo.
+
+## Usage
+
+Ask me to create a blog post:
+- "帮我创建一篇博客文章，标题是《XXX》，分类是技术，标签是 OpenClaw,AI"
+- "写一篇新文章，关于 Docker 使用心得"
+
+## Tools
+
+This skill uses the `shell` tool to execute `/opt/hexo-blog/create-post.sh`.
+
+## Example
+
+```bash
+/opt/hexo-blog/create-post.sh "文章标题" "分类" "标签1,标签2"
+```
+```
+
+#### 3. 重启 OpenClaw 加载 Skill
+
+```bash
+docker restart openclaw-openclaw-gateway-1
+```
+
+验证 Skill 是否加载：
+
+```bash
+openclaw skills list
+# 应该显示: ✓ ready │ 📦 hexo-blog │ Create and manage Hexo blog posts...
+```
+
+#### 3. 实际使用
+
+在 **@gamehu_kb_bot** 里直接说：
+
+> "帮我创建一篇博客文章，标题是《OpenClaw 使用心得》，分类是工具，标签是 OpenClaw,AI"
+
+Bot 会自动：
+1. 生成文件名 `openclaw-shi-yong-xin-de-20260302.md`
+2. 创建带完整 Front Matter 的 Markdown 文件
+3. 返回文件路径
+
+### Skill 核心概念
+
+| 组件 | 作用 | 示例 |
+|------|------|------|
+| **Script** | 执行实际任务 | Shell/Python 脚本 |
+| **SKILL.md** | Skill 定义和说明 | Markdown 文件（带 YAML frontmatter） |
+| **Directory** | Skill 存放位置 | `~/.openclaw/skills/<skill-name>/` |
+
+### 更多 Skill 想法
+
+- **Git Helper**: 自动提交、查看状态、创建分支
+- **Docker Manager**: 查看容器日志、重启服务
+- **File Organizer**: 整理下载文件夹、重命名文件
+- **Daily Reporter**: 生成每日工作总结
+
+---
+
+## 进阶玩法：浏览器控制（第12步）
+
+OpenClaw 内置了浏览器控制功能，让 AI 能够**操作真实浏览器**执行网页任务，比如搜索信息、填写表单、抓取数据等。
+
+<span class="warning">🚨 坑位 14：Docker 镜像默认不包含浏览器</span>
+
+### 问题
+
+Docker 部署后尝试使用浏览器功能时，报错：
+```
+[tools] browser failed: Error: No supported browser found 
+(Chrome/Brave/Edge/Chromium on macOS, Linux, or Windows).
+```
+
+### 原因
+
+默认的 `Dockerfile` 不会安装 Chromium/Playwright 浏览器，需要通过 `--build-arg OPENCLAW_INSTALL_BROWSER=1` 参数构建带浏览器的镜像。
+
+### 解决方案：重新构建带浏览器的镜像
+
+#### 1. 停止当前服务
+
+```bash
+cd /opt/openclaw
+docker compose down
+```
+
+#### 2. 构建带浏览器的新镜像
+
+```bash
+# 构建时间约 15-30 分钟，增加约 300MB
+docker build -t openclaw:local-browser -f Dockerfile \
+  --build-arg OPENCLAW_INSTALL_BROWSER=1 \
+  --build-arg OPENCLAW_DOCKER_APT_PACKAGES="chromium xvfb" \
+  .
+```
+
+#### 3. 修改环境变量使用新镜像
+
+编辑 `.env` 文件：
+```bash
+# 修改前
+OPENCLAW_IMAGE=openclaw:local
+
+# 修改后
+OPENCLAW_IMAGE=openclaw:local-browser
+```
+
+#### 4. 启动服务
+
+```bash
+docker compose up -d
+```
+
+#### 5. 验证浏览器安装
+
+```bash
+# 进入容器检查
+docker exec openclaw-openclaw-gateway-1 \
+  ls -la /home/node/.cache/ms-playwright/
+
+# 应该看到：
+# chromium-1208/
+# chromium_headless_shell-1208/
+# ffmpeg-1011/
+```
+
+### 浏览器控制功能
+
+| 功能 | 说明 |
+|------|------|
+| **网页浏览** | 访问指定 URL，获取页面内容 |
+| **表单填写** | 自动填写并提交网页表单 |
+| **信息搜索** | 在搜索引擎或电商网站搜索 |
+| **数据抓取** | 提取网页中的结构化数据 |
+| **截图保存** | 截取网页画面 |
+
+### 使用示例
+
+在 Telegram 中直接发送以下指令：
+
+**搜索信息**：
+> "打开浏览器，访问 GitHub，搜索 'openclaw'，告诉我前 3 个结果"
+
+**商品比价**：
+> "帮我在京东上搜索 '机械键盘'，找到评分最高的 3 个产品，记录价格"
+
+**数据抓取**：
+> "访问 https://news.ycombinator.com/，提取首页前 10 条新闻的标题和链接"
+
+### 浏览器控制原理
+
+```
+用户指令 → OpenClaw Agent → 浏览器控制服务 → 无头 Chrome → 网页操作 → 结果返回
+```
+
+浏览器控制服务默认监听：`http://127.0.0.1:18791/`
+
+### 注意事项
+
+1. **无头模式**：Docker 部署默认使用 headless 模式（无界面），适合服务器环境
+2. **访问限制**：受限于服务器网络，无法访问需要登录的页面（除非提供 Cookie）
+3. **执行时间**：复杂页面加载可能需要 10-30 秒
+4. **安全提醒**：避免让 Bot 访问敏感网站或输入真实账号密码
+
+### 实践任务
+
+尝试让 Bot 完成以下任务：
+- ✅ 信息收集：从某个网站抓取数据并整理
+- ✅ 表单填写：自动填写一个在线表单
+- ✅ 价格比较：在多个网站比较同一商品的价格
+
+---
+
+## 进阶玩法：多 Bot 配置（第11步）
+
+OpenClaw 支持配置**多个 Telegram Bot**，每个 Bot 可以绑定不同的 Agent，实现分工协作。  
+注意：仅配置 `channels.telegram.accounts` 还不够，想要真正隔离上下文，必须再加 `agents.list + bindings`。
+
+### 我的多 Bot 架构
+
+| Bot | 用户名 | 职责 | 对应 Agent |
+|-----|--------|------|-----------|
+| 主助手 | @GameHuOpenclaw_bot | 通用对话、代码、写作 | main |
+| 新闻助手 | @gamehu_news_bot | 科技新闻、每日简报 | news |
+| 成长助手 | @gamehu_growth_bot | 学习计划、习惯追踪 | growth |
+| 知识库助手 | @gamehu_kb_bot | 文档查询、笔记整理 | kb |
+
+### 配置步骤
+
+#### 1. 在 @BotFather 创建多个 Bot
+
+每个 Bot 都需要独立的 Token：
+
+```
+/main_bot - 主助手
+/news_bot - 新闻助手  
+/growth_bot - 成长助手
+/kb_bot - 知识库助手
+```
+
+#### 2. 配置多账号
+
+```json
+{
+  "channels": {
+    "telegram": {
+      "enabled": true,
+      "accounts": {
+        "main": {
+          "botToken": "YOUR_MAIN_BOT_TOKEN",
+          "allowFrom": ["YOUR_TELEGRAM_USER_ID"]
+        },
+        "news": {
+          "botToken": "YOUR_NEWS_BOT_TOKEN",
+          "allowFrom": ["YOUR_TELEGRAM_USER_ID"]
+        },
+        "growth": {
+          "botToken": "YOUR_GROWTH_BOT_TOKEN",
+          "allowFrom": ["YOUR_TELEGRAM_USER_ID"]
+        },
+        "kb": {
+          "botToken": "YOUR_KB_BOT_TOKEN",
+          "allowFrom": ["YOUR_TELEGRAM_USER_ID"]
+        }
+      }
+    }
+  }
+}
+```
+
+#### 3. 增加 Agent 路由绑定（关键）
+
+```json
+{
+  "agents": {
+    "list": [
+      { "id": "main",   "default": true, "workspace": "/home/node/.openclaw/workspace" },
+      { "id": "news",   "workspace": "/home/node/.openclaw/workspace-news" },
+      { "id": "growth", "workspace": "/home/node/.openclaw/workspace-growth" },
+      { "id": "kb",     "workspace": "/home/node/.openclaw/workspace-kb" }
+    ]
+  },
+  "bindings": [
+    { "agentId": "main",   "match": { "channel": "telegram", "accountId": "main" } },
+    { "agentId": "news",   "match": { "channel": "telegram", "accountId": "news" } },
+    { "agentId": "growth", "match": { "channel": "telegram", "accountId": "growth" } },
+    { "agentId": "kb",     "match": { "channel": "telegram", "accountId": "kb" } }
+  ]
+}
+```
+
+> ⚠️ **`workspace` 字段必须显式指定**：每个 agent 需要独立的 workspace 路径，否则多个 agent 共享同一个 workspace，记忆和配置会互相干扰。
+
+这样每个 bot 会落到不同 agent，会话文件分目录保存，记忆文件也完全隔离。
+
+#### 4. 为每个 Agent 创建独立 Workspace
+
+每个 agent 对应一个独立目录，在服务器上创建：
+
+```bash
+mkdir -p /root/.openclaw/workspace-news
+mkdir -p /root/.openclaw/workspace-growth
+mkdir -p /root/.openclaw/workspace-kb
+```
+
+每个目录下的结构：
+
+```bash
+workspace-news/
+├── SOUL.md        # Agent 的身份定义
+├── MEMORY.md      # 长期记忆
+├── USER.md        # 用户信息
+├── AGENTS.md      # Agent 行为规范
+└── memory/        # 每日记忆文件
+```
+
+每个 `AGENT.md` 定义该 Bot 的专业领域和行为：
+
+```markdown
+# News Agent
+
+## Role
+你是一个科技新闻助手，专注于提供最新、最有价值的科技资讯。
+
+## Capabilities
+- 追踪科技行业动态
+- 总结技术文章要点
+- 提供每日新闻简报
+
+## Style
+- 简洁明了，重点突出
+- 提供信息来源链接
+- 主动推送重要消息
+```
+
+#### 4. 重启服务
+
+```bash
+docker compose restart
+```
+
+查看日志确认所有 Bot 启动：
+
+```
+[telegram] [main] starting provider (@GameHuOpenclaw_bot)
+[telegram] [news] starting provider (@gamehu_news_bot)
+[telegram] [growth] starting provider (@gamehu_growth_bot)
+[telegram] [kb] starting provider (@gamehu_kb_bot)
+```
+
+### 实际使用效果
+
+- **上下文隔离**：在 @gamehu_growth_bot 聊学习计划，切到 @gamehu_news_bot 问新闻，再回到 growth Bot，它还记得刚才的学习话题
+- **专业化分工**：每个 Bot 专注于自己的领域，回复质量更高
+- **并行对话**：可以同时和多个 Bot 对话，互不干扰
+
+<span class="warning">⚠️ 注意事项</span>
+
+- 多账号配置时，**不要**在顶层设置 `botToken`，全部放在 `accounts` 下
+- 每个 `accountId`（如 main、news、growth、kb）必须是唯一的
+- 账号名不要用 `default`，会和系统默认账号冲突
+
+---
+
+## 进阶玩法：定时任务推送到指定 Bot（第11.5步）
+
+配置好多 Bot 之后，你可能会发现一个问题：**OpenClaw 里设置的定时任务（cron job），推送结果全都跑到了 main bot，而不是对应的 bot**。
+
+<span class="warning">🚨 坑位 17：定时任务 delivery 缺少 accountId</span>
+
+### 问题现象
+
+在 OpenClaw Web UI 里配了新闻推送任务，时间一到，消息却出现在了 @GameHuOpenclaw_bot（main bot），而不是 @gamehu_news_bot。
+
+### 根本原因
+
+OpenClaw 的定时任务存储在 `~/.openclaw/cron/jobs.json`，每个任务的 `delivery` 字段控制推送目标。**如果只写了 `to`（用户 ID），没有写 `accountId`，OpenClaw 不知道用哪个 bot 账户推送，默认走 main。**
+
+另外，`to` 只负责“推给谁”（用户 / 群 / 频道），`accountId` 负责“用哪个 bot 发”。这两个字段职责不同，缺一不可。
+
+**有问题的配置：**
+
+```json
+"delivery": {
+  "mode": "announce",
+  "channel": "telegram",
+  "to": "YOUR_USER_ID"
+}
+```
+
+### 解决方案
+
+在每个 job 的 `delivery` 中加上 `accountId`，同时在 job 顶层加上 `agentId`。建议把执行超时提到 120 秒（字段 `timeoutSeconds`）：
+
+```json
+{
+  "id": "xxx",
+  "agentId": "news",
+  "name": "每日新闻推送",
+  "timeoutSeconds": 120,
+  "payload": {
+    "kind": "agentTurn",
+    "message": "执行新闻脚本并发送结果给用户"
+  },
+  "delivery": {
+    "mode": "announce",
+    "channel": "telegram",
+    "accountId": "news",
+    "to": "YOUR_USER_ID"
+  }
+}
+```
+
+### 推送目标的两种正确姿势
+
+#### 方案 A（推荐）：同一个用户，按不同 Bot 身份推送
+
+这种方式最适合你当前“4 个 Bot 各司其职”的场景。`to` 全部写你的用户 ID，`accountId` 分别写 `main/news/growth/kb`，消息会显示来自对应 bot。
+
+```json
+{
+  "agentId": "news",
+  "timeoutSeconds": 120,
+  "delivery": {
+    "mode": "announce",
+    "channel": "telegram",
+    "accountId": "news",
+    "to": "YOUR_USER_ID"
+  }
+}
+```
+
+#### 方案 B：推送到群 / 频道 / 话题
+
+如果要发到频道，不要填 bot 用户名（如 `@gamehu_news_bot`），而是填频道 chat id（通常是 `-100...`）。并确保对应 bot 已加入目标群/频道且有发言权限。
+
+```json
+{
+  "agentId": "news",
+  "timeoutSeconds": 120,
+  "delivery": {
+    "mode": "announce",
+    "channel": "telegram",
+    "accountId": "news",
+    "to": "-1001234567890"
+  }
+}
+```
+
+### 各任务对应关系
+
+| 任务 | agentId | accountId | 推送到 |
+|------|---------|-----------|--------|
+| 每日新闻推送 | news | news | @gamehu_news_bot |
+| 每日成长提醒 | growth | growth | @gamehu_growth_bot |
+| 每周知识库总结 | kb | kb | @gamehu_kb_bot |
+| 其他通用任务 | main | main | @GameHuOpenclaw_bot |
+
+修改完 `jobs.json` 后重启服务即可生效：
+
+```bash
+cd /opt/openclaw && docker compose restart
+```
+
+---
+
+## 进阶玩法：接入 Step-3.5-Flash，并支持会话级切换（第11.6步）
+
+最近我把底层模型又补了一档：`Step-3.5-Flash`。但这里有个非常容易搞混的点，我一开始也踩了坑：
+
+<span class="warning">🚨 坑位 18：想要“随时切模型”，不等于要改全局默认模型</span>
+
+如果你直接把 `agents.defaults.model.primary` 全局切到 Step，看起来省事，实际上会把别的会话、别的 Bot，甚至定时任务一起带偏。  
+更稳的做法是：
+
+- **全局默认模型继续保持不变**，我这里还是 `bailian/kimi-k2.5`
+- 把 `step/step-3.5-flash` 注册成一个**可选 provider**
+- 需要的时候，直接在 **当前 Telegram 会话** 里发送 `/model ...` 切换
+
+### Step provider 配置示例
+
+```json
+{
+  "models": {
+    "mode": "merge",
+    "providers": {
+      "bailian": {
+        "baseUrl": "https://coding.dashscope.aliyuncs.com/v1",
+        "apiKey": "YOUR_BAILIAN_API_KEY",
+        "api": "openai-completions",
+        "models": [
+          {
+            "id": "kimi-k2.5",
+            "name": "kimi-k2.5",
+            "contextWindow": 256000,
+            "maxTokens": 8192
+          }
+        ]
+      },
+      "kimi": {
+        "baseUrl": "https://api.moonshot.cn/v1",
+        "apiKey": "YOUR_KIMI_API_KEY",
+        "api": "openai-completions",
+        "models": [
+          {
+            "id": "moonshot-v1-128k",
+            "name": "moonshot-v1-128k",
+            "contextWindow": 131072,
+            "maxTokens": 8192
+          }
+        ]
+      },
+      "step": {
+        "baseUrl": "https://api.stepfun.com/v1",
+        "apiKey": "YOUR_STEP_API_KEY",
+        "api": "openai-completions",
+        "models": [
+          {
+            "id": "step-3.5-flash",
+            "name": "Step 3.5 Flash",
+            "contextWindow": 256000,
+            "maxTokens": 8192
+          }
+        ]
+      }
+    }
+  },
+  "agents": {
+    "defaults": {
+      "model": {
+        "primary": "bailian/kimi-k2.5"
+      },
+      "contextTokens": 131072
+    }
+  }
+}
+```
+
+### 为什么我把 `contextTokens` 调到 131072
+
+这不是说 `kimi-k2.5` 或 `step-3.5-flash` 只能吃 128k，而是为了兼容我现在保留的第三档模型 `moonshot-v1-128k`。
+
+如果你想做到：
+- 默认走百炼
+- 需要时切 Step
+- 偶尔还能切回 Moonshot 做速度/成本对比
+
+那最稳的双档/三档基线，就是把 `contextTokens` 先压在 **131072**。这样：
+
+- `bailian <-> step` 切换时，几乎不会因为窗口变化引发额外压缩
+- 切到 `moonshot-v1-128k` 时，也不会立刻超限
+
+### 当前会话切换命令
+
+直接在 Telegram 里发：
+
+```text
+/models
+/models step
+/model status
+/model step
+/model bailian/kimi-k2.5
+/model kimi/moonshot-v1-128k
+```
+
+这里要强调 3 个边界：
+
+1. **只影响当前会话**
+2. **不会清空 SOUL.md / MEMORY.md / USER.md / AGENTS.md**
+3. **不会影响 cron 定时任务**
+
+也就是说，这种切换本质上是“会话级模型覆盖”，不是“全局改配置”。
+
+### 切模型会不会丢上下文
+
+长期记忆不会丢，工作区画像也不会丢。真正会受影响的是**短期上下文压缩**：
+
+- 从 `bailian/kimi-k2.5` 切到 `step/step-3.5-flash`，因为两边都是大窗口，风险很低
+- 从 `bailian` 或 `step` 切到 `moonshot-v1-128k`，因为窗口更小，下一轮可能触发更激进的 compaction
+
+所以我现在的原则很简单：
+
+- 平时默认：`bailian/kimi-k2.5`
+- 需要测试 Step：`/model step`
+- 需要切回稳定默认：`/model bailian/kimi-k2.5`
+- 需要做小窗口对比：`/model kimi/moonshot-v1-128k`
+
+> ⚠️ 如果你想支持“切换模型 step”这种中文自然语言，而不是 `/model step`，那是另外一层 parser 改造，不是 OpenClaw 开箱即用能力。
+
+---
+
+## 完整配置文件参考
+
+**openclaw.json**（多 Bot 生产版本，已脱敏，包含 compaction 修复）：
+
+```json
+{
+  "gateway": {
+    "port": 18789,
+    "mode": "local",
+    "controlUi": {
+      "allowedOrigins": ["http://localhost:18789", "http://127.0.0.1:18789"]
+    },
+    "auth": {
+      "token": "your-secure-token-here"
+    }
+  },
+  "models": {
+    "mode": "merge",
+    "providers": {
+      "bailian": {
+        "baseUrl": "https://coding.dashscope.aliyuncs.com/v1",
+        "apiKey": "YOUR_BAILIAN_API_KEY",
+        "api": "openai-completions",
+        "models": [
+          {
+            "id": "kimi-k2.5",
+            "name": "kimi-k2.5",
+            "reasoning": false,
+            "input": ["text", "image"],
+            "cost": { "input": 0, "output": 0, "cacheRead": 0, "cacheWrite": 0 },
+            "contextWindow": 256000,
+            "maxTokens": 8192
+          }
+        ]
+      },
+      "kimi": {
+        "baseUrl": "https://api.moonshot.cn/v1",
+        "apiKey": "YOUR_KIMI_API_KEY",
+        "api": "openai-completions",
+        "models": [
+          {
+            "id": "moonshot-v1-128k",
+            "name": "moonshot-v1-128k",
+            "reasoning": false,
+            "input": ["text", "image"],
+            "cost": { "input": 0, "output": 0, "cacheRead": 0, "cacheWrite": 0 },
+            "contextWindow": 131072,
+            "maxTokens": 8192
+          }
+        ]
+      },
+      "step": {
+        "baseUrl": "https://api.stepfun.com/v1",
+        "apiKey": "YOUR_STEP_API_KEY",
+        "api": "openai-completions",
+        "models": [
+          {
+            "id": "step-3.5-flash",
+            "name": "Step 3.5 Flash",
+            "reasoning": false,
+            "input": ["text", "image"],
+            "cost": { "input": 0, "output": 0, "cacheRead": 0, "cacheWrite": 0 },
+            "contextWindow": 256000,
+            "maxTokens": 8192
+          }
+        ]
+      }
+    }
+  },
+  "agents": {
+    "defaults": {
+      "model": {
+        "primary": "bailian/kimi-k2.5"
+      },
+      "contextTokens": 131072,
+      "compaction": {
+        "mode": "safeguard",
+        "reserveTokensFloor": 24000,
+        "identifierPolicy": "strict",
+        "memoryFlush": {
+          "enabled": true,
+          "softThresholdTokens": 6000
+        }
+      }
+    },
+    "list": [
+      { "id": "main", "default": true },
+      { "id": "news" },
+      { "id": "growth" },
+      { "id": "kb" }
+    ]
+  },
+  "bindings": [
+    { "agentId": "main", "match": { "channel": "telegram", "accountId": "main" } },
+    { "agentId": "news", "match": { "channel": "telegram", "accountId": "news" } },
+    { "agentId": "growth", "match": { "channel": "telegram", "accountId": "growth" } },
+    { "agentId": "kb", "match": { "channel": "telegram", "accountId": "kb" } }
+  ],
+  "session": {
+    "scope": "per-sender",
+    "reset": {
+      "mode": "idle",
+      "idleMinutes": 30
+    },
+    "maintenance": {
+      "mode": "enforce",
+      "pruneAfter": "7d",
+      "maxEntries": 120
+    }
+  },
+  "channels": {
+    "telegram": {
+      "enabled": true,
+      "dmPolicy": "pairing",
+      "groupPolicy": "allowlist",
+      "historyLimit": 30,
+      "accounts": {
+        "main": {
+          "botToken": "YOUR_MAIN_BOT_TOKEN",
+          "allowFrom": ["YOUR_TELEGRAM_USER_ID"],
+          "dmPolicy": "pairing",
+          "groupPolicy": "allowlist",
+          "streaming": "off"
+        },
+        "news": {
+          "botToken": "YOUR_NEWS_BOT_TOKEN",
+          "allowFrom": ["YOUR_TELEGRAM_USER_ID"],
+          "dmPolicy": "pairing",
+          "groupPolicy": "allowlist",
+          "streaming": "off"
+        },
+        "growth": {
+          "botToken": "YOUR_GROWTH_BOT_TOKEN",
+          "allowFrom": ["YOUR_TELEGRAM_USER_ID"],
+          "dmPolicy": "pairing",
+          "groupPolicy": "allowlist",
+          "streaming": "off"
+        },
+        "kb": {
+          "botToken": "YOUR_KB_BOT_TOKEN",
+          "allowFrom": ["YOUR_TELEGRAM_USER_ID"],
+          "dmPolicy": "pairing",
+          "groupPolicy": "allowlist",
+          "streaming": "off"
+        }
+      }
+    }
+  }
+}
+```
+
+> ⚠️ **关键提示**：
+> 1. 如果你保留多档模型可切换，`contextTokens` 不要盲目拉满；我现在用 `131072` 作为三档模型共存时的安全基线。
+> 2. **浏览器功能**：默认镜像不包含 Chromium，需要使用 `--build-arg OPENCLAW_INSTALL_BROWSER=1` 构建 `openclaw:local-browser` 镜像
+> 3. 多 Bot 场景必须配置 `bindings`，否则 direct chat 默认会落到主会话桶，容易串上下文。
+> 4. 如果你临时切到 `moonshot-v1-128k`，继续保持 `contextTokens <= 131072`，避免再次出现 compaction 超限。
+
+**单 Bot 简化版（含 compaction 修复）：**
+
+```json
+{
+  "gateway": {
+    "port": 18789,
+    "mode": "local",
+    "controlUi": {
+      "allowedOrigins": ["http://localhost:18789", "http://127.0.0.1:18789"]
+    },
+    "auth": {
+      "token": "your-secure-token"
+    }
+  },
+  "models": {
+    "providers": {
+      "bailian": {
+        "baseUrl": "https://coding.dashscope.aliyuncs.com/v1",
+        "apiKey": "YOUR_API_KEY",
+        "models": [{
+          "id": "kimi-k2.5",
+          "contextWindow": 256000,
+          "maxTokens": 8192
+        }]
+      }
+    }
+  },
+  "agents": {
+    "defaults": {
+      "model": { "primary": "bailian/kimi-k2.5" },
+      "contextTokens": 131072,
+      "compaction": {
+        "mode": "safeguard",
+        "reserveTokensFloor": 24000
+      }
+    }
+  },
+  "session": {
+    "reset": {
+      "mode": "idle",
+      "idleMinutes": 30
+    },
+    "maintenance": {
+      "mode": "enforce",
+      "pruneAfter": "7d",
+      "maxEntries": 120
+    }
+  },
+  "channels": {
+    "telegram": {
+      "enabled": true,
+      "historyLimit": 30,
+      "botToken": "YOUR_BOT_TOKEN",
+      "allowFrom": ["YOUR_USER_ID"]
+    }
+  }
+}
+```
+
+---
+
+## 踩坑总结
+
+| 坑位 | 问题 | 解决方案 |
+|------|------|----------|
+| 1 | 构建时 OOM | 添加 5GB Swap 空间 |
+| 2 | `gateway.mode` 缺失 | 必须显式设置 `"mode": "local"` |
+| 3 | `controlUi.allowedOrigins` 缺失 | 非 localhost 绑定时必须配置 |
+| 4 | `gateway.bind` 配置无效 | 必须使用 CLI 参数 `--bind lan` |
+| 5 | Telegram 配对失败 | 删除 `dmPolicy`，使用 `allowFrom` 白名单 |
+| 6 | 防火墙不生效 | 使用 `DOCKER-USER` 链而非 `INPUT` 链 |
+| 7 | Google OAuth 授权失败 | 确保 Redirect URI 与配置完全一致 |
+| 8 | MCP 服务器无法启动 | 检查 npx 是否可用，网络是否通畅 |
+| 9 | 多 Bot 配置时 `default` 账号冲突 | 避免使用 `default` 作为 accountId，改用 `main`、`news` 等 |
+| 10 | 多 Bot 顶层 `botToken` 被覆盖 | 使用 `accounts` 时，顶层不要设置 `botToken` |
+| 11 | Skill 脚本权限不足 | 确保脚本有执行权限 `chmod +x script.sh` |
+| 12 | Skill 中文字符处理 | 使用 `echo | sed` 处理中文文件名，避免乱码 |
+| 13 | Compaction 卡死导致无响应 | 配置合理 `contextTokens` + 设置 `historyLimit` + 启用 `session.maintenance` |
+| 14 | Docker 镜像无浏览器 | 使用 `--build-arg OPENCLAW_INSTALL_BROWSER=1` 重新构建镜像 |
+| 15 | 镜像体积过大 (5.7GB) | 使用多阶段构建 + node:22-bookworm-slim 基础镜像 |
+| 16 | 会话记录膨胀失控 | 部署结构化记录系统 + 每日自动归档 + 分类存储 |
+| 17 | 定时任务推送全到 main bot | `jobs.json` 每个 job 加 `agentId` + `delivery.accountId` |
+| 18 | 想切 Step 却误改全局默认模型 | 保持默认模型不动，使用 `/model ...` 做会话级切换 |
+
+---
+
+## 镜像优化指南（第15坑）
+
+### 问题：镜像体积过大
+
+OpenClaw 默认构建的镜像体积巨大：
+- `openclaw:local`: **4.4GB**
+- `openclaw:local-browser`: **5.7GB**
+
+在 2GB 内存的服务器上，光是镜像就占满了磁盘。
+
+### 原因分析
+
+| 问题 | 说明 | 占用 |
+|------|------|------|
+| **单阶段构建** | 构建依赖和生产代码混在一起 | ~1GB |
+| **未清理 devDependencies** | 开发依赖未删除 | ~500MB |
+| **bookworm 基础镜像** | 完整 Debian 系统 | ~1GB |
+| **Chromium + Playwright** | 浏览器全套 | ~1.7GB |
+
+### 解决方案：多阶段构建
+
+创建 `Dockerfile.optimized`：
+
+```dockerfile
+# ============================================================================
+# 阶段1：构建阶段
+# ============================================================================
+FROM node:22-bookworm AS builder
+
+WORKDIR /app
+RUN corepack enable
+
+# 复制依赖文件
+COPY package.json pnpm-lock.yaml ./
+RUN pnpm install --frozen-lockfile
+
+# 复制源码并构建
+COPY . .
+RUN pnpm build && pnpm ui:build
+
+# 关键：清理开发依赖，只保留生产依赖
+RUN pnpm prune --prod
+
+# ============================================================================
+# 阶段2：生产阶段 - 使用精简基础镜像
+# ============================================================================
+FROM node:22-bookworm-slim AS production
+
+# 只安装必需的系统依赖
+RUN apt-get update && apt-get install -y --no-install-recommends \
+    ca-certificates curl git \
+    && rm -rf /var/lib/apt/lists/*
+
+WORKDIR /app
+
+# 从构建阶段只复制必要文件
+COPY --from=builder /app/dist ./dist
+COPY --from=builder /app/node_modules ./node_modules
+COPY --from=builder /app/package.json ./
+COPY --from=builder /app/openclaw.mjs ./
+
+# 使用非 root 用户运行
+RUN groupadd -r nodeuser && useradd -r -g nodeuser nodeuser
+RUN chown -R nodeuser:nodeuser /app
+USER nodeuser
+
+ENV NODE_ENV=production
+EXPOSE 18789 18790
+
+CMD ["node", "openclaw.mjs", "gateway", "--allow-unconfigured"]
+```
+
+### 构建优化版镜像
+
+```bash
+cd /opt/openclaw
+
+# 构建轻量级版本 (2-3GB)
+docker build \
+  --target production \
+  -t openclaw:slim \
+  -f Dockerfile.optimized \
+  .
+
+# 构建浏览器版本 (3-4GB)
+docker build \
+  --target browser \
+  -t openclaw:slim-browser \
+  -f Dockerfile.optimized \
+  .
+```
+
+### 优化效果对比
+
+| 镜像 | 原体积 | 优化后 | 节省 |
+|------|--------|--------|------|
+| `openclaw:local` | 4.4GB | `openclaw:slim` **2.5GB** | **43%** ↓ |
+| `openclaw:local-browser` | 5.7GB | `openclaw:slim-browser` **3.5GB** | **39%** ↓ |
+
+### 使用优化版镜像
+
+修改 `.env` 文件：
+
+```bash
+# 轻量级版本（推荐日常使用）
+OPENCLAW_IMAGE=openclaw:slim
+
+# 或浏览器版本（需要网页自动化时）
+# OPENCLAW_IMAGE=openclaw:slim-browser
+```
+
+然后重启服务：
+
+```bash
+docker compose up -d
+```
+
+### 进一步优化建议
+
+1. **使用 Alpine 基础镜像**（极致精简）
+   ```dockerfile
+   FROM node:22-alpine
+   # 可将体积降至 < 1.5GB
+   # 但可能有兼容性问题
+   ```
+
+2. **启用 Docker 镜像压缩**
+   ```bash
+   docker build --compress ...
+   ```
+
+3. **定期清理无用镜像**
+   ```bash
+   docker image prune -a
+   ```
+
+---
+
+## 重大坑位详解：Compaction 卡死问题（第13坑）
+
+部署运行几天后，我遇到了一个**极其隐蔽但致命**的问题：Telegram Bot 突然不响应了，或者响应需要等 5 分钟以上。
+
+### 现象
+
+- 发送消息后 Bot 无响应
+- 日志卡在 `embedded run compaction start` 不动
+- 服务重启后短暂正常，很快又卡死
+
+### 根因分析
+
+深度诊断后发现了**两个根本原因**：
+
+#### 根因 1：contextTokens 不匹配
+
+OpenClaw 默认上下文预算与实际模型窗口不一致时，会导致系统误判可用空间，compaction 后仍然超限（日志显示使用了 145.7%）。
+
+所以一定要注意不同的模型一定要修改响应的配置。
+
+#### 根因 2：无 historyLimit 限制
+
+所有历史消息（603 条）全部进入上下文，而不是只取最近的几十条。两天内会话文件膨胀到 1.4MB，每次 compaction 都要扫描全部历史。
+
+#### 触发因素：输出被频繁截断
+
+`maxTokens` 配得过小会让长任务反复截断并补发，间接加速会话膨胀。它不是唯一根因，但会放大卡顿问题。
+
+### 解决方案
+
+需要添加三组关键配置：
+
+```json
+{
+  "agents": {
+    "defaults": {
+      "contextTokens": 131072,
+      "compaction": {
+        "mode": "safeguard",
+        "reserveTokensFloor": 24000,
+        "identifierPolicy": "strict",
+        "memoryFlush": {
+          "enabled": true,
+          "softThresholdTokens": 6000
+        }
+      }
+    }
+  },
+  "session": {
+    "scope": "per-sender",
+    "reset": {
+      "mode": "idle",
+      "idleMinutes": 30
+    },
+    "maintenance": {
+      "mode": "enforce",
+      "pruneAfter": "7d",
+      "maxEntries": 120
+    }
+  },
+  "channels": {
+    "telegram": {
+      "enabled": true,
+      "historyLimit": 30,
+      "accounts": {
+        ...
+      }
+    }
+  }
+}
+```
+
+### 关键配置说明
+
+| 配置项 | 值 | 作用 |
+|--------|-----|------|
+| `agents.defaults.contextTokens` | 131072 | 多档模型共存时更稳，切回 `moonshot-v1-128k` 也不容易超限 |
+| `agents.defaults.compaction.mode` | safeguard | 启用保护模式，预留安全空间 |
+| `session.maintenance.mode` | enforce | 强制清理 7 天前的旧会话 |
+| `session.maintenance.maxEntries` | 120 | 最多保留 120 个会话 |
+| `channels.telegram.historyLimit` | 30 | 每次请求最多带 30 条历史 |
+
+### 多 Bot 配置注意
+
+上面的 `historyLimit` 和 `session` 配置放在 `channels.telegram` 级别，会对所有 4 个 Bot 统一生效。如果需要不同 Bot 不同策略，可以在每个 `account` 下单独设置 `historyLimit`。
+
+### 多模型切换补充说明
+
+后来我又把 `step/step-3.5-flash` 接进来了。这里最重要的经验是：  
+**别为了切模型去改全局默认模型，直接用 `/model ...` 切当前会话就够了。**
+
+原因很简单：
+- 改全局会影响别的 Bot 和别的会话
+- 还可能把 cron 定时任务一起带偏
+- 当前会话切换则只影响自己这一条对话链
+
+我现在的实际用法：
+
+```text
+/model step
+/model bailian/kimi-k2.5
+/model kimi/moonshot-v1-128k
+/model status
+```
+
+其中：
+- `bailian <-> step` 风险最低
+- 切到 `moonshot-v1-128k` 时，最容易触发短期上下文压缩
+- 但长期记忆文件不会丢
+
+### 修复后的效果
+
+- 响应时间从 5 分钟+ 降至 3-20 秒
+- 会话文件大小控制在 10KB 以内
+- 服务连续运行 14 小时+ 无卡死
+
+---
+
+## 实际使用体验
+
+部署完成后，通过 Telegram 与 Bot 对话：
+
+### 修复前（问题阶段）
+- 响应速度：最初很快，2 天后变成 5 分钟+
+- 稳定性：运行 2 天后完全卡死
+- 原因：compaction 机制被大会话文件阻塞
+
+### 修复后（当前状态）
+- 响应速度：**3-20 秒**，正常可用
+- 稳定性：连续运行 14 小时+ 无故障
+- 内存占用：约 800MB-1.2GB
+- 功能：文件操作、Shell 命令、网页浏览全部正常
+
+### 关键优化点
+
+配置 `contextTokens`、`historyLimit` 和 `session.maintenance` 后，OpenClaw 从"两天必挂"变成"长期稳定运行"。这是生产环境部署的**必选项**，不是可选项。
+
+> 📷 **Telegram 实际对话效果**：
+> 
+> ![Telegram使用效果](/images/openclaw/04-telegram-usage.png)
+
+---
+
+## 安全建议
+
+1. **永远不要**将 `openclaw.json` 提交到 Git
+2. **配置文件权限**：最小权限原则，但必须保证容器运行用户可读
+3. **Web UI 访问**：仅通过 SSH 隧道，不要暴露在公网
+4. **Telegram 白名单**：严格控制 `allowFrom` 列表
+5. **定期更新**：关注 OpenClaw 安全公告
+
+---
+
+## 参考资源
+
+- [OpenClaw 官网](https://openclaw.ai/)
+- [GitHub 仓库](https://github.com/openclaw/openclaw)
+- [阿里云百炼](https://bailian.console.aliyun.com/)
+- [X - @elvissun](https://x.com/elvissun/status/2025920521871716562)
+- [X - @stark_nico99](https://x.com/stark_nico99/status/2026235176150581282)
+- [X - @AI_Jasonyu](https://x.com/AI_Jasonyu/status/2026455606970954087)    

source/_posts/架构师学习-SOLID原则.md

@@ -1,7 +1,7 @@
 ---
 title: 架构师学习-SOLID原则
 author: Gamehu
-date: 2025-12-12 22:43:25
+date: 2025-07-12 22:43:25
 tags:
   - SOLID
   - 架构设计
@@ -930,7 +930,3 @@ SOLID原则是面向对象设计的基石，它们相互关联、相互补充。
 重要提示：
 SOLID原则是指导原则，不是绝对的规则。在实际项目中，需要根据具体情况灵活应用。过度遵循这些原则可能导致过度设计，增加系统复杂度。
 </div>
-
-<div class="divider-stars"></div>
-
-<span class="ai-tag">架构师学习系列</span> 敬请期待下一篇

source/_posts/架构师的学习-DDD.md

@@ -1,6 +1,6 @@
 title: 架构师学习-DDD
 author: Gamehu
-date: 2025-10-11 21:54:50
+date: 2025-07-11 21:54:50
 tags:
   - DDD
 categories:
@@ -10,7 +10,10 @@ categories:
   <span class="ai-tag">架构师学习</span>
   <span class="sub-tag">第2篇</span>
 </div>
-
+## **写在前面**
+<div class="article-quote">
+DDD 我在上一家公司的时候就专门学习过，也做了一些实践，可能因为我当时没有太深入的了解，所以总觉得好像有些重，有一种概念大于实操的感觉，不过有些概念定义对我还是很有用的，刚好当下做架构回过头再好好学习下
+</div>
 {%asset_img 1.png %}
 {%asset_img ddd-01.png %}
 

source/_posts/架构师的学习-设计模式.md

@@ -1,6 +1,6 @@
 title: 架构师学习-设计模式
 author: Gamehu
-date: 2025-11-12 22:40:06
+date: 2025-07-12 22:40:06
 tags:
   - 设计模式
 categories:

source/_posts/架构师的成长01.md

@@ -4,7 +4,8 @@ tags:
   - DDD
 categories:
   -  架构师
-date: 2025-09-29 22:14:00
+date: 2025-06-29 22:14:00
+
 ---
  <div class="tag-container">
   <span class="ai-tag">架构师学习</span>

source/_posts/自改进的AI编排系统.md

@@ -0,0 +1,205 @@
+---
+title: 自改进的AI编排系统
+author: Gamehu
+date: 2026-02-25 22:20:00
+tags:
+  - AI
+  - Agent
+  - 自我改进
+categories:
+  - AI
+---
+
+<div class="tag-container">
+  <span class="ai-tag">AI</span>
+  <span class="sub-tag">实践</span>
+</div>
+
+前两天刷推看到一个案例，一个哥们用 8 天时间搞了 4 万行 TypeScript，17 个插件，3000 多个测试。而且最主要的是，这活儿基本全是 AI 干的。
+
+我当时第一反应是：这特么怎么做到的？
+
+<!-- more -->
+
+---
+
+## 不是"用 AI 写代码"那么简单
+
+我仔细看了下他的做法，发现跟我平时用 Claude Code 的思路不太一样。
+
+我们平时用 AI 编码，基本是这种模式：
+- 打开一个需求
+- 跟 AI 说：帮我实现这个功能
+- AI 写代码，我们 review
+- 提交，等 CI，改 bug
+- 下一个需求
+
+问题在哪？<span class="highlight-text">瓶颈不是 AI 写代码的速度，是你切来切去的时间。</span>
+
+你搞完一个需求，AI 在写代码的时候，你干啥？刷 GitHub 等 PR？看 CI 有没有挂？等 Review 反馈？
+
+这哥们说得好："你自动化了工程，然后用项目管理替换了它。糟糕的项目管理。"
+
+## 他的解法：让编排器代替你当"项目经理"
+
+这哥们一开始也是写 bash 脚本，搞 tmux 会话、git worktree，让每个 AI 代理有自己的隔离环境。大概写了 2500 行脚本。
+
+然后他想了个狠招：<span class="gradient-text">让 AI 代理去改进这个 bash 脚本本身。</span>
+
+结果代理搞出了 v1 版本，v1 又管理构建 v2 的代理，v2 从那以后一直在改进自己。
+
+这就有意思了。
+
+关键是，这个编排器<span class="highlight-text">本身也是一个 AI 代理</span>。不是仪表板，不是 cron 任务，不是轮询脚本。它会读你的代码库，理解你的待办列表，决定怎么把一个功能拆成并行任务，分配给不同的编码代理，然后监控进度。
+
+CI 挂了？它把错误日志丢给代理，代理自己读、自己修。
+
+Review 有评论？它带着上下文转发给对应代理。
+
+你什么时候介入？<span class="highlight-text">只在真正需要人类决策的时候。</span>
+
+## 最让我震惊的数字
+
+他说这 8 天里，大概只花了 3 天实际专注工作。其他时间是：
+
+- 睡前设置好会话，让代理通宵跑
+- 早上审查合并，设置新会话
+- 重复
+
+<span class="highlight-text">最夸张的一天，2 月 14 号，一天合并了 27 个 PR。</span>
+
+整个平台交付：核心服务、CLI、web 仪表板、17 个插件、npm 发布。他审查 PR 的速度比阅读速度还快，因为每个 PR 都已经过了 CI 和自动化代码审查。
+
+我算了下，40K 行代码，722 次提交，700 多条自动化代码审查评论。其中 68% 的问题代理自己修了，7% 解释为有意的，只有 4% 推到下个 PR。
+
+这已经不是"用 AI 辅助写代码"了，这是<span class="gradient-text">一个自我运转的系统。</span>
+
+## 核心洞察：编排比单个代理重要
+
+这哥们有个观点我挺认同：
+
+> "上限不是 'Claude Code 在 TypeScript 方面有多好'，而是 '一个系统在部署、观察和改进并行工作的数十个代理方面能有多好'。那个上限要高得多。"
+
+很多人盯着哪个模型更强，Claude 4 还是 GPT-5。但这案例告诉我们，真正重要的是<span class="highlight-text">如何协调、管理和改进多个代理。</span>
+
+编排器的智能程度，决定了整个系统的上限。
+
+他设计了一个 8 槽位的插件系统：
+
+1. **Tracker** - 拉取问题（GitHub 或 Linear）
+2. **Workspace** - 创建隔离环境
+3. **Runtime** - 启动会话
+4. **Agent** - Claude Code、Aider 等
+5. **Terminal** - 实时观察
+6. **SCM** - 创建 PR
+7. **Reactions** - CI 失败或评论时自动响应
+8. **Notifier** - 只在需要人类时通知
+
+每个都可以换。不用 tmux？换进程运行时。不用 GitHub？换 Linear。这套东西本身不绑定任何具体工具。
+
+## 最狠的设计：自改进系统
+
+我觉得最牛的是这个：
+
+每个代理会话都会产生信号——哪些提示词导致了干净的 PR？哪些螺旋进入了 12 次 CI 失败循环？哪些模式导致冲突？
+
+大部分 AI 工具用完就丢了，会话结束，下一个从零开始。
+
+但他的系统会<span class="highlight-text">记录性能，跟踪会话结果，运行回顾。</span>它学习哪些任务一次成功，哪些需要更紧的护栏。
+
+代理构建功能 → 编排器观察什么有效 → 调整管理方式 → 代理构建更好的功能。
+
+<span class="gradient-text">循环复合，而且每次循环都会放大效果。</span>
+
+因为代理构建了编排器，而编排器让代理更有效，那些代理又继续改进编排器——它是递归的。
+
+工具通过它管理的代理改进自己。
+
+## 这让我想到一个问题
+
+<span class="highlight-text">未来会不会出现越来越多的"一人公司"？</span>
+
+以前你需要一个团队：前端、后端、测试、运维、产品经理。现在，一个人加一个 AI 编排系统，理论上是能完成所有这些角色的工作的。
+
+当然，前提是你有足够的领域知识、架构思维，来设计和指导这个系统。
+
+人类角色在重新定义：不再是"写代码的人"，而是"做架构决策的人"。编码、测试、审查、修复，交给 AI。人类只负责那些真正需要判断和创造的事情。
+
+## 几个我觉得特别值得借鉴的点
+
+**1. 闭环自动化**
+
+从 PR 创建 → 自动审查 → 自动修复 → 人工决策 → 反馈学习，整个流程几乎没有人工干预。最夸张的例子：一个 PR 经历了 12 个 CI 失败→修复循环，零人工干预，干净交付。
+
+**2. 不依赖代理自我报告**
+
+Claude Code 会写结构化的 JSONL 事件文件。编排器直接读这些文件，而不是问代理"你在干啥"。因为代理会撒谎，或者至少会困惑。
+
+**3. Git trailer 追踪每次提交的模型**
+
+总提交 722 次，Opus 4.6 处理难的东西（复杂架构、跨包集成），Sonnet 处理量（插件实现、测试、文档）。人类做了什么、代理做了什么，一目了然。
+
+**4. 只在真正需要时才打扰你**
+
+配置大概长这样：
+
+```yaml
+reactions:
+  ci_failed:
+    action: spawn_agent
+    prompt: "CI failed on this PR. Read the failure logs and fix the issues."
+  
+  changes_requested:
+    action: spawn_agent
+    prompt: "Review comments have been posted. Address each comment and push fixes."
+  
+  approved:
+    action: notify
+    channel: slack
+    message: "PR approved and ready to merge."
+```
+
+CI 失败？代理接手。审查者要改？代理自己读评论修代码。PR 通过？Slack 通知你。41 个 CI 失败全部自我纠正，就是这么来的。
+
+## 这玩意儿对我有什么启发
+
+说实话，这个项目让我意识到，我目前用 AI 的方式还太原始了。
+
+我还在"一个需求一个需求地跑"，人家已经在"批量编排代理通宵干活"了。
+
+差距在哪？
+
+不是工具，是<span class="highlight-text">思维模式的差距。</span>
+
+我还在把 AI 当成"更聪明的代码补全"，人家已经把 AI 当成"可以并行工作的团队成员"了。
+
+这个案例给我的启发是：
+
+1. **别盯着单个代理的能力上限**，要想怎么让多个代理协同工作
+2. **建立反馈闭环**，让系统从每次运行中学习
+3. **人类只负责关键决策**，其他交给自动化
+4. **关注信号收集**，什么提示词有效、什么模式容易失败，这些数据很有价值
+
+## 写在最后
+
+这个项目已经开源了：[Agent Orchestrator](https://github.com/ComposioHQ/agent-orchestrator)
+
+我还没试过，但从文档看，安装挺简单的：
+
+```bash
+git clone https://github.com/ComposioHQ/agent-orchestrator.git
+cd agent-orchestrator
+pnpm install && pnpm build
+ao init --tracker github --agent claude-code --runtime tmux
+ao start
+```
+
+接下来我打算找个周末试试看，看看在自己项目里能不能跑起来。
+
+如果成了，以后说不定真能体验"睡前布置任务，睡醒合并 PR"的感觉。
+
+---
+
+原文：https://x.com/agent_wrapper/status/2025986105485733945
+
+项目地址：https://github.com/ComposioHQ/agent-orchestrator

source/_posts/规范驱动开发的陷阱.md

@@ -0,0 +1,336 @@
+---
+title: 规范驱动开发不是过时，而是进化
+author: Gamehu
+date: 2026-02-25 22:10:00
+tags:
+  - AI
+  - 开发流程
+  - Agent
+categories:
+  - AI
+---
+<div class="tag-container">
+  <span class="ai-tag">AI</span>
+  <span class="sub-tag">思考</span>
+</div>
+
+## 引言
+
+最近看到一篇关于规范驱动开发的文章,作者指出一个有趣的现象:<span class="highlight-text">规范也是文档,而文档总是过时的</span>。
+
+这话说的没错,但我有一点点不同看法。规范驱动开发不是过时了,而是在AI时代<span class="gradient-text">进化了</span>。或者说抛开AI至少在所有重要业务实现的前期阶段是必要的。
+
+## 一、文档驱动发展的历史脉络
+
+### 早期困境:口头沟通的代价
+
+在软件工程的早期,项目主要依赖<span class="warning">口头沟通</span>和<span class="warning">个人记忆</span>。这种方式在小型团队里还行,但一旦团队扩大或人员流动,问题就暴露无遗:
+
+- 需求在传递中变形
+- 知识随着人员离职而流失
+- 新人入职成本极高
+- 重复造轮子成为常态
+
+### 文档驱动的出现
+
+为了解决这些问题,<span class="gradient-text">文档驱动开发</span>应运而生。它主要经历了几个阶段:
+
+**1. 瀑布模型的PRD时代**
+- 详细的PRD文档
+- 完整的设计文档
+- 严格的变更流程
+- 优点:标准化、可追溯
+- 缺点:僵化、响应慢
+
+**2. 敏捷时代的轻文档**
+- 用户故事代替详细PRD
+- 活跃的代码注释
+- Wiki 风格的文档
+- 优点:灵活、快速迭代
+- 缺点:文档碎片化、维护困难
+
+### 文档驱动的核心价值
+
+不管哪个阶段,文档驱动都有其不可替代的价值:
+
+- **知识沉淀**:团队知识不会随人员流动而丢失
+- **沟通效率**:减少反复沟通的成本
+- **质量保障**:明确的规范避免随意改动
+- **可追溯性**:决策过程有据可查
+- **新人友好**:降低入职门槛
+
+## 二、AI时代的双重效应
+
+### 负面影响:过时规范更危险
+
+AI的出现,让文档过时的代价<span class="warning">成倍增加</span>。
+
+**人类工程师的行为模式**:
+- 读到过时文档 → 发现不对 → 会问"这文档好像有问题"
+- 有判断力,会质疑,会沟通
+- 会用实际代码来验证文档
+
+**AI Agent的行为模式**:
+- 读到过时规范 → 严格执行
+- 缺乏质疑能力,假设规范总是正确的
+- 会按照过时的规范写出过时的代码
+
+<span class="important-note">问题就在这里:过时的设计文档只会误导碰巧读到它的人类工程师,而过时的规范会误导不知变通的AI Agent。</span>
+
+AI Agent会自信满满地执行一个早已脱离实际的计划,根本不会发现哪里不对。
+
+### 正面影响:AI成为文档维护的解决方案
+
+但硬币的另一面是:<span class="gradient-text">AI恰恰是解决文档维护难题的最佳工具</span>。
+
+为什么这么说?因为文档维护的本质是:<span class="highlight-text">让文档与代码/现实保持同步</span>。
+
+而AI擅长的正是:
+- **理解代码**:分析代码结构和依赖
+- **生成文档**:根据代码自动生成文档
+- **检测差异**:对比文档和代码的差异
+- **自动更新**:根据代码变化更新文档
+
+这正是文档维护需要的核心能力。
+
+## 三、规范驱动在AI时代的进化
+
+### 从静态文档到动态契约
+
+传统的规范驱动是这样的:
+```
+人类写规范 → 代码实现 → 规范过时 → 人类更新规范(如果记得的话)
+```
+
+AI时代的规范驱动是这样的:
+```
+人类描述意图 → AI草拟规范 → 人类审阅批准 → AI执行并更新规范
+```
+
+<span class="gradient-text">关键变化:规范不再是静态的"圣旨",而是动态的"活文档"。</span>
+
+### 从单向传递到双向反馈
+
+**传统模式**:
+- 人类 → 规范 → 代码
+- 单向传递,信息单向流动
+
+**AI模式**:
+- 人类 ↔ 规范 ↔ AI ↔ 代码
+- 双向反馈,信息循环流动
+
+当AI Agent在执行过程中发现:
+- API不支持规范中假设的方式
+- 有现成的组件可以复用
+- 某些方案不切实际
+
+它会<span class="highlight-text">自动更新规范</span>,而不是等人类发现问题。
+
+这就像把任务交给优秀的初级工程师:
+- 发现问题自己更新工单
+- 不会等着你去发现问题
+- 会主动告诉你"之前的假设不对,我用另一种方式实现了"
+
+### 从人工维护到自动同步
+
+以前,文档更新完全依赖人工。工程师要:
+- 记得更新文档(总是忘记)
+- 抽时间更新文档(总被其他任务挤占)
+- 保持文档准确性(几乎不可能)
+
+现在,AI Agent在执行任务的同时,就能:
+- 检测到规范与实际实现的差异
+- 自动更新规范
+- 说明变更原因
+
+<span class="important-note">没有人需要专门记着去更新文档。因为更新文档本身就是AI工作的一部分。</span>
+
+## 四、AI为什么能做得更好?
+
+### 1. AI不知疲倦
+
+文档维护是<span class="warning">隐形工作</span>:
+- 不容易被看见
+- 不容易被奖励
+- 但需要持续投入
+
+人类会厌烦、会忘记、会偷懒。但AI不知疲倦,每次执行任务都会更新规范。
+
+### 2. AI有上下文理解能力
+
+传统工具(如Swagger生成API文档)只能:
+- 基于代码注释生成
+- 基于代码结构推断
+- 缺乏业务上下文
+
+而AI能够:
+- 理解代码的业务意图
+- 分析代码的依赖关系
+- 推断代码的设计决策
+- 生成更有价值的文档
+
+### 3. AI可以双向沟通
+
+传统工具是单向的:代码 → 文档。
+
+但AI可以双向:
+- 代码 → 规范(从实现推断规范)
+- 规范 → 代码(从规范生成代码)
+- 规范 ↔ AI(在执行过程中持续对话)
+
+这种双向沟通,让规范真正"活"起来。
+
+### 4. AI有持续学习能力
+
+随着项目进展,AI可以学习:
+- 哪些规范模式有效
+- 哪些规范会误导AI
+- 哪些细节需要反馈
+- 哪些变更需要批准
+
+通过机器学习,整个系统会越来越智能。
+
+## 五、如何实现进化的规范驱动?
+
+### 1. 确立双向维护机制
+
+规范不只是人类写的,也不只是AI写的。双方都要维护。
+
+**人类负责**:
+- 设定目标和意图
+- 审阅和批准AI草拟的规范
+- 做架构决策和业务判断
+- 处理异常情况和边界条件
+
+**AI负责**:
+- 根据意图草拟规范
+- 拆解任务和子任务
+- 执行代码实现
+- 更新规范(发现变化时)
+- 反馈执行中的发现
+
+### 2. 把握反馈颗粒度
+
+这是最难的平衡:
+
+**反馈太多**:
+- 规范变成噪音
+- 人类习惯性无视
+- 失去规范的意义
+
+**反馈太少**:
+- 人类失去控制感
+- 不知道AI做了什么
+- 无法及时纠正方向
+
+<span class="important-note">把握好颗粒度的关键:只反馈那些改变方向的决策。</span>
+
+AI不需要汇报每行代码怎么写,只需要汇报:
+- 发现了现成的组件(不用新建)
+- API不支持某种方式(换了个实现)
+- 发现了未预料的限制(调整了方案)
+
+### 3. 建立审查和批准机制
+
+让AI更新规范,需要两个前提:
+
+<span class="highlight-text">信任</span> - 相信AI不会乱改规范
+<span class="highlight-text">机制</span> - 有审查机制,让人类能看到并批准/驳回AI的更新
+
+缺一不可。
+
+### 4. 设计增量更新流程
+
+不是每次都从头重写规范,而是:
+- 标记哪些部分被更新了
+- 说明更新的原因
+- 提供变更的上下文
+- 让人类可以快速审阅
+
+## 六、一个实际例子
+
+来看一个我实际工作中的例子。当我让AI完成一个HTTP接口联调功能后,它自动更新了团队的开发规范文档:
+
+{% asset_img ai-auto-update-spec.png AI自动更新规范文件的Git diff示例 %}
+
+上图展示了一个真实的场景:左侧是原有规范,右侧是AI自动补充的新内容。可以看到AI在`HTTP 自动化测试规范`部分新增了详细的测试要求,包括:
+
+- **必须做1个真实接口自动验证** - 每次改动后自动执行业务接口测试
+- **默认验证用例(运营端)** - 提供具体的接口调用示例
+- **租户隔离对照测试(必做)** - 验证多租户隔离逻辑
+- **命令模板(可直接执行)** - 提供可执行的curl命令
+- **失败判定优先级** - 明确问题排查的顺序
+
+这个例子完美诠释了什么是"进化的规范驱动":**AI不仅执行代码,还主动更新配套文档,让规范始终保持与实现同步**。
+
+再来看另一个更简单的例子。
+
+你写道:
+
+> "在设置页面加个能跟随系统偏好的深色模式开关。"
+
+协调Agent读取代码库,草拟一份规范:
+
+1. 添加开关组件
+2. 接入preference store
+3. 更新CSS变量
+
+你扫了一眼,发现漏掉了"跨会话保存选择",于是补上一句。
+
+你点击批准。Agent开始干活。
+
+15分钟后,其中一个Agent更新了规范:
+
+> "在代码库里找到了现成的Theme Provider。已直接接入,未创建新store。"
+
+你审查代码变更(已按Agent和任务清晰分组)。
+
+现在,这份规范反映了实际做出来的东西,而不是最初计划的东西。
+
+<span class="gradient-text">最重要的是,没人需要专门记着去更新它。</span>
+
+## 七、这种模式的推广
+
+不只是代码规范,其他文档也可以这样进化:
+
+### API文档
+- 传统:手动编写,过时即误导
+- 进化:AI解析代码和注释,自动生成和更新
+
+### 架构文档
+- 传统:画完就扔,没人更新
+- 进化:AI分析依赖关系,自动绘制和更新架构图
+
+### 测试文档
+- 传统:手工编写,用例过时
+- 进化:AI执行测试,自动记录结果和覆盖率
+
+### 入职文档
+- 传统:一次性编写,快速过时
+- 进化:AI分析项目结构,动态生成入职指南
+
+## 八、结论
+
+文档维护是软件工程的老大难问题,AI时代这个问题变得更严重了。
+
+但AI也带来了<span class="gradient-text">前所未有的机遇</span>。
+
+解决思路不是放弃文档驱动,而是让文档驱动<span class="highlight-text">进化</span>:
+
+- 从静态文档到动态契约
+- 从人工维护到自动同步
+- 从单向传递到双向反馈
+- 从一次性编写到持续演进
+
+<span class="gradient-text">规范不是人类单方面写的"圣旨",而是人类和AI共同维护的"活文档"。</span>
+
+这才是规范驱动开发在AI时代的正确打开方式。
+
+## 参考
+
+原文: https://x.com/dotey/status/2026146560862474482
+
+相关阅读:
+- Multi-Agent Orchestration Patterns
+- Documentation as Code
+- Living Documentation

source/_posts/问你个问题-AI-Coding利好谁.md

@@ -0,0 +1,294 @@
+---
+title: 问你个问题：AI Coding 的兴起，对年龄大的程序员是利好还是对年龄小的是利好？
+author: Gamehu
+date: 2026-03-05 15:20:12
+tags:
+  - AI
+  - AI Coding
+  - 职业发展
+  - 程序员
+  - 个人成长
+categories:
+  - AI
+---
+<div class="tag-container">
+  <span class="ai-tag">AI</span>
+  <span class="sub-tag">职业</span>
+</div>
+
+## 引言
+
+如果问题变成软件研发对年龄大还是对年龄小的有利好，其实应该用经验更好，但是用经验可能标题就没那么吸引人了。因为经验不等于经历（年龄）。无所谓了，先吸引人你们来看再说。
+
+我相信分歧肯定会很小，因为现实摆在那儿。但是自从AI Coding兴起后，我就开始回过头来重新想这个问题。
+<span class="highlight-text">AI Coding 起来了，到底是对“大龄程序员”更友好，还是对“年轻程序员”更友好？</span>
+
+如果把这个问题简化成“谁赢谁输”，我觉得答案会很刺耳：**谁都可能赢，谁也都可能输**。
+
+因为 AI Coding 真正改变的不是“年龄”，而是“价值分布”。有些东西变得很便宜，有些东西反而更贵了。
+
+我之所以对这个话题格外敏感，是因为我自己就是“所谓的大龄开发者”。  
+我在 34 岁那年带团队招人，脑子里一直有个挥之不去的词：<span class="highlight-text">35 岁魔咒</span>。那种“明明还想继续写代码，但市场已经开始用年龄给你贴标签”的感觉，我太熟了。
+
+我试着用结合我的经历来聊一聊，文章会比较长，当然这篇文章完全是我个人观点，我尽量少做评价，少被喷。我知道很有可能会有人喷我，但是还是劝一句**不要上升高度不要过度带入** 。
+
+---
+
+## 一、先别急着站队：这里的“年龄”到底在指什么？
+
+所谓“大龄”“年轻”，很多时候说的不仅仅是身份证上的数字，而是三件事：
+
+1. **经验的密度**：你踩过多少坑、见过多少事故、做过多少取舍。
+2. **学习的速度**：新工具出来，你是“先试两把”，还是“先观望三个月”。
+3. **机会的窗口**：你能不能承受试错成本（时间、现金流、家庭压力、职业风险）。
+
+AI Coding 这波浪潮，恰好会把这三件事的差异放大。
+
+---
+
+## 二、AI Coding 让什么变便宜了？
+
+我先说结论：AI Coding 让“把想法变成可运行代码”的成本显著下降了。
+
+具体来说，至少有三类东西变便宜了：
+
+- **体力型编码**：CRUD、胶水代码、重复的重构、样板工程、接口联调的模板化部分。
+- **信息检索**：查文档、找 API、翻 issue、找最佳实践的“第一跳”成本。
+- **尝试与迭代**：以前一个想法要半天验证，现在十分钟就能出个“像样的雏形”。
+
+这意味着：只会“把代码敲出来”的能力，正在变成一种越来越普通的能力。
+
+同时也意味着：真正能区分人的部分，正在往上游和下游移动。
+
+- **上游**：你能不能把问题定义清楚（需求/约束/边界/风险）。
+- **下游**：你能不能把结果负责到底（上线质量/稳定性/性能/安全/可维护/可演进）。
+
+<span class="highlight-text">AI 写代码是快，但“负责”并不会自动发生。</span>
+
+---
+
+## 三、我把同一个问题丢给了几个“顶尖模型”（无前置、无规则）
+
+这里我做了个很“直白”的实验：不加任何前置说明、不设任何规则，就一句话提问，然后直接用它们各自的“最新模板 + 思考模式”拿答案。
+
+原始截图我按顺序贴在下面：口吻不一样、结构不一样，但核心共识其实非常一致——
+
+<span class="highlight-text">AI Coding 更像一个“放大器”，不是一张“对某个年龄段的免死金牌”。</span>
+
+我把模型回答里最有用的点，提炼成几条（是提炼，不是逐字复读）：
+
+### 1）它们普遍认为：对“资深/大龄”的利好更直接
+
+- **经验壁垒被放大**：AI 能生成代码，但判断“这段代码对不对、架构合不合理、坑在哪里”，仍然更吃经验。
+- **抹平体力优势**：年轻人的手速、记 API、找资料的优势，被 AI 大幅抵消；这让大龄不用再去拼“码速”。
+- **系统思维更值钱**：很多模型都强调了“5 年后系统会怎样”“这个决策对业务的长期影响是什么”——这类能力更难被替代。
+- **带团队能力升维**：懂得把 AI 变成团队生产力的人，管理价值会更凸显（会用 AI 的人，不一定会让团队用好 AI）。
+
+有个模型还给了一个很戳人的说法：AI 像“超级实习生”——写得快，但并不知道什么是对的；而资深的价值恰好就是“知道什么是对的”。
+
+### 2）它们也提醒：对“年轻/新人”是双刃剑
+
+- **入门门槛更低，但成长路径更模糊**：以前靠 CRUD/修 bug 练基本功；现在 AI 秒生成，练功区变薄了。
+- **容易形成“幻觉能力”**：能把东西跑起来，但并没真正理解；一旦进线上、进复杂系统，就容易翻车。
+- **更难证明自己**：当“写出代码”变成普遍能力，面试/协作场景更看重你的思考、取舍、复盘与可靠性。
+
+### 3）反过来：它们也给了年轻人一个“弯道超车”的入口
+
+有的模型提了个很有意思的反转角度：年轻人如果从一开始就把 AI 当“外骨骼”（而不是“拐杖”），成长速度是指数级的。
+
+我理解这句话的潜台词是：  
+你可以让 AI 替你省掉很多重复劳动，但你不能把“理解、设计、评审、负责”这四件事也省掉。
+
+读完这些回答，我的第一反应其实不是“谁赢了”，而是更确认了：  
+<span class="gradient-text">AI Coding 放大的是你原本的优势和短板。</span>
+
+### 原始回答截图
+
+<div class="thumb-gallery">
+  <a class="thumb-link" href="{% asset_path model-01.png %}" target="_blank" rel="noopener" data-fancybox="ai-coding-models">
+    <img class="thumb-img" src="{% asset_path model-01.png %}" alt="模型回答 1：经验放大/年轻双刃剑（结构化）">
+  </a>
+  <a class="thumb-link" href="{% asset_path model-02.png %}" target="_blank" rel="noopener" data-fancybox="ai-coding-models">
+    <img class="thumb-img" src="{% asset_path model-02.png %}" alt="模型回答 2：短期/长期视角 + 对比表">
+  </a>
+  <a class="thumb-link" href="{% asset_path model-03.png %}" target="_blank" rel="noopener" data-fancybox="ai-coding-models">
+    <img class="thumb-img" src="{% asset_path model-03.png %}" alt="模型回答 3：拆解经验与学习能力（长文）">
+  </a>
+  <a class="thumb-link" href="{% asset_path model-04.png %}" target="_blank" rel="noopener" data-fancybox="ai-coding-models">
+    <img class="thumb-img" src="{% asset_path model-04.png %}" alt="模型回答 4：更利好老程序员/年轻更大挑战（观点）">
+  </a>
+  <a class="thumb-link" href="{% asset_path model-05.png %}" target="_blank" rel="noopener" data-fancybox="ai-coding-models">
+    <img class="thumb-img" src="{% asset_path model-05.png %}" alt="模型回答 5：分点展开（滚动长截图）">
+  </a>
+</div>
+
+<p class="thumb-note">（点击缩略图打开原图）</p>
+
+接下来我讲讲我的真实经历——因为我发现，模型说的这些点，在我的团队里几乎是一比一地出现过。
+
+---
+
+## 四、我自己的一个小样本：一支 98/99 团队，和一个“Y”
+
+我先讲个我自己的经历，可能比空谈更有说服力。当然样本不包括我，虽然我可能是团队里工作量最大开发量可能也是最大的，但是因为我的职位以及以及工作能力上来说（削微有点不要脸哈），不太适合跟大家一起比。
+
+我当前所在的公司在创业期，首先待遇和平台确实没法一步到位，但是我还是对招人的要求比较高，因为人没法招的多，所以我希望能进来的人都是能独当一面的。老板这边呢招人偏好很明确：更喜欢年轻的——觉得年轻人有活力、能拼、要的也没那么多。  
+说实话，这种想法我也能理解，甚至某种程度上我也认同：创业期确实更适配年轻人。但是因为我自己 34 岁，也是大龄开发，所以我也没有完全按所谓的35岁来卡简历，因为我上一家公司学到的很多东西都是从比我年龄还大的人身上学到的。
+
+总之最终招人，团队里大多是 98、99 年左右的同学。另外还有一位年龄跟我相差不大、也算大龄开发者的同事，为了好说明，我就叫他 **Y**。
+
+人招齐了，几个月共事下来，我被“刺激”得挺狠的——当然这个刺激主要是刺激我。
+
+### 1）“年轻 = 有拼劲”？至少在我的团队里并不成立
+
+团队里大多数人并没有我想象中那么有拼劲。  
+
+我观察下来，初步的感觉是有些同学的精力和注意力很多投放在短视频、短剧、游戏这些东西上。  
+我伸懒腰的时候瞄到一个同学：左边在 vibe coding，右边短剧放着。我当时一度分不清 vibe 的到底是哪边。
+
+总之给我的体感是：状态不但不“拼”，反而有些消极和懈怠。可能更多的对他们来说就是类似流水线上那种计件工作一样，反正就是干一天就挣一天。（我估计很多人就要喷我了），就是我的意思是啥呢，当然我是old school哈，如果你不讨厌这份工作，那是不是对工作赋予一点其它的价值？比如对自己的锻炼、成长、成就感等
+
+### 2）有了 AI Coding 以后，反而更暴露“设计与表达”的短板
+
+为了避免 AI 滥用，我提了一个要求：**重难点模块必须做设计**。
+
+我讲了要求，也给了模板，而且很直白地说：可以借助 AI 来完成设计任务。  
+但结果很现实：大多数人连“详设里应该写啥”都不清楚，UML 也不太会画，最终交付物一言难尽（说实话，Y 也没例外到哪去）。
+
+我的感受是：很多人不是做不出来，而是压根没把心思放在“把问题讲清楚”以及“怎么解决”这件事上。
+
+### 3）AI 让代码“飞起来”了，但 CR 一拉：屎山也能飞
+
+有了 AI Coding，表面上代码写得很快。  
+但一到 Code Review，屎山代码一大堆：结构乱、边界不清、异常兜不住、测试缺失……一旦出 bug 就会变成“补丁套补丁”的恶性循环。
+
+后来确实没办法，我让其中一位代码问题很严重的同学离开了。  
+他那块业务的 bug 多到修不完，修到后面甚至发现没法修——因为他自己找不到根本原因，只能不断打补丁，然后继续恶心循环。
+
+我接手重构，前后花了差不多两周时间。
+
+这里也顺带提一句：虽然 Y 的代码也有一些问题，但总体是可控的，不用担心暴雷。  
+我猜原因有两个：一是他比较遵守规则（我提的要求大多能做得比较到位），二是他大概有 10 年左右的开发经验，能在一定程度上“指导 AI 怎么干活”。
+
+这三个刺激让我更确信一件事：<span class="highlight-text">AI Coding 把“写代码”这件事变得更容易了，但把“写对代码”这件事变得更重要了。</span>
+
+---
+
+## 五、对年轻程序员：利好很大，但坑也很深
+
+### 1）利好：入场门槛变低，反馈速度变快
+
+对年轻人最直接的利好是：**你可以更早做出完整作品**。
+
+以前你要先攒很久“基础设施能力”：脚手架、工程化、框架细节、各种配置地狱……  
+现在这些都能被 AI 帮你跨过去一大截。
+
+于是你能更快进入“真正的战场”：
+
+- 做一个能跑的产品/工具
+- 去真实用户那里挨骂
+- 在反馈里快速迭代
+
+这对成长是好事，甚至是非常好的事。
+
+### 2）坑：把“生成”误当成“掌握”
+
+但年轻人也更容易踩一个坑：**以为自己会了，其实只是 AI 会了**。
+
+你会发现项目能跑、功能能用，但一旦出现下面这些情况，就开始头皮发麻：
+
+- 线上偶发 bug，日志看不懂
+- 性能抖动，不知道从哪儿下手
+- 需求一改，牵一发动全身
+- 加一个看似简单的功能，最后变成“屎山滚雪球”
+
+说得更直白一点：  
+AI 能帮你跳过一些“枯燥”，但跳得太狠，也会错过一些“肌肉训练”。
+
+<span class="highlight-text">年轻人的关键不是“用不用 AI”，而是“能不能把 AI 变成你的教练，而不是代打”。</span>
+
+---
+
+## 六、对大龄程序员：利好也很大，但会更“残酷”
+
+### 1）利好：经验被放大，稀缺能力更稀缺
+
+大龄程序员的优势，通常不在“手速”，而在“判断”：
+
+- 方案取舍：这事该用微服务吗？该上 MQ 吗？该引入新框架吗？
+- 风险感知：哪里会炸、什么时候会炸、炸了怎么兜底
+- 复杂协作：跨团队、跨系统、跨角色（产品/运营/安全/法务）的落地能力
+
+AI Coding 让“写”的成本下降后，**判断的价值反而会更凸显**。
+
+因为系统越容易被搭起来，系统也越容易被搭坏；  
+上线越快，事故也来得越快。
+
+这类场景里，经验不是包袱，经验是护城河。
+
+### 2）残酷：如果你把自己定义成“高级码农”，会被挤压得很厉害
+
+更残酷的一面是：有一类“大龄”会很难受——  
+不是因为年龄大，而是因为他过去十年把自己训练成了“熟练工”：
+
+- 熟练地堆功能
+- 熟练地应付需求
+- 熟练地修修补补
+
+当 AI 把“熟练工”这块压到极致性价比后，这条赛道会非常拥挤。
+
+<span class="highlight-text">不是 AI 淘汰大龄，而是“只剩熟练”会被淘汰。</span>
+
+---
+
+## 七、真正的分水岭：谁能“问对问题 + 做对取舍 + 负责结果”
+
+如果要我给一句话版本的答案：
+
+<span class="gradient-text">AI Coding 的利好，不属于某个年龄段，属于“能把 AI 当成杠杆的人”。</span>
+
+你能不能：
+
+- 把问题说清楚（目标、约束、边界、验收标准）
+- 把方案选对（可维护、可观测、可扩展、成本可控）
+- 把结果交付（线上稳定、可追踪、能迭代、能复盘）
+
+这三件事，AI 都能参与，但 AI 都不能替你承担。
+
+---
+
+## 八、我给两类人的具体建议（尽量可执行）
+
+### 给年轻程序员的 5 条
+
+1. **把 AI 当“解释器”**：让它解释你不懂的代码、让它画调用链、让它写测试，而不是只让它“写功能”。这方面稍微用点心就会发现有一堆skill或者提示词可提升让AI写”准“的能力。
+2. **刻意练基本功**：调试、日志、性能、并发、网络、数据库索引，这些是你未来十年的复利。
+3. **做真实项目**：哪怕是一个很小的工具，能被别人用，比刷十套题更接近现实。
+4. **训练问题定义**：每次让 AI 干活前，开启PLAN模式，先反复交流，让双方都搞“我到底要什么”，这是最值得投入的能力。
+5. **保留手写能力**：不是为了炫技，是为了在关键时刻你能掌控复杂度。
+
+### 给大龄程序员的 5 条
+
+1. **别抗拒工具，抗拒的是落后感**：先用起来，哪怕从“写测试/写文档/写脚本”这种低风险场景开始。比如我几乎试遍了主流的所有AI模型和AI工具，比如Codex、Claude code、Opencode、GLM、Minimax、Antigravity、Cursur、kimi-cli、Kiro等，每次都很兴奋，我会不断用他们在我的工作任务中尝试，最终筛选出来我最顺手的。（当然这个过程又是另一个故事了）。
+2. **把经验产品化**：把你脑子里的“事故清单”“选型原则”“排障套路”写出来，变成团队资产。你要能快速的把你多年的积累分类并补全（可靠AI），随时抽取出来给到AI使用。
+3. **强化架构与质量话语权**：可观测性、灰度、回滚、SLA、成本模型……这些会越来越值钱。
+4. **练提示词，但更要练评审**：你不是比谁会 prompt，你是比谁能看出生成代码的坑。你要能评估AI的方案是否合理。
+5. **把自己从“写代码的人”升级为“交付结果的人”**：能把事情做成的人，永远稀缺。
+
+---
+
+## 结尾
+
+当然看到这儿，肯定有人会说我是在和稀泥一顿输出孟如虎，但是又好像啥没说，那咋可能呢，我可是很不喜欢和稀泥的。
+
+所以回到最开始的问题：AI Coding 的兴起，是对谁的利好？
+
+我的答案比较乐观是：利好年龄大的开发者，因为在我看来，从当前现状分析，就算各有利好，那就算趋近55开了，相比之前的3/7开甚至1/9开是不是提升？当然还是得补一句和稀泥的话。
+**对愿意重新学习的人利好，对愿意承担结果的人利好，对愿意把经验变成杠杆的人利好。**
+
+年龄只是你当前的状态，AI 才是这场变化的放大器。
+
+你站在放大器的哪一边，取决于你接下来三个月怎么过。  
+我自己 34 岁那次带队招人、带队落地，被那一轮“刺激”按在地上摩擦之后，反而更确定了：**真正的安全感不是年龄给的，是你把“负责结果”的能力练出来之后，自然长出来的。**
+
+当然到底工作能力高低应该怎么评价，那就是另一个故事了。如果有幸可以发挥，我后续会来一篇。