Product Manager 4.0 — How I Vibe Code with Claude Code

这一期我们来聊一聊Vibe Coding 毒舌产品经理之前分享过了 现在已经迭代到了4.0版本 那上一期我手搓了一个开源的龙虾 叫做Forge 本来以为大家会关心项目本身 没想到问我最多的居然是开发过程 所以这一期 我就把我Vibe Coding的方案 完整的给你拆解一遍 而且还会现场开发一个写小说的agent 当做演示 那我们话不多说

现在开始 产品经理4.0 这套方案核心是三层架构 顶层规则技能体系加上进化系统 顶层规则就是CLAUDE.md

顶层规则就是CLAUDE.md 它定义了整个团队的角色和工作流程 技能体系一共有8个skill 覆盖了产品开发的完整链路 Product Spec Builder负责需求收集 design brief builder负责写设计规范 design maker画设计图 Dev planner做开发计划 Dev builder写代码 bug fixer修bug

code reviewer做代码的审查 release builder负责构建发布 每个skill都是独立的 有自己的触发条件和执行流程 其中bug fixer我要单独说一下 它不是那种看到报错就试着改的方式 而是一套四阶段的系统性调试方法 先收集证据 再分析模式 然后提出假设并且验证

最后才是实施修复 核心原则就是一个不猜测 没有证据的时候不下结论 一次只改一个地方 改完还要回归验证 确保修了a不会破坏b 在执行层面 我们有4个subagent implementer负责写代码 code reviewer负责审查 feedback observer负责 记录反馈 evolution runner负责扫描反馈

生成进化建议 这里有一个很重要的原则SUB agent隔离 每个task都用一个全新的实例 不复用不继承之前的上下文 为什么呢 因为如果让agent带着之前task的记忆 去做下一个task 那前面的错误假设 就可能污染后面的判断 隔离 才能保证每个task的执行都是干净的 接下来说hooks

光靠自然语言 让AI自己决定什么时候该做什么 是不靠谱的 所以我们设计了一套hook机制来兜底 举几个例子 Pre commit check 这个hook 每次会在commit之前自动跑一遍 编译检测 编译不通过就直接阻止 commit auto push则是commit成功之后 自动推送到远程仓库 不用你手动操作

stop gate会在agent准备停下来的时候 检查代码改了 但是如果没有code review的话 那就不让你停止 必须先审查完 还有detect feedback signal 它会自动检测用户消息里面 有没有修正 或者是不满意的关键词 如果检查到了 它会提醒主agent去记录反馈 这意味着反馈记录是半自动的

很多时候甚至你自己不需要专门说 记下来系统自己就会捕捉到 最后是进化系统 这套方案不是用完了就结束了 它会越用越好 进化分为四层 第一层用户给反馈 系统静默记录 第二层同一条反馈出现3次以上 他就会让他毕业升级 成为skill里面的正式规则

第三层 如果某个skill的反馈评分持续偏低 系统会提议优化这个skill 第四层当某个操作模式反复出现 但是没有skill覆盖 那系统会提议创建一个全新的skill 整个过程对用户是无感的 记录和扫描都在后台完成 只有生成了具体的建议的时候 才会轻轻的提示你

而且每条建议都需要你确认才会执行 绝对不会自动改规则 这就是产品经理4.0的整体架构 简单来说 skill管流程 agent管执行 hook负责兜底 进化管成长 理论部分其实讲的已经差不多了 接下来我们直接上手实操 我以前出过一期视频 用skill和agent编排来写短篇小说 当时

还做了一套现代言情的写作技能包 这次 我们就拿这套技能包当AI的agent原型 用产品经理4.0 把它开发成一个桌面端的短篇小说 写作agent 首先在终端中启动Claude Code 然后在文件树中 创建一个.claude 的系统文件夹

创建一个.claude 的系统文件夹 这是我准备好的产品经理4.0配置文件 包含所有的agents和skill 全选后导入到.claude 文件夹下

全选后导入到.claude 文件夹下 整个配置就完成了 接下来我们看看导入了什么 点开 CLAUDE .md，这是整套方案的顶层规则

.md，这是整套方案的顶层规则 在里面我定义了它的角色 以及8个任务 每个任务都有对应要调用的skill 下面还有完整的文件结构 导入后可以照着检查一下是否有缺失 这里要注意 文件的目录层级 必须和结构定义保持一致 比如skills要放在skill文件夹 下agents要放在agents文件夹下

一定要注意 否则会报错 再来看EVOLUTION .md，这个文件定义的是进化规则

.md，这个文件定义的是进化规则 解决了三个问题 第一我们在使用过程中反馈的问题 怎么被沉淀下来 第二这些反馈怎么升级成正式规则 去优化现有的skills 第三当反复出现新场景的时候 是否需要自动生成新的skill 那具体怎么运作 后面在实际使用的时候你会看到 好那我们快速启动一下

看看配置是否正确 OK启动成功 到这里产品经理4.0 这套开发流程就配置完成了 你开发一个agent 得先告诉他这个agent是做什么的 流程怎么走 那最好的方式 就是 直接给他一个跑通的skill编排方案 当做参考 这样他不是从零开始猜你要做什么 而是基于一个已经验证过的工作流程 来设计这个产品 我这里有一个现成的

之前写的写现代言情小说的skill 当然 你从0开始构思产品的功能和流程 也可以这个看你 但我还是建议你 用之前跑通的skills agents编排 直接拿来当产品原型 每一套跑通的编排 其实本身就是一次产品的验证 我们先创建一个新的文件夹 名字随便取 我这里叫Xianyan

这是写现代言情小说的skills的技能包 里面包含了SKILL.md 技能文件

里面包含了SKILL.md 技能文件 写作方法论 还有模板示例等等 把这些文件复制 然后导入到现言这个文件夹下 我们点开 CLAUDE .md，可以看到整个写作技能包的顶层规则

.md，可以看到整个写作技能包的顶层规则 这套方案的定位 就是帮助用户 完成 现代言情短篇小说的完整的创作流程 然后我们来点开 SKILL .md，这是这套技能包的技能文件

.md，这是这套技能包的技能文件 接下来我开始输入需求 我希望用Claude Agent SDK 来开发一个桌面端的短篇小说创作 agent并且以刚才上传的现言技能包 作为项目的原型 来设计这款产品 那你可能会问我用LangChain行不行 或者其他的agent框架行不行 当然可以 你甚至还可以开发网页

这个完全看你 可以看到他开始调用Product Spec Builder 这个skill来向我了解产品的具体细节 他向我发起了第一轮询问 这个产品是只支持现代言情这个题材 还是要加载不同题材的技能包 还有我们的目标用户是谁 那我的回答是 这个产品是给我自己用的 并且需要支持加载不同题材的技能包 第二轮

他问我产品的交互方式是对话式 面板式还是编辑器形式 那我的回答是 对话式和编辑器形式的结合是最好的 紧接着第三轮 他开始问产品的布局 和技能包管理的操作流程 那我告诉他 我需要一个技能包的管理面板 每个技能包对应一个题材 操作上需要有一个编辑器或者写作台

同时还要有一个文件树 可以浏览我所有的文档 总的来说 我要做的 就是一个 更贴合创作者使用习惯的写作工作台 第四轮他问了我关于操作路径的想法 从零开始写一部小说 到最终完成 整体路径应该是怎样的 那我告诉他 直接按照我上传的 那套现代言情小说的技能包 里面的工作流程就可以了

接着是最后一轮 他问了两个问题 项目管理方面 是否需要一个工作台或者项目列表 技能包管理方面 管理面板是做独立的页面 还是嵌在左侧的侧边栏里面切换 我的回答是 项目管理需要一个项目列表 技能包管理也需要一个独立的页面 另外编辑器部分 我还是需要一个文件树 加一个Markdown编辑器

方便管理和编辑技能包的配置文件 到这里所有问题都问完了 他现在已经有了足够的信息 可以开始帮我生成产品需求文档了 OK他写完了 我们来看一下他都写了什么 可以看到 这是一份非常完整的 面向AI的产品需求文档 注意这里很重要的点是 这份文档是给AI看的 不是给我们人看的

在AI能力需求这部分 我们重点关注多轮对话 上下文管理结构生成 指令理解与流程控制 这些都是agent的核心工程能力 不过产品需求文档不是一蹴而就的 我们也可以随时继续补充 比如我这里 再次调用了Product Spec Builder这个技能 这会让我们进入到迭代模式 那我告诉他 我希望加一个Claude Code

订阅账号登录的功能 他收到需求后不会马上回答 而是先上网搜索 确保信息是最新的 他告诉我 Anthropic最新的规定 已经禁止了第三方应用中 使用订阅账号登录了 好吧那 我就让他加上国产模型的调用 像GLM、Kimi这些国产模型 其实都已经有了官方的兼容端点

紧接着他又问了我一轮问题 模型适配的范围仅限国产模型 还是所有支持 OpenAI 兼容格式的 API 都能接入 对话区 是否只负责交流引导 而生成的内容是写入编辑区 因为这是第一版 所以我告诉他 只适配 GLM、MiniMax、Kimi这几家就可以了 然后

再加一个custom API的自定义接入功能 对话流程方面 与AI对话只用于交流和流程引导 真正的内容产出 是在中间的编辑区完成的 需求明确后 他开始修改产品的需求文档了 绿色部分就是新增的内容 变更完成后 它不仅会更新产品需求文档 同时还会生成产品的变更记录

那我们打开看一下 通过刚才这轮对话 它已经帮我们新增了7个功能点 并且修改了5个需求 需求文档搞定了 但是你会发现 光有需求的描述是不够的 你告诉AI我要深色主题极简风格 可是他能给你搞出十几种不同的理解 所以我们需要一份设计规范 把视觉方向配色布局交互风格 这些东西全部都定下来

让AI在画设计图和写代码的时候 有一个统一的标准和对齐方法 设计方面 我们有两个skill design maker负责生成设计图 design brief builder 负责生成设计的规范文档 我们先从设计规范文档开始 它的原理和Product Spec Builder是一样的 通过追问来了解需求 他先问我产品定位更接近哪款产品

比如是notion还是Linear 我觉得我们这次要设计的 应该更像notion一些 然后配色方案 我选择了深色模式 因为写作类的产品 用户需要长时间的盯着屏幕 深色主题对眼睛更友好 接着是点缀色 点缀色决定了产品的性格 我选择的是中性低调 尽量减少色彩干扰

再往下他问文档的结构 是要Markdown编辑器那种纯文本 沉浸式的感觉 还是像notion那样的有标题层级分割线 区块感很强的结构化文档 考虑到产品是以写作为主 所以我选择了结构化更强的方案 对话区的设计 我希望的是极简信息流 不要有气泡或者头像 直接把信息列出来就行

交互元素上 既然是极简风格 我要求用幽灵按钮 透明底不显眼 不会分散注意力 那最后一轮他问了动效和名字 动效方面 我选择微动效就够了 不要加多余的东西 然后产品名字的话 因为是针对剧本和小说的写作产品 所以我取名Scrafter

就是script和Crafter的结合体 现在信息足够了 接下来他开始帮我写设计规范了 好的完成了 我们来看一下这份设计规范 文档中描述的视觉风格是深色灰阶 结合了notion的结构感和obsidian的克制 布局参考了Claude Code 核心理念是让界面尽量的隐形

让文字成为唯一的主角 交互元素全部用幽灵按钮 极简的信息流 没有大幅度的动效 整体是一款非常沉浸式的写作产品 设计规范有了 接下来就是把这些文字描述 变成真正的设计图 设计图 在整个的流程里面的权重是最高的 后面我们写代码的时候 AI会优先参考这个设计图

其次才是设计规范和需求文档 所以这一步的质量 直接决定了最终产品长什么样 接下来调用design maker这个技能 开始设计产品原型图 设计工具我推荐用pencil或者Figma 产品经理和设计师 对这两款应用应该都很熟悉 我最近用pencil用的比较多 所以接下来用pencil来演示 如果你没有装过也不用担心

这套流程会引导你 怎么去连接设计工具的MCP 好的现在pencil的MCP已经连上了 我们来看一下它 基于产品需求文档和设计规范文档 帮我们规划出了8个组件 4个主页面和6个变体页面 在这一步 你最好仔细的核对 尽量让每一屏的设计都完成 因为在整个的开发过程中

设计图是最重要的 很多人觉得Vibe Coding做出来的东西丑 根本的原因就是没有设计图 你让AI自己去发挥 它只能从预训练的数据里面 去拼凑出那些默认的组件 样式和配色方案 出来的效果不好 布局呢也一定不是你想要的 我跟他说 再仔细检查一下有没有漏掉的地方 包括所有的变体页面

跳转到的新页面空状态页面 你这些都要检查到 收到我的反馈后 他重新梳理了一遍 那之前是8个组件10屏页面梳理完成 之后变成了10个组件 22屏页面 包含了各个页面的页面变体 你可能会问 难道每次都要提醒他吗 如果不想每次手动提醒的话 你要把刚刚的需求变成反馈意见

比如我说把我刚刚给你的意见记下来 同时我又给了他一个新的意见 设计的时候 页面的平铺布局最好按功能来分类 你看收到反馈之后 他启动了一个叫feedback observer的蓝色SUB agent 把我们刚才的反馈意见都记了下来 记录完成后 他就开始调用pencil的MCP 来画原型图了 那我们切到pencil 你会看到

Claude Code正在全自动的帮你画图 所有页面 都是按照 你前面设计规范文档里面的描述 和产品需求文档中的需求来设计的 全程不需要你干预 画图需要一点时间 那这个过程就不展示了 我们先跳过 现在你看到的就是最终的完成结果 你可以感受一下 整体的风格 和我们前面在设计规范里描述的 几乎是一致的 深色的主题

三栏式布局 没有多余的色彩和装饰 界面非常干净 交互元素也很克制 不会分散注意力 整个设计 就是围绕着 沉浸式写作的这个体验来做的 这就是我们要的效果 好那设计图完成了 不过你还记得 我们前面提的那两条反馈意见吗 可以看到这里 提示反馈意见已经记录好了 在feedback的文件夹下 就可以找到这些记录

所有的反馈索引 都统一在了feedback index的这个文档中 这样反馈多了之后 AI可以通过这个索引 快速加载对应的内容 这是我们提的关于仔细检查 不要遗漏任何页面的反馈意见 然后这个是关于在pencil当中的页面 归纳整理的反馈意见 好的那到这里 需求文档设计规范设计图就都完成了

接下来我们该进入到开发了 我们调用Dev planner这个技能 来规划开发计划 这个skill的流程是 先阅读我们已经写好的所有文档 同时 上网搜索这些需求涉及到的技术站 调研有没有现成的组件 或者是开源项目可以用 了解清楚之后 他会直接帮我们规划和排期 现在他已经写好了一共10 个 Phase

每个 Phase 都有对应的核心交付 在文件树 这里可以找到DEV-PLAN.md

这里可以找到DEV-PLAN.md 这个就是完整的开发计划文档 它的作用不仅是告诉AI 每一期要做什么 那当我们新开一个新的 session的时候 Claude Code也能通过这份文档 知道从哪里接着继续开发 好那计划有了 接下来我们调用dev builder这个技能 开始写代码 他先做了一下依赖检查 然后问有没有设计图

要不要先建一个GitHub远程仓库 那我告诉他设计稿在pencil里 然后也让他帮我创建一个仓库 剩下的就直接开始就行了 现在他开始写Phase 1 的代码 先列好 task list 然后逐项的去实现 这里解释一下他的工作方式 他不是一口气把整个 Phase 写完 而是每个 Phase 拆成多个独立的task 一个一个完成

每完成一个 task 它都会先编译验证 确保没有报错 然后再进入到下一个 那这样做的好处就是 如果中间某个环节出了问题 可以精确定位到 到底是哪个task引入的 而不是写了一大堆代码之后再去排查 好的Phase 1 已经完成了 可以看到 code reviewer的subagent启动了 帮我们做Phase 1 的代码审查

根据我们的流程 每个功能或者Phase 完成之后 它都会自动启动 code reviewer这个agent来审查 包括代码质量功能性测试 以及对照Product Spec做漂移检测 review跑完了 整个审查修复验证的循环都走了一遍 代码也已经推送到了GitHub仓库 打开GitHub 可以看到 它已经帮我们创建了一个私人仓库

推上来的这些文档和代码都在这里 好接着开发 Phase 2，流程是一样的 他先去看设计图 然后找到对应的开发内容 进入到plan模式 列出所有的task list 然后按任务逐个开发 那我们在Phase 2 要开发的 就是所有可复用的组件 这里提醒一下大家 在每开发一个 Phase 的时候 最好你都让他重新读一遍

产品需求文档 设计规范和开发计划以及设计图 虽然我在流程里已经写了 开发前要读这些文档 但每个 Phase 的开发内容都很多 上下文一大 前面的记忆就可能被挤掉 一旦他失忆了 后面就容易乱来 甚至完全脱离我们的产品需求 所以这里 一定要通过每个 Phase 都重新读一遍 文档的方式

不断的刷新他对产品的理解 那这个技巧大家一定要记住好 Phase 2 已经开发完成了 不过你注意看 这一次的code review 的SUB agent没有自己启动 但因为我们设计了stop hook系统 检测到Phase 2 开发完了 但是代码还没有审核 所以就提醒Claude Code要启动code review 这就是我们双层设计的好处

如果完全靠自然语言 让AI自己决定什么时候调用SUB agent 有的时候确实不是很靠谱 不是很稳定 所以我们用hook来兜底 这种双层保险 能让SUB agent在该启动的时候 一定会启动 到这里你应该能感受的到 整个的开发过程其实就是一个循环 读文档写代码审查修复提交 每个phase都是一个循环

但实际开发中 你不可能一个session 把所有的phase都跑完 那上下文会爆 TOKEN也会耗尽 所以你需要不断地开新的session 这个时候 我们前面写的DEV plan 这个开发计划就发挥作用了 每次重启 AI都能通过它知道当前的进度 从上次停下来的地方接着开发 我们现在就重启一下

顺便看看进化系统在新 session 启动时 会做什么 我们重新启动一下整套流程 Claude Code会检查我们目前的项目状态 你看这里还有一个紫色的 evolution Runner的subagent也启动了 它在后台 扫描feedback文件下的所有feedback意见 这个过程是在后台运行的 不影响我们正常操作 好，扫描 结果出来了

这就是我们的进化系统 在开始工作了 目前只有两条反馈 还没有达到进化阈值 所以暂时没有意见 那随着我们使用的积累 同样的反馈如果出现3次以上 就会自动毕业 然后变成规则 那这个过程也是持续的 而且可以跨项目延续 现在我跟他说继续帮我开发项目 可以看到

他重新加载了Dev Builder 这个技能 然后进入到了持续开发模式 他会开始阅读前面所有的开发文档 包括产品需求设计规范开发计划 然后从我们上次停下来的地方接着干 后面几个 Phase 就不逐个演示了 流程和前面都是一样的 重复的 满打满算呢 我花了不到3个小时吧 那整个过程我也修了几个bug

提交了几条反馈 我们现在就来看看初步的效果 我先让它本地启动一下 这就是一次性开发出来的结果 我们看一下设置页面 设置页面里面Kimi GRM Mini Max 这些自定义的供应商 配置和API都有了 技能包管理页面也做好了 左边是文件树 右边是Markdown编辑器 可以直接进行编辑 不过要注意 Vibe Coding呢

不是一次性就能开发出完整的产品 你总会有新想法 会漏掉某些功能 也一定会有bug 所以你是需要不断的迭代 而迭代的方式也很简单 比如用过cursor或者vs code的都清楚 他们的编辑器 应该是每一行都有行号标注 所以我就跟他说参照cursor 帮我也加上行号 这是个小需求 它很快就改好了

Code Review跑完之后 我们现在回到Scrafter 在技能包管理页面 我们随便打开一个Markdown文件 你看行号已经出来了 效果非常好 再来一个难度稍微大一点点的 我希望在文件树里面加一个 右键弹出菜单 然后里面包含重命名 删除和review file path这三个功能 因为这算是新需求

所以Product Spec Builder技能被加载了 他追问了我几个问题 review file path具体是指什么 重命名是针对文件还是整个文件夹 删除的时候要不要确认弹窗 回答完他之后 他就开始更新产品需求文档 和变更记录 然后他问我要不要更新开发计划 还是直接开始干 因为这个需求不是很大

也没有专门做计划的必要 所以我就让他直接上了 不过小需求可以这么干 但是如果是比较大的需求变更 我建议你还是先用DEV planner 好好规划一下 因为开发过程中 一定会有一些关联功能要提前去考虑 不规划直接上手就很容易遗漏 所以这个习惯大家最好养成 好的开发完成了 我们回到Scrafter 来看一下效果

在左边的文件树点击右键 重命名删除 还有在Finder中显示 这三个功能都出来了 然后我们再试一下重命名 OK这个功能也没有问题 不过我发现了一个问题 这次他没有帮我做设计图 我说的不用做开发计划 并不代表着连设计图都可以跳过 所以我给他提了一个反馈 每次修改或新增需求

你都应该同步更新设计图 比如刚才的这个弹窗 你直接把设计环节给忽略了 你看feedback observer启动了 他先帮我把反馈记录了下来 然后主agent呢 使用pencil开始帮我补齐弹窗的设计图 好设计图补完了 打开pencil 可以看到弹窗的原型图已经补好了 我们回到Claude Code 在feedback的文件夹下

可以找到刚才这条反馈 新增和修改UI时必须同步 更新设计稿已经记录在这里了 当同样的情况发生三次 这条反馈就会毕业 然后变成一条正式的规则 写进对应的技能文件里 feedback index中 这条索引也已经加好了 开发和迭代的流程就演示完了 最后呢 我们来完整的跑一遍这个产品 看看实际的体验是怎么样

我们先到设置页面里 这里我还是想办法 给它加了一个 Claude 订阅账号的登录功能 不过测试的话 我会选择用 GLM 来测试 模型选择用他们最新的GLM 5.1 把我的Coding Plan的API key贴到这里 点击测试连接 OK连接成功 保存返回 点击创建一个新项目 名字随便起

然后点击创建 进入项目 我在聊天区随便打个招呼 你看流程就启动了 他开始问我创作方向 包括核心创意 故事的核心冲突以及调性 因为只是测试 我不想动脑子 所以我就跟他说 你帮我组合一个吧 这就是他搭配出来的故事概要 点击生成大纲 它就开始按照这个概要来生成了 到这一步

功能应该都打通了 使用上也很通顺 点击编辑 就可以直接在Markdown编辑器里面 修改刚才生成的大纲了 然后我们去到技能管理页面 打开 CLAUDE .md

.md 你看编辑器也是一切正常 到这里一个简单的 支持加载多题材技能包的 短篇小说创作agent 就基本完成了 最后我分享几点 我在做这个项目过程中的产品思考 那首先第一 先编排再开发 很多人一上来就想着做产品写代码 但其实你应该先用skill和agent 把整个流程跑通

编排的成本非常的低 一个Markdown文件 就能验证你的想法 到底成立还是不成立 跑通了再开发 方向不会错 跑不通几分钟就能调整 不用推翻了重来 那我每期视频出不同的编排方案 本质上就是在做产品验证 第二产品的第一受众是AI 不是人以前我们做产品

思考的是用户怎么点怎么看怎么操作 但agent时代 真正使用工具的是AI 人是在使用agent 所以你在设计产品的时候 第一个要问的不是用户好不好用 而是AI能不能用 这也是为什么 越来越多的工具类产品开始 CLI 化 AI不需要漂亮的按钮 它需要的是清晰的接口和指令 那至于界面

这不是你一开始就要设计的东西 你应该先把agent的能力跑通 等用起来了之后 发现哪些环节确实需要人介入 可以可视化 那这个时候你要去做界面 界面是被需求推出来的 而不是你预设出来的 第三也是我觉得最重要的一点 传统的产品界面怎么开发是死的 按钮在哪里 流程怎么走 全都是固定的

你做了一个言情小说的写作工具 想让他去写短剧剧本长剧剧本 或者电影剧本 每一个行当的流程都是不一样的 你得重新设计界面 重新开发功能 但我们今天的做法 这个agent 它就是一个界面的容器 具体的流程怎么跑 什么时候出现什么按钮 全都在对话框里面动态完成 界面不再限制功能 功能也不再被界面绑死

容器只需要扮演好容器的角色 你往里面加载一套技能包 它就是一个全新的产品 同一个壳 跨4个行当 不用重新开发 说白了技能包就是功能 加载一套新的技能包 比重新开发一个产品的成本 要低太多了 原型成本低 验证成本低 更新速度快 我觉得 这就是未来非常重要的一个方向 好了以上就是本期的全部内容

如果你觉得对你有帮助 别忘了点个关注 也欢迎加入废才俱乐部 那我们下期见