我用 OpenClaw 和 Claude Code,做了一个冥想小程序,并把它部署上线

最近 OpenClaw 很火，大家也能明显感受到，各家公司都在推 AI 相关产品。 热度是真的，变化也是真的。

随之而来的，是很多岗位共同的焦虑： 未来会不会被替代？ 我们原本擅长的工作方式，会不会很快失效？

作为产品经理，这种感受其实也很明显。 最近很多工作场景已经在发生变化：

• 用 AI 帮忙做原型

• 用 AI 帮忙整理需求

• 用 AI 帮忙生成方案

• 用 AI 快速做出一个能体验的 demo

以前很多需要自己一下一下手动完成的事情，现在越来越多可以通过 AI 协作来完成。

所以我觉得，真正需要面对的，不是先急着抗拒，也不是一味焦虑， 而是先接纳这个变化，去建立手感，去理解新的工作方式，去判断：当 AI 可以替我们做掉一部分执行之后，我们应该把自己的能力，转向哪里？

这两天，我想验证一件事： 如果不从“大而全”的产品开始，而是先做一个可体验的 demo，能不能更快把一个 AI 产品想法落地？

于是，我拿“冥想小程序”做了实验。 从最初的界面原型，到加入呼吸节奏、声音、打卡，再到最后部署上线，整个过程其实比我想象中更顺。

这篇文章，就把整个过程拆开讲清楚。

一、先别上来就做完整产品，先做一个能体验的 demo

我这次做的，不是一个完整 App，而是一个冥想功能原型。

一开始先明确最小范围：

• 有首页

• 有冥想主题切换

• 有呼吸节奏

• 有开始、暂停、重置

• 有冥想后的感受记录

• 后面再补音乐、提示音和打卡

这一步很重要。

因为很多人做产品 demo 时，上来就想把登录、账号体系、推荐算法、会员体系全做了，最后项目根本起不来。

正确的方法是：先做一个“能感受到产品价值”的最小闭环。

对冥想产品来说，这个闭环就是： 进入页面 → 选择场景 → 开始呼吸 → 听到声音引导 → 完成一次练习。

只要这个闭环成立，demo 就已经有意义了。

二、用 OpenClaw 做执行入口，用 Claude Code 辅助 coding

这次我用的组合是：

• OpenClaw：作为执行入口，帮我读文件、改文件、跑命令、部署项目

• Claude Code：作为 coding 能力补充，帮我更快推进前端原型和交互逻辑

这个组合最大的好处，不是“能不能写代码”，而是： 你不用自己反复切工具、切窗口、切上下文。

你只要把目标说清楚，比如：

• 我想做一个冥想小程序原型

• 我想加背景音乐

• 我想让它更像 App

• 我想上线给手机打开

剩下的事情就可以一层层往下推。

这也是我这次最大的感受： 做 demo，最怕的不是不会写代码，而是过程太碎。 而 OpenClaw 这种方式，能把“想法—执行—验证”串起来。

三、先把静态原型做出来

我们最早先落了一个纯前端静态版本，结构很简单：

• index.html

• styles.css

• script.js

也就是说，它本质上就是一个静态网页 demo。

这样做的好处是：

1. 起步快

2. 修改快

3. 部署也简单

4. 非常适合验证产品感觉

最初这个页面里已经有了：

• 睡前放松、缓解焦虑、恢复专注、自我安抚等主题

• 3/5/10 分钟时长选择

• 4-2-6、4-7-8 等呼吸节奏

• 开始、暂停、重置

• 冥想后的感受输入

到这一步，其实已经不只是“画了个页面”，而是有了一个可操作的高保真原型。

四、部署时不要一上来纠结服务器，静态站点最省事

因为这是纯前端静态页面，所以我一开始就没打算上复杂服务器。

最省事的方案有两个：

• Vercel

• GitHub Pages

我一开始尝试了 Vercel，但中间卡在账号 token 问题。 这个过程反而提醒了我一件事： 做 demo，上线方式越轻越好。

后来直接切到 GitHub Pages，就顺很多。

整个部署路径是这样的：

1）先创建 GitHub 仓库

比如：meditation-prototype

2）本地初始化并 push

核心就是：

• git init

• git add .

• git commit

• git remote add origin

• git push -u origin main

3）打开 GitHub Pages

在仓库里设置：

• Source：Deploy 

• from a branch

• Branch：main

• Folder：/ (root)

然后等几分钟，就能拿到一个公开链接。

这一步特别适合新手。 因为你不需要管 nginx、不需要管 Docker，也不需要买服务器。 只要是 html/css/js 静态项目，GitHub Pages 就足够好用。

五、原型真正“活起来”，关键不是页面，而是声音

这个冥想 demo 真正的难点，其实不在界面，而在声音体验。 因为冥想产品如果没有声音，它很容易显得像一个“死页面”。

所以后面我重点补了三层：

1）背景音乐

先接入音频文件，让点击后可以播放冥想音乐。

中间遇到一个很真实的问题： 最早我拿到的是 .ogg 音频，但手机端兼容性不好，尤其是 iPhone / Safari 环境下容易不播。 后来把它转换成 m4a，兼容性就明显更稳了。

这一步给我一个提醒： 做面向手机的 demo，素材格式别随便用，优先考虑浏览器兼容性。

2）测试声音按钮

因为移动端音频权限很容易被浏览器限制，所以我加了一个“测试声音”按钮。

这个按钮的意义不只是测试，而是： 先把手机浏览器的声音权限解锁。

不然你会陷入一种很痛苦的状态—— 代码看着没问题，按钮也点了，但就是没声音。

3）呼吸提示音和语音提示

为了让整个冥想过程不再死板，我又补了：

• 吸气提示

• 停留提示

• 呼气提示

而且不只是单纯提示音

，还尝试用语音把节奏带起来。 这样用户在体验时，才会真正有“被带着走”的感觉。

六、让 demo 更像产品，而不是只像页面

如果只是能点能播，其实还不够。 一个更像产品的 demo，最好让人感受到“连续使用的价值”。

所以后面我又补了两块：

1）打卡记录

加入了：

• 连续天数

• 累计次数

• 最近一次练习

这部分先用了浏览器本地存储，也就是 localStorage。

为什么这么做？ 因为 demo 阶段，不一定非要上后端。 本地记录已经足够让用户感受到“我在使用它”。

2）更像 App 的外层能力

为了让这个网页在手机上看起来更像 App，我还补了：

• App 图标

• manifest

• theme-color

• 添加到主屏幕支持

这样用户在手机桌面上点开时，就不再只是一个普通网页链接，而更像一个轻量应用。

这一步对产品演示非常重要。 因为用户一旦觉得“这像个产品”，接受度会明显高很多。

七、这次最大的经验：做 demo，先做“能感知价值”的版本

这次做完之后，我最大的感受不是“AI 能帮我写代码”，而是： AI 最有价值的地方，是帮你把 demo 更快推到“可感知”的状态。

什么叫可感知？ 不是页面做完了。 而是用户真的能感受到：

• 它是干什么的

• 它带来的体验是什么

• 它有没有继续使用的可能

比如这个冥想 demo，如果只有页面，没有声音，那就只是个展示页。

但一旦有了：

• 呼吸节奏

• 背景音乐

• 提示音

• 打卡记录

• 手机上像 App 一样打开

它就开始有了“产品感”。 而产品感，往往比功能数量更重要。

八、如果你也想自己做一个 demo，可以直接照这个流程走

第一步：定最小闭环

先想清楚，用户最核心的一次体验是什么。

第二步：先做静态前端

不要一开始就纠结后端和数据库。

第三步：快速上线

静态项目优先 GitHub Pages 或 Vercel。

第四步：补最关键的感知能力

像这个项目里，最关键的不是页面，而是声音。

第五步：加一点产品状态

比如打卡、记录、连续使用反馈。

你会发现，一个 demo 一旦做到这里，已经足够拿去：

• 演示

• 讲产品思路

• 验证用户反馈

• 继续迭代

结尾：对产品经理来说，真正的变化才刚刚开始

写到这里，其实更想说的，不只是“我做出了一个 demo”。 

这次过程让我越来越明确一件事：产品经理的工作方式，真的已经在变了。

以前我们很容易把产品经理的价值，放在这些动作上：

• 写需求文档

• 画原型

• 跟设计、研发反复沟通

• 推动排期、跟进上线

这些能力当然仍然重要。

 但当 AI 已经可以越来越快地帮你：

• 出原型

• 整理需求

• 生成页面

• 写基础代码

• 快速做出一个 demo

产品经理接下来真正要提升的，就不只是“把东西写出来”，而是下面这些更底层的能力。

1）定义问题的能力

以后比“会不会画原型”更重要的，是你能不能定义一个值得解决的问题。

你要能看清楚：

• 用户真正卡在哪里

• 需求背后的真实动机是什么

• 哪个场景最值得先做

• 什么是最小闭环，什么只是噪音

AI 可以帮你加速产出， 但“问题定义得准不准”，仍然决定了方向对不对。

2）把想法快速转成可验证产品的能力

以前很多产品经理只停留在“想明白”和“写清楚”。 但未来越来越重要的一项能力，是：你能不能把一个想法，迅速变成一个可以让别人体验、反馈、验证的东西。

这也是为什么我觉得 coding 这件事，对产品经理越来越重要。

不一定是要成为专业工程师， 但你至少要有能力借助 AI、借助工具，把一个产品想法快速推到 demo 级别。

因为只有当东西真的被做出来，很多判断才会变得具体。

3）与 AI 协作的能力

未来不是“会不会被 AI 替代”这么简单， 更现实的问题是：同样是产品经理，有的人会用 AI，把效率和产出拉开 5 倍；有的人不会。

所以要提升的，不只是工具使用熟练度， 而是：

• 怎么描述目标更清楚

• 怎么拆任务更合理

• 怎么判断 AI 给出的结果能不能用

• 怎么继续追问，直到结果变好

换句话说，产品经理以后很重要的一项核心能力，可能是“调度 AI 的能力”。

4）体验判断力

AI 能生成很多东西， 但它不天然等于“产品感”。

一个页面是否顺手、一个流程是否自然、一个功能是否真的让人愿意留下来， 这些仍然高度依赖人的判断。

所以未来越到后面，越不能只停留在“做出来了”。 而要追问：

• 好不好用？

• 有感觉吗？

• 用户会不会愿意继续用？

• 这个体验里最打动人的点是什么？

5）跨角色整合能力

当 AI 把执行门槛拉低以后，产品经理会越来越像一个“组织者”和“整合者”。

你需要同时理解：

• 用户

• 业务

• 技术

• 内容

• 增长

• 体验

然后把这些东西拼成一个真的能跑起来的产品闭环。

这意味着，未来不是单一技能更重要， 而是你能不能把多种能力整合起来，快速形成结果。

所以回到最开始那个很多人都会焦虑的问题： AI 会不会替代产品经理？

我的感觉是， 它一定会替代掉一部分原本高度依赖手工、重复、低杠杆的工作。 

但它也会把产品经理往一个更高要求的位置推：

你要更懂用户， 更会判断， 更会组织资源， 更会借助 AI 把想法变成现实。

如果只把自己停留在“写文档、画原型、传需求”这一层，焦虑会越来越强。 但如果开始训练自己：

• 定义问题

• 快速验证

• 借助 AI 做 demo

• 提升体验判断

• 建立更强的产品闭环能力

那 AI 反而会变成一个非常强的放大器。

它不是只来替代你的， 也可能是来放大你的。

而我们真正要做的，不是和趋势对抗， 而是尽快进入趋势，找到新的位置。

总结

这次用飞书对话、连接 OpenClaw、再配合 Claude 模型，把一个 demo 一路做出来， 就是一次很具体的感受：未来的产品工作，不一定更轻松，但一定会更快，也更要求判断力。

所以与其一直焦虑“会不会被替代”， 不如先从一个小 demo 开始。

先上手， 先建立手感，让自己进入这个新的工作方式里。

很多答案，不是在旁边想出来的， 而是在真正做过一次之后，才会慢慢清楚。

<End>