TOPIC / RESOURCE
OpenClaw + Claude Code 工作流：一个负责运行系统，一个负责把技能做出来
如果你已经知道 OpenClaw 和 Claude Code 不该做一模一样的事，这一页会继续往下讲两者实际配合的完整工作流细节：技能开发中怎么分工、项目目录结构怎么组织、开发调试验证和发布的顺序怎么收稳，以及日常协作中哪些环节更适合交给哪个工具来处理。
适合谁
- 已经知道 OpenClaw 和 Claude Code 不该拿来做一模一样的事
- 想把技能开发、调试、验证和发布串成稳定工作流
- 希望有一页把分工、项目结构和验证顺序讲清楚
先把分工说死，不要把它们当成同一类工具
如果说 OpenClaw 更像持续运行的系统，那么 Claude Code 更像按需出手的开发助手。前者偏运行，后者偏开发。把这层说清，工作流就顺了。
什么时候该让 Claude Code 出手
更适合让 Claude Code 出手的任务包括：
- 写 Skill 代码
- 查 bug
- 重构脚本
- 补测试
- 写验证脚本
- 收项目结构
这些任务的共同点是：
它们更像开发工作，而不是持续运行服务本身。
什么时候该留给 OpenClaw
更适合留给 OpenClaw 的任务包括：
- 日常执行
- 长期任务链
- 渠道收发
- 定时任务
- 多 Agent 协作
- 工作区沉淀
一个更顺手的配合顺序
OpenClaw + Claude Code 工作顺序
1. 先在 OpenClaw 里确定要解决的任务
2. 再让 Claude Code 帮你把 skill / 脚本 / 配置做出来
3. 再回到 OpenClaw 里接入、验证和运行
4. 最后用日志、测试和发布流程把它收稳
技能项目最小结构，先别做花
蓝皮书里最值得直接拿走的一点不是“加速倍数”，而是技能项目结构应该尽早规整。
skill-project/
├── SKILL.md
├── index.js
├── tools/
├── tests/
└── docs/
它真正解决的是：
- 入口文件放哪里
- 文档放哪里
- 测试放哪里
- 项目以后还能不能维护
一条更稳的技能开发顺序
技能开发顺序
1. 先写最小可运行结构
2. 先保证参数和错误处理清楚
3. 先补正常 / 边界 / 错误三类测试
4. 再跑 validate
5. 最后再考虑 publish
一份够用的发布前清单
npm test
openclaw skill validate
openclaw skill publish
这三步的意义不是“形式完整”，而是避免下面几种最常见的问题直接进生产：
- 参数校验没做好
- 错误提示太难懂
- API key 被硬编码
- 入口文件和文档结构不一致
这类工作流最容易踩的 4 个坑
坑 1：把 Claude Code 也当成运行系统
它更适合干开发任务，不适合替代 OpenClaw 的长期运行能力。
坑 2：跳过测试，直接把“看起来能跑”的 skill 装进去
第一次最容易出的问题不是功能缺失，而是错误输入和边界场景直接打穿。
坑 3：把 API key 写死在项目里
这类错误一旦进仓库，后面清理成本会非常高。
坑 4：没有中文可读的错误信息
调试阶段你可能看得懂，到了真实工作流里，队友和用户未必看得懂。
如果你现在就想开始
这条路径最值的切入点通常是：
- 先读 OpenClaw vs Claude Code
- 再决定要不要做自己的 Skill
- 如果要做，再把项目结构和验证顺序按这页收住
官方文档 / 延伸阅读
相关链接
FAQ
本页常见问题
对比页解决的是定位判断；工作流页解决的是实际怎么配合做事，尤其是技能开发、调试、验证和发布。
价值会下降。它最适合准备做 Skill、做自动化工程、做运维脚本或长期开发工作的用户。