说在前面

  • 本文档只描述产品经理在 vibecoding 实战过程中的基本操作过程，可能遇到的问题及如何解决，并不涉及前置如何调研需求、设计方案，及后续的验收等环节的标准。
  • 建议由研发评估需求较小、影响范围可控后，再交由产品进行 Vibe Coding。
  • 建议提前安装 Vibe Coding 相关 skill，利用这些 skill 进行 Vibe Coding 工程质量更可靠，推荐：

准备工作

基础知识

产品要有最基础的代码理解能力和 Git 基础知识

  • 如新增一个表单字段（如“地址”）就会涉及新增变量（如“address”）及对应的CRUD（增、删、改、查）处理函数，可以不用太关注函数内部的实现逻辑。
  • Git 基础知识包括：
    • Repository-代码仓库：origin-远端代码库、local-本地代码库
    • branch-代码分支：master-主分支，feature_123（开发分支）
    • commit-提交代码变更到当前分支
    • pull/push-拉取/推送代码 from/to 另一个仓库（一般为origin）
    • merge-合并代码分支：feature -> master；Merge Request 即请求将自己当前开发的代码分支 与 master 分支进行合并

准备好Agent工具

agent工具推荐 Codex，总体的体验可能会好一些。

下载好代码

联系研发从GitLab上获取到对应系统的代码库（前、后端）。

开始 Vibe Coding

创建新的对话 + 新建代码分支

基于本次要开发的内容创建新的对话，并指定系统对应代码库的工作目录（内含前端代码和后端代码）

图片

默认 git 会在 master 分支。每次新的开发对话，都让 Agent 拉取最新 origin 仓库 master 分支的代码后，再创建新的开发分支（后续提 PR 后由研发继续 cr 和 MR）

图片

本地启动 + mock 非必要依赖

让 agent 在本地把项目跑起来，这样在本地就可以通过浏览器看到代码的效果

图片

项目在本地启动的过程中，可能会出现很多基础数据缺失（本地数据库没有数据）、依赖其它三方系统接口等问题，让 agent 以 mock 的方式解决，但是需要告诉 agent：

  1. mock 的改动不要污染当前的需求开发，比如需求是在表单里增加一个新的字段，不应该包含其它 mock 的代码变动
  2. mock 的改动范围不要超过系统必要内容部分，避免本次改动的影响范围因 mock 影响而未评估到，比如需求是在表单里增加一个新的字段，但不应 mock 保存接口，否则保存是否成功/是否报错，Vibe Coding 时无法感知
图片

此部分建议研发帮助产品完成。mock的内容会长期沉淀，后续不会需要再做此部分工作或偶尔出现少量类似工作。

vibecoding + 测试

前序工作完成后，就可以正常用自然语言、Prd、spec 等内容让 agent 实现需求功能的 coding 工作。需要注意 agent 的产出质量和速度成反比（质量越高，速度越慢），建议基于需求的复杂度，自行把握尺度，保险的话都用最高质量，但是等的时间会久一点。

图片

每次 agent 产出完成后，都在本地环境的系统里点一点、测一测（仅针对简单需求），看看是否满足预期。有时 agent 也会自己进行相关测试，但保险起见需要人工校验确保符合预期。

提交代码变更

  • Code review：产品先在本地对代码进行简单cr，确保修改范围未超出预期（不应修改了不该改的东西）图片
  • Pull request：让 agent 把本次的代码修改提交到 origin（GitLab） 代码库图片
  • merge request：一般 agent 提交 PR 时也会自动创建 MR，之后手动修改 Assignee 和 Reviewer 为对应研发，让研发再次进行 CR，无问题后合并代码

    建议此部分由研发处理。

提交数据库变更

  • 新增字段涉及数据库变更，让 agent 生成一个 sql 工单（实际会生成一个 sql 文件），给到研发去提 dbpass 工单。图片

发布

代码合并后会在console系统生成发布任务，建议此部分由研发处理。

其它建议

产品 Vibe Coding 流程化建议：产品经理 Vibe Coding 方案