用 OpenClaw 做个小项目：惊喜与踩坑全记录
过年前 OpenClaw 火了一把。正好过年假期有点闲暇，便体验了一下它和 Claude Code 有什么区别。过年假期最后一天，总算用它把想做了很久的小功能完成了。
从「改一段代码」到「下一个指令」
如今 AI Coding 的形态已悄然改变——从前是在编辑器里让 AI 改一小段代码，如今是在命令行里下达指令，AI 在后台默默干活，时不时来问一句「我可以这样做吗」，你点头，它继续 。做一个新需求、修一个 bug，不需要精确定位到代码行，只需描述想要什么。
Claude Code 是这种模式的开创者。它面向企业，主打安全可靠，默认设计偏向保守— —会反复确认，生怕误删用户内容。
OpenClaw 则更像一个兴趣驱动项目。它的核心理念是：让 AI 自己做更多决策，别什么事都来问用户。另一个有趣的特点是把 IM（聊天软件）接入 AI，这样你不需要守在电脑前，在手机上发条消息就能驱动 AI 干活。
当然它还有更强大的能力——比如可以创建一个 AI 军团，多个 AI 分工协作。不过我还没用到那么深，先从一个小项目练手。
我的小项目：把播客变成可检索的知识库
我听播客有个困扰：节目前半段提到的 reference，听后半段时就忘了；节目中提到的各种链接、来宾信息，根本来不及记。
所以我想要的是：听完之后能快速回顾要点、定位引用来源，把「播 客内容」变成可检索的知识库。
系统架构：一套流水线 + 批处理能力
核心流程是四步：
- 下载：从小宇宙下载指定节目
- 转写：本地用大模型转写成文字
- 总结：用大模型做总结，抽出关键观点与 reference
- 同步：把结果同步到一个线上空间，方便随时回看
后续我加了批量处理：可以把一组节目列表一次性丢进去，系统会持续监控、自动下载，也能回溯下载很久之前的多期内容，然后批量转写与总结。
OpenClaw 上手的惊喜
安装后配置好，能在手机上发指令，用了半天。
第一个惊喜：效率。从我给出指令，到 OpenClaw 完成上面描述的小项目的第一个版本，一共只花了6分钟。这效率让我有点惊讶，而且主要功能测试下来是可用的！
第二个惊喜：它可以自己配置自己：配置连接到即时通信软件，我只是给了指令，配置修改是它自己做的。
第三个惊喜：移动端真的能有产出！上面一半的事情我是在手机上做的，可能只是在等年夜饭，在晒太阳的闲暇，只要你有想法，下达一个指令，它就能跑，不需要等回到家再做，因为经常回到家早就把这件事忘了。
我踩过的坑：把 AI 串进多步骤流程后，可控性会下降
第一版我把它做成一个 OpenClaw 的 skill：里面有脚本负责下载、转写；总结则用 OpenClaw 内置的 summarize 能力。
但问题出在”步骤一多，变量就多”。总结质量波动明显：有时结构完整，有时遗漏 reference，有时输出格式不稳定。这种不稳定, 导致这套系统最终没有达到可用的阈值。
当然这个锅也不该完全由 OpenClaw 背，因为架构设计可能对它要求太高了。或者说需要显式地先和它讨论清楚架构，再做实现。所以第二版当我让它对第一版的实现提建议，和它做了详细的讨论，它就能提议做一个更稳定的架构。
以下是根据我踩过的坑，总结出的最佳实践。他们不仅限于 OpenClaw，其实他们可以用于所有的 AI 编程工具。
经验一：先让 AI 评审自己的作品，再改进
第一次做，它只有 prompt，做得不够好；第二次做，它已经有个可运行的工程，评审这个工程的实现更容易给出有效建议。让 AI 面对一个具体可评审的产物，比空对空讨论 prompt 效果好得多。
经验二：专人专职，别让一个 AI 干所有的活
上面的例子里：做总结的是一个 AI，调度步骤 1234 的是一个 AI，把自然语言指令转换成步骤的也是一个 AI。
但这些角色本质不同：
- 总结 固定输入输出，适合用模板，工具属性强
- 调度步骤 顺序清晰，几乎不需要智能
- 指令翻译 需要理解意图，有管理属性
所以要拆开：总结功能固化为 prompt + API 编排；组合逻辑用流程代码；指令翻译用 AI Skill。
结果就是：第一版是一个厚重的、带代码片段的 Skill；第二版是本地可直接运行的工具，加上薄薄的 Skill Wrapper。远程让 AI 操作工具，本地直接上手用工具，各司其职。
经验三：把 AI 当成初级工程师带，效果会明显提升
我观察到：很多 AI（包括表现不错的模型）并不会自动补齐你默认会做的工程步骤，比如写文档、写测试、做边界条件、更新变更记录。
如果你希望它按工程化方式产出，就需要把要求写清楚，像带一个初级工程师那样拆任务与验收标准。
对我有效的一套流程是：
- 先让它给出 planning，尽量细到步骤与风险点
- 我确认方向后再让它实现，避免它”先写再说”
- 先设计 test cases，再写实现
- 测试跑通后，把关键设计与用法写回项目文档，保证以后能捡起来
即使模型的”代码分数”未必最高，只要协作流程清晰，产出仍然可以达到非常高的可用度。
经验四：让项目自解释，能显著降低”重新捡起来”的摩擦
我很喜欢 Claude 的 /init 那种”先读取项目上下文再开始工作”的体验，于是我也把类似习惯写进项目规范：
- 进入工作目录先看是否存在项目说明（例如 OpenCLAW.md）
- 每做完一个阶段，把变更与下一步更新回这个说明
现在项目还小，收益已经能感觉到；等项目变大，这种”持续维护上下文”的价值会更明显。
当天的一个小插曲
今天我还听了一期播客，重轻老师在讲他使用 OpenClaw 的过程里遇到的各种问题。
他说他就像在带一个小孩写作业，一边生气，一边又被它的进步惊到。
这个描述太精准了。我完全能想象那种割裂感——AI 能完成看起来很难的任务，却在看起来很简单的地方栽跟头。像到了一个新世界，曾经的经验失效了，你无法预测下一件事会怎样。
作为一个日常工作就是设计软件用户体验的人，听他讲这些收获很大：很多时候「不会写代码的人」遇到的难点，其实来自预期管理，而 不是模型本身够不够聪明。这个提醒非常实用。
结尾
这是最好的时代，也是最差的时代。AI 每天都在革命某个行业。有的是真的会改变社会，有的只是用来讲故事。
还是那句话：亲手试试呗。
Ricky
22 Feb 2026
