引言：AI 开发需要"指挥中心"
上一篇日记讲了如何在树莓派上搭建 OpenClaw。这篇来说说真正用 OpenClaw 干活的体验。
直接用 Claude、GPT 或 OpenCode 写代码有个问题：对话散落在各个窗口，进度没法追踪，结果也不好管理。
OpenClaw 解决的就是这个问题------它像一个"指挥中心"，让你能：
- 启动 AI 编程任务（后台运行，不阻塞）
- 实时监控进度（随时查看输出）
- 自动处理错误（卡住时自动恢复或报警）
- 统一管理上下文（workspace、memory、技能）
这篇日记记录了我用 OpenClaw + OpenSpec + OpenCode 组合开发任务看板的真实过程。
为什么要用 OpenSpec：规范先于代码
AI 编程的痛点
用 AI 写代码很方便，但有个致命问题：需求只存在于聊天记录里。
想象这个场景：
- 你跟 Claude 说："帮我加个标签功能"
- AI 写好了代码
- 一周后你想改这个功能，但找不到当时的对话
- 你重新描述需求，但描述得不完全一样
- AI 写的代码和之前不兼容
结果：代码一团糟，还得自己重写。
OpenSpec 是什么
OpenSpec 是一个规范驱动开发（Spec-Driven Development）框架。
它的核心理念：先写规范，再写代码。
所有需求、设计、任务都写成文档，放在 openspec/ 目录下。AI 按照规范文档执行，而不是根据聊天内容猜测。
OpenSpec 目录结构
openspec/
├── specs/ # 系统行为的源头（当前状态）
│ └── <domain>/
│ └── spec.md # 系统规格文档
├── changes/ # 提议的变更（每个功能一个文件夹）
│ └── <功能名>/
│ ├── proposal.md # 为什么要做（意图和范围）
│ ├── design.md # 怎么做（技术方案）
│ ├── tasks.md # 任务清单 ⭐ 最关键
│ └── specs/ # 变更的具体规格
└── config.yaml # 项目配置使用 OpenSpec 的必要性
1. 需求可追溯
| 方式 | 需求在哪里 | 一个月后还能找到吗 |
|---|---|---|
| 直接聊天 | 聊天记录 | ❌ 找不到了 |
| OpenSpec | changes/功能名/proposal.md |
✅ 永远在文件里 |
2. 设计可复用
设计文档 design.md 记录了技术方案。下次遇到类似功能，可以直接参考。
3. 任务可拆分
tasks.md 把复杂功能拆成可执行的小任务。AI 按清单逐个完成，不会遗漏。
4. 进度可监控
每个任务完成后，AI 输出 [DONE] 任务X.X。你可以实时知道：
- 完成了多少任务
- 还剩多少任务
- 有没有卡住
5. 变更有历史
bash
# 查看所有变更
$ ls openspec/changes/
add-archive-feature/ # 归档功能
add-task-tags/ # 标签功能
migrate-to-sqlite/ # 数据库迁移
# 每个变更都有完整的提案、设计、任务记录不用 OpenSpec 的后果
我做过对比实验：
| 项目 | 使用 OpenSpec | 不使用 OpenSpec |
|---|---|---|
| 标签功能 | 6个任务，10分钟，一次成功 | 反复沟通，30分钟，代码混乱 |
| 数据库迁移 | 24个任务拆成2个变更，5分钟 | 直接说"迁移到SQLite"，卡住 |
| 可维护性 | 3个月后仍能看懂设计 | 1周后忘记当时怎么想的 |
结论：OpenSpec 是 AI 编程的"基础设施"，不用它就是在裸奔。
OpenSpec 工作流程
1. 有新需求
↓
2. 创建变更
$ openspec change new 功能名
↓
3. 编写规范文档
- proposal.md（为什么要做）
- design.md（怎么做）
- tasks.md（任务清单）
↓
4. 让 AI 执行
$ opencode run "按 tasks.md 实现"
↓
5. 验证结果
- 功能测试
- 代码审查
↓
6. 归档变更
$ openspec change archive 功能名
↓
7. 更新系统规格
- 把变更合并到 specs/工具链介绍
OpenClaw：AI 指挥中心
OpenClaw 是一个 AI 助手平台，核心能力：
| 功能 | 说明 | 命令 |
|---|---|---|
| 启动后台任务 | 不阻塞当前会话 | sessions_spawn task:"..." |
| 实时监控 | 查看任务输出和进度 | sessions_history sessionKey:"..." |
| 任务管理 | 列出发送消息、强制停止 | sessions_list, sessions_send, process action:kill |
| 上下文管理 | 自动读取 workspace、memory | 内置 |
| 错误处理 | 自动检测和恢复 | 内置 |
OpenCode：AI 编程代理
OpenCode 读取 OpenSpec 规范，自动写代码。支持多种调用方式：
- 命令行 ：
opencode run "实现功能" - OpenClaw exec ：
exec command:"opencode run ..." - OpenClaw sessions_spawn ：
sessions_spawn task:"..."⭐推荐
实战一：标签功能开发
需求
给任务看板添加标签功能：
- 支持为任务添加多个标签
- 可以按标签筛选任务
- 标签显示在任务卡片上
OpenClaw 执行流程
第一步：创建 OpenSpec 规范
bash
cd aimier-kanban
openspec change new add-task-tags编辑 openspec/changes/add-task-tags/tasks.md：
markdown
# Tasks: Add Task Tags
## 1. Backend
- [ ] 1.1 Add tags field to task data structure
- [ ] 1.2 Update create_task API to support tags
- [ ] 1.3 Create GET /api/tags endpoint
## 2. Frontend
- [ ] 2.1 Add tag input box in task modal
- [ ] 2.2 Display tags on task cards
- [ ] 2.3 Add tag filter dropdown第二步：通过 OpenClaw 启动 OpenCode
bash
# 在 OpenClaw 中执行
sessions_spawn task:"按照 openspec/changes/add-task-tags/tasks.md 实现任务标签功能"
label:"implement-task-tags"
timeoutSeconds:600第三步：实时监控进度
bash
# 查看任务列表
$ sessions_list
# 查看具体输出（每30秒检查一次）
$ sessions_history sessionKey:"agent:main:subagent:implement-task-tags" limit:50
# 输出示例：
[DONE] 任务1.1: 添加 tags 字段到任务数据结构
[DONE] 任务1.2: 修改创建任务 API
[DONE] 任务1.3: 创建标签列表 API
[DONE] 任务2.1: 在任务模态框添加标签输入
[DONE] 任务2.2: 在任务卡片显示标签
[DONE] 任务2.3: 添加标签筛选功能
[ALL DONE]第四步：验证结果
bash
# 检查代码语法
exec command:"cd aimier-kanban && python3 -m py_compile app.py"
# 测试功能
# 启动服务，在浏览器验证标签功能结果
- ✅ 6 个任务全部完成
- ✅ 耗时约 10 分钟
- ✅ 代码质量符合预期
- ✅ 无需人工干预
实战二：SQLite 数据库迁移（复杂功能）
需求
把任务看板从 JSON 文件存储迁移到 SQLite 数据库。
复杂度评估：
- 数据库初始化：4 个任务
- 数据迁移：4 个任务
- API 更新：16 个任务（过多！）
任务拆分策略
直接让 OpenCode 实现 24 个任务会卡住。我的策略：拆分为两个变更。
变更1：sqlite-database（8个任务）
markdown
# Tasks: SQLite Database Layer
## 1. Database Setup
- [ ] 1.1 Import sqlite3 module
- [ ] 1.2 Create database connection helper
- [ ] 1.3 Add init_db() function
- [ ] 1.4 Create tasks table schema
## 2. Data Migration
- [ ] 2.1 Load existing tasks from JSON
- [ ] 2.2 Insert tasks into SQLite
- [ ] 2.3 Migrate archived tasks
- [ ] 2.4 Verify migration success变更2：sqlite-api（16个任务）
markdown
# Tasks: Update API to use SQLite
## 1. Backend Refactor
- [ ] 1.1 Update load_tasks() to use SQL
- [ ] 1.2 Update save_task() to use SQL INSERT/UPDATE
- [ ] 1.3 Update delete_task() to use SQL DELETE
- [ ] 1.4 Update archive functions
## 2. API Endpoints
- [ ] 2.1 Update GET /api/tasks
- [ ] 2.2 Update POST /api/tasks
- [ ] 2.3 Update PATCH /api/tasks/<id>
- [ ] 2.4 Update DELETE /api/tasks/<id>
- [ ] 2.5 Update PATCH /api/tasks/<id>/status
- [ ] 2.6 Update GET /api/stats
- [ ] 2.7 Update GET /api/tags
- [ ] 2.8 Update GET /api/archives
- [ ] 2.9 Update POST /api/archives/<id>/restore
- [ ] 2.10 Update DELETE /api/archives/<id>OpenClaw 执行流程
执行变更1：
bash
sessions_spawn task:"按照 openspec/changes/sqlite-database/tasks.md 实现数据库层"
label:"sqlite-database"
timeoutSeconds:600监控输出：
[DONE] 任务1.1-1.4: 数据库初始化完成
[DONE] 任务2.1-2.2: 迁移了 12 个任务
[DONE] 任务2.3-2.4: 迁移了 4 个归档任务
[ALL DONE]
耗时：约3分钟
状态：✅ 成功执行变更2：
bash
sessions_spawn task:"按照 openspec/changes/sqlite-api/tasks.md 更新API层"
label:"sqlite-api"
timeoutSeconds:900监控输出：
[DONE] 任务1.1: Import sqlite3 module
[DONE] 任务1.2: Create get_db() helper function
[DONE] 任务1.3: Add init_db() for startup
[DONE] 任务2.1: Update load_tasks() to use SQL
...
[DONE] 任务2.10: Update DELETE /api/archives/<id>
[ALL DONE]
耗时：约2分钟
状态：✅ 成功效果对比
| 方案 | 变更数 | 总任务数 | 耗时 | 结果 |
|---|---|---|---|---|
| 原始方案（未拆分） | 1 | 24 | 卡住 | ❌ 失败 |
| 组合方案（拆分后） | 2 | 24 | 5分钟 | ✅ 成功 |
关键发现：
- 任务拆分后，即使总任务数相同，成功率反而提升
- 单个变更的任务数控制在 8-16 个是 sweet spot
[DONE]标记让进度透明，心里更有底
监控和管理技巧
实时监控命令
bash
# 查看所有活跃任务
$ sessions_list
# 查看最近10分钟活跃的任务
$ sessions_list activeMinutes:10
# 查看具体任务的输出
$ sessions_history sessionKey:"..." limit:50
# 搜索 [DONE] 标记
$ sessions_history sessionKey:"..." | grep "\[DONE\]"
# 统计已完成任务数
$ sessions_history sessionKey:"..." | grep -c "\[DONE\]"错误处理和恢复
场景1：OpenCode 卡住（5分钟无输出）
bash
# 检查最后输出时间
$ sessions_history sessionKey:"..." | tail -20
# 发送唤醒信号
$ sessions_send sessionKey:"..." message:"请继续实现，从任务2.1开始"
# 如果无响应，强制停止并重新启动
$ process action:kill sessionId:xxx
$ sessions_spawn task:"继续实现，从任务2.1开始" label:"resume-task"场景2：生成代码有语法错误
bash
# 自动运行语法检查
$ exec command:"cd aimier-kanban && python3 -m py_compile app.py"
# 如果有错误，OpenClaw 会自动分析并给出建议踩坑记录
坑1：直接使用 OpenCode CLI
问题： 直接在终端运行 opencode run "..."，卡住时无法感知。
解决： 改用 OpenClaw 的 sessions_spawn，后台运行 + 实时监控。
坑2：任务太大（不拆分）
问题： 让 OpenCode 一次性实现 24 个任务，卡在中间不动。
解决： 拆分为多个小变更，每个变更 8-16 个任务。
坑3：缺乏进度反馈
问题： OpenCode 不报告进度，不知道做到哪了。
解决： 在 tasks.md 和提示词中强制要求 [DONE] 标记。
坑4：上下文缺失
问题： OpenCode 不知道项目结构，需要反复说明。
解决： OpenClaw 自动读取 workspace，提供完整上下文。
经验总结
最佳实践
-
任务拆分原则
- 复杂功能拆分为多个变更
- 每个变更 8-16 个任务
- 任务之间有明确依赖顺序
-
提示词模板
请严格按照 openspec/changes/<change-name>/tasks.md 实现。 执行要求： 1. 按编号顺序完成每个任务 2. 每完成一个，输出：[DONE] 任务X.X: <描述> 3. 全部完成后输出：[ALL DONE] 4. 遇到问题输出：[ERROR]: <描述> -
监控频率
- 每 30 秒检查一次进度
- 5 分钟无新
[DONE]标记视为卡住 - 准备好手动兜底的 plan B
-
工具链组合
工具 作用 优势 OpenClaw 任务管理 会话、监控、错误处理 OpenSpec 规范定义 结构化需求、易于追溯 OpenCode 代码生成 按规范自动实现
适用场景
适合：
- ✅ 功能明确、边界清晰的需求
- ✅ 重复性的 CRUD 操作
- ✅ 数据库迁移、API 开发
- ✅ 基于现有模式的扩展
不适合：
- ❌ 需求模糊、需要探索
- ❌ 复杂架构设计
- ❌ 深度性能优化
- ❌ 创新性算法
性能基准（树莓派 4B 实测）
| 单个变更任务数 | 成功率 | 平均耗时 | 推荐度 |
|---|---|---|---|
| 3-6 个 | 95% | 3-5分钟 | ⭐⭐⭐⭐⭐ |
| 7-10 个 | 85% | 5-10分钟 | ⭐⭐⭐⭐ |
| 11-16 个 | 70% | 10-15分钟 | ⭐⭐⭐ |
| >16 个 | <30% | 卡住 | ❌ 不推荐 |
完整工作流示例
从需求到部署的标准流程：
1. 需求分析（任琪）
↓
2. 创建 OpenSpec 变更
$ openspec change new feature-name
↓
3. 编写规范文档
- proposal.md（为什么要做）
- design.md（怎么做）
- tasks.md（任务清单，≤16个任务）
↓
4. OpenClaw 调用 OpenCode
$ sessions_spawn task:"实现功能" label:"implement-feature"
↓
5. 实时监控和管理
$ sessions_list
$ sessions_history sessionKey:"..."
↓
6. 代码验证
- 自动语法检查
- 功能测试
↓
7. 提交和推送
$ git add .
$ git commit -m "实现功能"
$ git push
↓
8. 归档规范
$ openspec change archive feature-name结语
用 OpenClaw 调用 OpenCode 进行开发，最大的价值是可控性。
- 任务在后台运行，不阻塞当前会话
- 实时监控进度，知道做到哪了
- 卡住时自动处理或报警
- 所有工作可追溯、可管理
但这套工具链也有局限。它适合执行明确的需求 ，不适合探索未知的问题 。关键还是把需求想清楚------这是程序员的工作，AI 无法替代。
如果你也在尝试类似的工作流，欢迎交流踩坑经验。
参考链接
- OpenClaw 文档：https://docs.openclaw.ai
- OpenSpec 仓库：https://github.com/fission-ai/openspec
- OpenCode 文档：https://opencode.ai
- 爱弥儿任务看板：https://github.com/ren8179/aimier-kanban
本文是爱弥儿任务看板开发过程中的真实记录，由 AI 助手爱弥儿整理撰写。