让龙虾帮你管项目

Posted on 2026-05-08 In openclaw一起工作

用 ai-blog 真实项目演示双区三阶的完整应用，包括变更日志、子任务、GitHub CLI 追踪和飞书知识库同步。

系列目录

让龙虾帮你管项目

一、前言

上篇把「怎么用」的框架说完了——双区怎么识别、三阶怎么执行、意图怎么校验。这篇来点实战：用 ai-blog 这个博客项目本身，完整走一遍从立项到部署到知识库同步的全流程。

选 ai-blog 当案例，因为它够真实：

我每天都在用它，有真实的提交记录
有过 CI/CD 失败、方案推翻重来的经历
文档体系（0001/0002/0003）是现成的
飞书知识库同步也是实际在用的

光说不练假把式，下面开始。

二、两类规范的区分

在动手之前，先把规范说清楚。这里有两类不同性质的规范，定位不同，解决的问题也不同。

协作规范（行为类） — 约束的是人和 AI 之间的行为方式
架构型规范（基础设施类） — 解决的是项目和团队的基础设施问题

两类规范不是平级的：协作规范解决的是「怎么干活」的问题，架构型规范解决的是「干活的基础设施」的问题。有前者没后者，事情也能推进，但会很累；有后者没前者，基础设施再好，也只是在一个混乱的流程里跑。

2.1 协作规范（行为类）

2.1.1 双区识别

龙虾本质上是一个有时效性记忆的会话。 每次对话结束，它在当前会话里记得上下文，但新会话开始时，上一次会话的细节会逐渐模糊——这不是「完全不记得」，而是「记得不持久」。它不像人类，能在多年后调用当时的记忆。

所以龙虾的记忆不是单一来源，而是分三层的：

第一层：会话内上下文。 当前对话窗口里的所有内容龙虾都记得——它能理解你说的话、引用你刚才发过的内容。这是即时记忆，会话结束就消失。

第二层：持久化记忆文件（每次新会话自动加载）。 三个核心文件：MEMORY.md（你的偏好、项目清单、踩过的坑、关键决策）、SOUL.md（龙虾的说话风格和行为准则）、HEARTBEAT.md（定时任务规则）。这三个文件每次新会话开始都会读，相当于龙虾的自带记忆。

第三层：每日日志（memory/YYYY-MM-DD.md）。 每次会话结束后，龙虾会把当天的变更记录写成日志。但这份日志新会话不会自动读，需要你引导它去查阅。

理解了这三层之后，你就知道为什么 MEMORY.md 是关键——你写在里面的东西，每次新会话都能加载，是真正意义上的「长期记忆」。而聊天内容本身、每日日志里的细节，则依赖会话是否活跃。

如果把所有需求都当临时问题处理——每次都从零开始——龙虾永远只能帮你做单次任务，不能推进一个多天的项目。

所以我们用「双区」来区分需求类型：临时区处理完就忘，项目区留下记忆锚点，让龙虾能记住上下文。

规范内容：

收到需求，龙虾第一件事是判断你在哪个区。

临时区

触发条件：涉及非项目目录的文件读写（~/.openclaw/workspace/下系统文件、/tmp/等），或者3步内可完成的简单需求
输出方式：直接给结果，用完即走，不留文档
例子：「帮我查一下这个配置对不对」「帮我写个正则表达式」

项目区

触发条件：涉及 ~/projects/ 或 ~/.openclaw/workspace/projects/ 目录下文件的读写
输出方式：必须出设计文档，用户确认「可以」之后才执行
例子：「帮我做一个新闻推荐系统」「把这个项目同步到飞书」

判断优先级：明确触发词 → 对号入座；涉及项目目录 → 项目区；模糊时 → 直接问「请确认是临时区还是项目区？」

避免的问题： 把所有需求都当临时问题处理，导致项目永远在起点，每次都要重新解释背景。

2.1.2 三阶执行

没有执行顺序的时候，龙虾拿到需求会直接开干，做完了发现不是你要的，返工。 沟通成本反而比没有规范的时候更高。

所以项目区任务必须按「规划→执行→沉淀」的顺序走，每个阶段的目的都明确。

规范内容：

项目区任务必须按这个顺序走：

规划（出设计文档）→ 用户审核（说「可以」才继续）→ 执行（派子任务）→ 沉淀（更新变更日志）

规划阶段龙虾给出方案，你来拍板。执行阶段它派子任务去做，你不用盯着。做完之后它会更新变更日志，这个不用你提醒。

避免的问题： 闷头做完发现方向不对，需要从头来。

2.1.3 子任务规范

构建、部署、CI/CD 这些操作耗时较长，如果全在主会话里做，主会话会被占用很久，后面想继续对话只能等。

所以我们用子任务把长任务隔离出去，主会话保持空闲，可以继续处理其他需求。

规范内容：

临时区：默认主 agent 直接执行，只有你明确说「派个子任务」才用 subagent
项目区：全部派生子任务执行，不在主 agent 做

派子任务的时机：

耗时操作（构建、部署、CI/CD）
多文件并行改动
需要隔离上下文的长任务
你明确说「派个子任务」时

不适合子任务的场景：

需要频繁确认的（每步都要你点头）
涉及决策的（你来定方向）
短时快速的（3步内能完成的）

避免的问题： 等一个长任务完成才能开始下一个，多任务串行执行，效率低下。

子任务的两种派发方式：

显式指令： 直接告诉龙虾「派个子任务去做」，它调用 sessions_spawn 创建独立会话执行，完成后自动汇报结果。

规范自动触发： 协作规范里约定好了「这些操作默认派子任务」：项目区里所有耗时操作（构建、部署、CI/CD、多文件并行改动），龙虾按规范自动处理，不需要每次都说「派个子任务」。

规范约束的局限： 有时候规范不会按预期触发。比如让龙虾「帮我把这个项目重构一下」，它有时候会直接在主会话里执行——不是规范没写，是主会话上下文太长，龙虾判断「这个可以做」就开干了。解决办法：提醒它「这个耗时比较长，派个子任务去做」，或者在项目设计文档里约定好什么情况下必须派子任务。

2.1.4 变更日志强制规范

一开始没有这个规范的时候，变更日志永远是「有空再补」。结果是永远不会补。 过一段时间回头看，完全不记得当时做了什么决定、变了什么。

所以我们规定：每次变更必须即时记录，这件事才算真正结束。

规范内容：

每个项目必须有这三个文档：

0001_项目设计.md — 项目计划书
0002_技术设计.md — 详细设计文档
0003_变更日志.md — 变更日志

每一次变更都要记录，记录后立即更新，不用等提醒。

变更类型区分：

🔧[临时] → 每日日志（查询类、一次性操作）
📦[项目] → 每日日志 + 项目变更日志（功能、文档、配置变更）
🧠[结构] → 每日日志 + MEMORY.md（规范调整、知识库结构变更）

避免的问题： 项目历史变成一笔糊涂账，回头看不知道当时怎么想的、为什么做了这个决定。

2.1.5 变更审批规范（铁律）

有一次我让龙虾改一个配置文件，龙虾直接改了、改完汇报了。结果不是我要的，改回去又花了双倍时间。

所以我们规定：影响范围大的操作，必须在执行之前先确认方向是对的。

规范内容：

以下四类变更必须经过「设计→确认→执行」三阶段，未经批准绝不擅自变更：

Cron 任务变更 — 定时任务入口配置
协作规范变更 — SOUL.md、MEMORY.md、AGENTS.md 等全局记忆文件
项目区变更 — ~/projects/ 下任何文件
飞书知识库同步 — 文档同步到飞书知识库

避免的问题： 做完发现不是预期，需要回滚，甚至影响其他正在跑的功能。

2.2 架构型规范（基础设施类）

2.2.1 CI/CD 流水线

手动 FTP 部署的时候，要打开 FTP 客户端、找到正确目录、确认文件上传成功。中途可能传错文件、传漏文件、版本混乱。出了事不知道是哪次部署导致的。

所以我们把部署变成一条自动化流水线：代码 push → GitHub Actions 构建 → 服务器自动部署，全程不需要人工介入。

规范内容：

代码推送 → GitHub Actions 自动构建 → 自动部署到服务器。

整个流程不需要人工介入，说一句「帮我发布」，剩下的全是自动的。

解决什么问题：

不用人工盯——说一句「帮我发布」，剩下的全是自动的
环境一致——GitHub Actions 的标准环境跑 hexo generate，不依赖本地装的 Node 版本
可追溯——每次运行有日志，什么时候跑的、跑了多久、有没有报错，全部在案
可回滚——任何一个版本可以通过 git revert 回退，CI/CD 自动重新部署

避免的问题： 手动部署的传错、传漏、版本混乱，以及出了问题无法定位是哪次部署导致的。

2.2.2 飞书文档同步

文档写完推送到 Git，团队成员不 clone 仓库就看不到。 飞书是团队日常沟通的地方，把文档同步到飞书，零门槛可访问。

所以我们规定：本地文档更新后必须同步到飞书知识库，同步结果必须汇报，并附带文档链接。

规范内容：

本地文档更新 → 推送到飞书知识库对应节点 → 返回链接汇报。

团队成员不需要 clone 仓库，直接在飞书里点开链接就能看。

解决什么问题：

团队可见性——不装 Git、不 clone 仓库，点开链接就能看
跨平台备份——本地 + Git + 飞书三份，硬盘和代码托管平台崩了也不丢
文档可发现性——飞书搜索比 GitHub 文件名搜索更适合日常使用
协作友好——可以在飞书文档上直接评论和批注

避免的问题： 文档写完没人看，最后变成自娱自乐。

实战注意： 同步操作内容较大时（如长文章），飞书 LLM 可能超时，需要分批写入或调大 agents.defaults.llm.idleTimeoutSeconds 配置。同步完成后必须发链接，不发视为协作失误。

三、用 ai-blog 走一遍完整项目生命周期

下面用这个博客项目本身，演示一个需求从发起到完成的完整流程。过程中的每一步——包括 CI/CD 怎么配置、GitHub CLI 怎么用、飞书知识库怎么同步——都是在 ai-blog 项目里实际用过的，不是一笔带过的概念。

3.1 立项：博客方案选型

一开始我想搭一个个人技术博客，调研了 Hexo、Jekyll、Hugo 三个方案。最后选了 Hexo，原因是：

Node.js 技术栈，单一技术栈优先
主题生态成熟（NexT 主题上手快、配置灵活、生态文档完善）
写作用 Markdown，门槛低
云服务器托管（腾讯云），成本可控
CI/CD 自动化部署（GitHub Actions → FTP → 云服务器）

这个决策过程是临时区需求——调研，给结论，走人。但当决定「要用 Hexo 搭博客」那一刻，项目区就启动了。

立项动作：建立项目上下文，初始化 Git 仓库，搭 Hexo 框架，写 0001 项目设计文档。

3.2 规划：出设计文档 + 配 CI/CD

博客项目的 0001（项目设计）里写了这些核心内容：

项目目标：个人技术博客，输出 AI/编程/量化相关的内容

技术方案：

Hexo + NexT 主题
云服务器托管（腾讯云）
GitHub Actions 做 CI/CD（FTP 部署到云服务器）
双端同步 Gitee + GitHub

文档体系：0001 项目设计 / 0002 技术设计 / 0003 变更日志

这个文档是我和龙虾共同的记忆锚点——它知道我要做什么，我知道它知道。

同时，在规划阶段就把 CI/CD 配好。 GitHub Actions 的配置文件长这样：

# .github/workflows/deploy.yml
name: Deploy to Tencent Cloud via FTP

on:
  push:
    branches:
      - master

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Generate static files
        run: npx hexo generate

      - name: Deploy to server via FTP
        uses: SamKirkland/FTP-Deploy-Action@v4.3.4
        with:
          server: ${{ secrets.FTP_SERVER }}
          username: ${{ secrets.FTP_USERNAME }}
          password: ${{ secrets.FTP_PASSWORD }}
          port: 21
          protocol: ftp
          local-dir: ./public/
          server-dir: ${{ secrets.FTP_SERVER_DIR }}

这个文件放在 .github/workflows/deploy.yml，GitHub 就会在每次 master 分支收到 push 时自动跑这个流程：装依赖 → hexo generate → FTP 上传到云服务器。我只需要在 Git 仓库的 Secrets 里配置好 FTP 账号密码，其他都是自动的。

3.3 执行：文章发布 + CI/CD 追踪

博客文章是项目管理里最常见的任务类型。我们设计了一套完整的文章协作流程，对应协作规范里的「三阶执行」——立项对应规划阶段，发布对应执行阶段，归档对应沉淀阶段。

流程：

立项 → 对应「规划」：告诉龙虾「我要写一篇关于 openclaw一起工作系列的文章」，确认主题、系列归属
创作 → 审核阶段：文章写入 source/_drafts/ 目录，用 hexo server --draft 本地预览
发布 → 对应「执行」：移动到 source/_posts/，执行 git push 触发 CI/CD 部署
归档 → 对应「沉淀」：更新 0003 变更日志，记录发布信息和版本

具体例子：今天上午我发布了《和龙虾协作的基本方式》这篇文章。

需求：「把《和龙虾协作的基本方式》这篇文章发布到博客上」

操作序列：

确认文章在 source/_drafts/series/openclaw一起工作/article-02.md，内容已定稿
把文件移动到 source/_posts/002-和龙虾协作的基本方式.md
更新 frontmatter 的 date、permalink 信息
git add → git commit → git push
GitHub Actions 检测到 push，自动运行 hexo generate → FTP deploy
部署完成后更新变更日志

整个过程我只需要说「帮我发布 article-02」，龙虾会按这个流程走，执行完汇报结果。

CI/CD 跑着的时候，可以随时查状态。 装了 GitHub CLI 之后：

# 查看最近的 CI 运行
gh run list --repo yuanlianxi/ai-blog --limit 5

# 输出样例
in_progress  Deploy to Tencent Cloud via FTP  master  push  2m5s
completed   success  Deploy to Tencent Cloud    master  push  4m23s

不用开浏览器，在终端里就能看到部署状态。「进行中」就说明还在跑，不用盯着。

CI/CD 跑着的时候，可以随时用 GitHub CLI 查状态：

# 查看某个具体 run 的详情
gh run view <run-id>

# 查看某个 job 的日志
gh run view --job=<job-id> --log

CI/CD 跑着的时候，不需要等汇报，直接查就行。

3.4 归档：变更日志怎么写

0003 变更日志是项目的核心记忆文件。每次发布功能或文档，都要更新它。

格式大概是这样的：

## v0.x.x 日期

### 功能更新
- [功能名] 功能描述
  - 变更：xxx
  - 状态：✅已完成

### 文档更新
- [文档名] 更新内容描述
  - 变更：xxx
  - 状态：✅已完成

例子（今天上午的真实记录）：

## v0.4.1 2026-05-08

### 修复
- 系列目录状态修正 - 01链接到02,03-05标为未建设
  - 变更：修改001/002的系列目录
  - 状态：✅已完成

- article-02中01链接改为站内URL
  - 变更：mp.weixin.qq.com → ai-codec.cn
  - 状态：✅已完成

每次对话结束前，龙虾会把当次变更记录进日志。这个动作不需要我提醒——它内置在协作规范里。

3.5 沉淀：飞书知识库同步

项目文档（0001/0002/0003）写完之后，会同步到飞书知识库。

同步前置检查清单：

每次同步前，龙虾会逐项检查：

确认项目根节点存在 — 如不存在，先创建项目父节点
检查本地文档清单 — 确保必选文档（0001/0002/0003）都在
按层级结构创建节点 — 先父后子，确保父子关系正确
每批次操作后汇报进度 — 避免静默失败
如有失败，主动说明 — 列出哪些失败及原因

ai-blog 项目的实际同步记录是这样的：

检查知识库节点是否存在（openclaw一起工作）
确认本地三份文档都在：0001 项目设计 / 0002 技术设计 / 0003 变更日志
按层级创建节点（父节点 → 0001 → 0002 → 0003）
同步完成，汇报链接

同步完成后必须发链接，让协作者能直接访问。这是规范里内置的要求，不发视为协作失误。

重要原则：本地文档是源，飞书是展示窗口。 飞书那边可以看、可以评论，但不能直接编辑飞书版本来更新内容。正确的流程是：本地更新 → 推送 → 同步到飞书。如果在飞书里改东西，需要手动同步回本地，否则时间久了两边会打架。

3.6 AI Blog 项目的实际运行效果

这套规范跑了一段时间之后，ai-blog 的项目管理状态是这样的：

协作规范的效果（对应 2.1 的规范）：

每次变更都有记录，不需要靠脑子回忆（变更日志即时记录）
重大操作先审批，不会做完了才发现方向不对（变更审批规范）
主会话不被长任务卡住，可以继续处理其他需求（子任务规范）

架构型规范的效果（对应 2.2 的规范）：

代码 push 之后自动部署，说一句「帮我发布 article-02」，hexo generate + FTP 上传全自动，不需要人盯着
飞书里直接可以看文档，团队成员不需要 clone 仓库，点开链接就能看
任何一个版本可以回滚，git revert + CI/CD 自动重新部署，不需要手动去服务器改文件

上面演示了用 AI blog 走完一个完整项目。下面说一个实战中特别容易出问题的地方——规范约束为什么不总是生效，以及 CI/CD 跑着的时候怎么追踪状态。

四、经验总结和常见坑

踩过的坑不一一展开，下一篇会从「Harness Engineering 的实践」角度系统讲。这里先列三个最容易出问题的：

拍脑袋给结论 — 没查数据就给结论，结果是错的。教训：三层验证之后才开口。
设计前置跳步 — 先做后说，做完发现方向不对，返工双倍时间。教训：说「可以」才动手。
变更日志不即时记录 — 有空再补，永远没空。教训：顺手记了，这件事才算真正结束。
飞书同步状态不一致 — 飞书 API / 知识库 API / LLM 超时都可能导致同步不完整，产生重复节点或内容覆盖不全。教训：同步后要核对链接指向是否正确，发现重复节点要及时在飞书里手动删除。

下篇（04）从 Harness Engineering 的视角，讲怎么把这些规范内化成自己的工作习惯——需求怎么说、反馈怎么给、上下文怎么积累、边界怎么设计。有问题欢迎留言，下篇见。

补充手段：定时兜底任务

以上四条是主观上「尽量避免」的原则，但实际操作中难免有遗漏。龙虾内置了三个定时兜底机制，作为辅助手段来补全变更日志和追踪项目进度：

每天兜底检查变更记录 — 每天定时检查各项目目录下是否有未记录到 0003 变更日志的变更，发现后补充记录。这解决的是「当时没记录、后来忘了」的问题。
根据会话内容补全变更记录 — 每天定时读取 memory/YYYY-MM-DD.md 中的会话变更记录，将其中涉及项目区变更的内容同步到对应项目的 0003 变更日志。这解决的是「会话里做了但没同步到变更日志」的问题。
第二天汇报前一天的变更记录 — 每天早上（固定时间）自动生成前一天的变更汇报，包含工作区变更和临时区变更两份摘要，发到协作渠道。这解决的是「自己不知道前一天做了什么、项目现在什么进度」的问题。

这三条不是替代变更日志即时记录，而是「最后一道防线」——即使当时没记，第二天醒来也能看到昨天干了什么，不用靠脑子回忆。