别再瞎写提示词了：一个运维老哥的 Vibe Coding 10 步实战流

大家好，我是老张。

前段时间在群里看到一张 vibe coding 的工作流图（10 步从想法到上线），看完特别受启发------能把"做产品"这件事提炼成 10 步可执行的流程，本身就很厉害。 感谢分享这张图的朋友，给了我们一个很好的行动框架。

我最近做的 4 个 AI 项目------博客、国学板块、博客后台、小程序------基本就是照着这 10 步走下来的。 框架本身非常好用，照着做不会走大的弯路。

但真的一步步落地的时候发现：每一步里面都有很多"图上没画出来"的实战细节和坑。

就像有人给了你一张地图，告诉你从 A 到 B 要经过哪几个站------路线是对的，但每一站怎么买票、转什么车、哪里容易踩坑，得自己走一遍才知道。

这篇文章就是我照着这 10 步走了 4 遍之后，在每一步里补充的一点点自己的实战经验和踩坑记录。

如果你也想用 AI 做产品，这篇文章能让你少走一些弯路。

本文首发于我的个人博客「山外云」：https://www.shanwaiyun.top/post/vibe-coding-10-step-workflow

博客排版更清爽，还有更多 AI 开发 + 运维实战文章,后续我将把排版工具分享出来

先看图：别人画的 10 步骨架

我看到的那张图把 vibe coding 拆成 4 个阶段：

阶段	步骤	原图描述
PHASE 01 准备（2 步）	00 建仓	GitHub 仓库，每步 commit 可回滚
	01 写 PRD	功能描述 · 数据结构 · 交互逻辑
PHASE 02 视觉（2 步）	02 UI 视觉确认	找参考 → demo → 选风格 → 设计规范
	03 做页面前端	先做出所有页面，逐页对照调整
PHASE 03 开发（2 步）	04 拆分 issues	垂直切片 · 细拆 · 标注依赖
	05 正式开发	按 issue 逐个开发
PHASE 04 交付（4 步）	06 全功能验收测试	业务流走查
	07 UI 细节打磨	组件 · 对齐间距 · 一致性
	08 上线	Vercel · 自定义域名 · 生产数据库
	09 迭代维护	新需求记录，重新走流程

这张图好在哪：把"做产品"切成了可执行的步骤流。

我补充什么：每一步怎么做、踩什么坑、为什么这么做------实战层面的血肉。

下面我用自己的实战（国学板块、博客后台、小程序），把每个格子拆开讲。

PHASE 01 · 准备阶段：这两步决定你会不会放弃

步骤 00：建仓------但不是先建仓，是先验证想法

那张图说"建仓"是第一步。我反过来：先不要建仓。

我自己的流程是：

复制代码

想法出现
  ↓
花 2 天在日常工作中"被这个想法折磨"
  ↓
确认痛点是真实存在的（不是想象）
  ↓
建仓

为什么这么改？

我做国学板块之前，痛点是真实的------通勤地铁想读《道德经》，但 APP 切换烦、字典另开、笔记另存，被这个问题折磨了 6 个月。

这种痛点做出来的产品，3 天弃坑是不可能的------因为它解决的是你自己每天都在面对的问题。

反例：我见过很多人做工具，"觉得有用"，建了仓，写了 README，3 天没更新 。原因不是忙，是痛点不够痛，做下去没动力。

老张的判断标准：建仓前问自己一个问题------

"如果这个产品明天做不出来，我明天还会被这个问题折磨吗？"

如果答案是"会"，就值得做。如果答案是"其实也还好"，趁早放弃。

步骤 01：写 PRD------不要写功能，写场景

那张图说 PRD 是"功能描述、数据结构、交互逻辑"。

我反对这种写法。先写场景，再写功能。

我自己的 PRD 模板（国学板块示例）：

sh 复制代码

# PRD：每日国学小程序

## 场景
- 通勤地铁 30 分钟，想读《道德经》，手机单手操作
- 做饭时想"听"经典，眼睛腾不出来
- 读到精彩处想分享，但不想复制粘贴

## 用户画像
- 35-50 岁传统文化爱好者
- 不是研究者，是"想读但读不进去"的人

## 核心需求（按优先级）
1. 一句话经句 + 白话翻译 + 拼音（解决"读不下去"）
2. 点击任意句可朗读（解决"做饭时想听"）
3. 打卡印签 + 进度自动保存（解决"读两章就忘读到哪"）

## 不要做的
- 不做完整古籍检索（用户不是研究者）
- 不做社交分享（用户群体不爱社交）
- 不做付费内容（违背产品定位）

关键差异：

功能式 PRD	场景式 PRD（我的写法）
功能 1：今日推荐	场景 1：通勤地铁 30 分钟
功能 2：朗读	场景 2：做饭时想"听"经典
功能 3：打卡	场景 3：读到精彩处想分享

前者是给程序员看的，后者是给自己看的。 PRD 的作用不是"让别人照着做"，是"让自己想清楚要不要做"。

我写 PRD 至少花 1 天，比写代码花的时间多得多。

PHASE 02 · 视觉阶段：AI 时代最大的卡点

步骤 02：UI 视觉确认------不是"找参考"，是"找你的审美标准"

那张图说"找参考 → demo → 选风格 → 设计规范"。但实际做起来，这一步的复杂度远超想象。

我自己的 UI 阶段流程目前是这样的：后期可能会调整，目前在看figma

sh 复制代码

收集 20+ 张"我要这种风格"的图（不是"参考"，是"标准"）
  ↓
分析共性：配色 / 字体 / 间距 / 装饰元素
  ↓
提炼出 3 个不可妥协的设计原则
  ↓
用 Codex / Claude Code 生成 v1 demo
  ↓
手动调整 v1，每个细节都改到"自己看着舒服"
  ↓
冻结设计原则（之后改动必须有理由）

国学板块我的 3 个不可妥协原则：

米白宣纸底（#F5F0E8），不用纯白------纯白刺眼，不够"读"
朱砂红强调色（#C03E3E），全篇不超过 3 处------多就显得俗
印章风格图标（手绘感），不用矢量图标------矢量图标"太现代"

这一步 AI 完全帮不上忙。 你可以让 AI 生成图，但"这个红色太刺眼""这个字体撑不起国风""印章太规整没有手作感"------AI 不知道什么叫"好看"。

我自己在 UI 阶段花的时间，比写代码多 2 倍 。这是 AI 时代最反直觉的事：写代码变便宜了，做审美变贵了。

步骤 03：做页面前端------不是"逐页对照调整"，是"先做最丑的能跑版"

那张图说"先做出所有页面，逐页对照调整"。我的实战经验是，顺序可以调整一下，效果更好。

我的做法是反过来的：

sh 复制代码

第 1 版：所有页面都用最丑的样式（白底黑字），但功能跑通
  ↓
用户实际用一遍，记录"哪里用着别扭"
  ↓
第 2 版：基于"别扭点"做 UI 优化，不是基于"设计规范"
  ↓
第 3 版：风格统一化

为什么？

因为"设计规范"是想象出来的，"别扭点"是真实存在的。

我第一版国学板块是纯文字版，连配色都没做。但我用起来发现：

章节切换按钮太小，拇指按不准
译文折叠按钮太隐蔽，第一次用根本找不到
朗读按钮和章节按钮颜色一样，经常点错

这 3 个"别扭点"才是 UI 阶段真正要解决的问题。 设计规范是手段，"用着不别扭"才是目标。

PHASE 03 · 开发阶段：AI 写代码不是"无脑提示词"

步骤 04：拆分 issues------一个 issue = 一个原子任务

那张图说"垂直切片 · 细拆 · 标注依赖"。但具体怎么拆、拆到多细，很多人没概念。

我自己的拆分标准：

一个 issue 对应一个 commit（理想状态）
每个 issue 必须能在 30 分钟内完成
每个 issue 完成后可以立刻看到效果（不是隐藏在内部）

反面教材：我见过有人一个 issue 写"实现用户系统"，结果做了 3 天，最后还要回滚------因为没人能 review。

我的实战数据（国学板块）：

sh 复制代码

总 commit 数：17（10 小时开发）
平均每个 commit：35 分钟
最大 commit：拼音标注功能（90 分钟，但单独成 issue）

关键技巧：拆 issue 不是按"模块"拆，是按"用户感知"拆。

❌ 按模块拆	✅ 按用户感知拆
数据库设计	用户打开页面能看到书架
API 接口	用户能点开《道德经》
前端页面	用户能看到第一章第一句
联调测试	用户能点击朗读

后者每个 issue 完成后，用户能立刻感知到变化。这有两个好处：

动力强------每 35 分钟就有"做出来了"的感觉
出问题容易定位------某个 commit 错了，回滚就是这个功能没了，不波及其他

步骤 05：正式开发------AI 提示词模板

那张图说"按 issue 逐个开发"。关键是每个 issue 怎么给 AI 提示词。

我的提示词模板（实测有效）：

sh 复制代码

【背景】
- 项目：每日国学微信小程序
- 技术栈：uni-app + Vue 3 + Vite
- 当前进度：书架页已完成，正在做阅读页

【本任务】
实现阅读页的"点击单句朗读"功能

【具体要求】
1. 用户点击任意一句，调用 TTS 朗读该句
2. 朗读时该句高亮，朗读完自动取消高亮
3. 切换到下一句时，自动停止当前朗读

【技术约束】
- 必须用 Web Speech API（不要引入第三方 TTS 库）
- 必须处理 Android Chrome 的自动播放限制
- 高亮用 CSS class，不用 inline style

【验收标准】
- 点击第 3 句，朗读第 3 句，不是第 1 句
- 朗读过程中点击第 5 句，自动停止第 3 句，开始第 5 句
- 朗读完成后高亮自动消失

这个模板的 5 个要素：

背景------AI 需要知道项目上下文
本任务------明确做什么
具体要求------可验收的细节
技术约束------避免 AI 自己选错技术栈
验收标准------避免"做完了"但"不能用"

没有验收标准的提示词，必然翻车。

PHASE 04 · 交付阶段：运维人的主场

步骤 06：全功能验收测试------不要"走查业务流"

那张图说"业务流走查"。从运维视角看，这还不够全面。

我自己的测试分 4 层：

sh 复制代码

第 1 层：功能测试（每功能单独跑）
  ↓
第 2 层：流程测试（用户真实路径走一遍）
  ↓
第 3 层：异常测试（断网/慢网/并发/极端输入）
  ↓
第 4 层：设备测试（iOS Safari / Android Chrome / 微信内置浏览器）

异常测试是 90% 的项目跳过的步骤。 但国学板块最大的坑全在异常测试里：

Android Chrome 自动播放限制（点朗读没声音）
语音引擎异步加载（首次朗读失败）
哑引擎------状态正常但不出声（修了 10 个版本）
在线语音网络抖动（连读错乱）

没有这 4 层测试，这些坑不会暴露。

步骤 07：UI 细节打磨------不是"对齐间距一致性"

那张图说的"组件 · 对齐间距 · 一致性"是基础。我觉得更重要的细节打磨，是"交互一致性"。

我自己的 UI 细节清单：

sh 复制代码

□ 所有按钮的点击反馈是否一致？
□ 所有页面的返回逻辑是否一致？
□ 所有错误提示的措辞是否一致？
□ 所有 loading 状态是否都有？
□ 所有空状态是否有友好提示？
□ 所有图片是否有 fallback？
□ 所有长文本是否有截断/省略号？
□ 所有表单是否有防重复提交？

"用户用着不别扭"是结果，"交互一致性"是手段。

步骤 08：上线------运维老哥的真正主场

那张图说"Vercel · 自定义域名 · 生产数据库"。这是偏前端视角的上线，从运维视角看，上线要考虑的事比这多得多。

我博客的上线清单（运维视角）：

sh 复制代码

□ Nginx 配置（缓存、压缩、安全头）
□ HTTPS 证书（按需购买）
□ WAF 规则（防 SQL 注入、XSS、扫端口）
□ 数据库备份（每日全量 + 每小时 binlog）
□ 监控告警（Prometheus + Alertmanager）
□ 日志收集（access log + error log + 慢查询）
□ 限流配置（防 CC 攻击）
□ 二次验证（后台 MFA）
□ 灾备方案（数据库主从 + 文件异地备份）
□ 应急预案（被攻击/宕机/数据丢失时的应对）

这是 AI 帮不了你的部分。 你可以让 AI 写 Nginx 配置，但它不知道你的流量特征、不知道你的攻击历史、不知道你的运维习惯。

这也是运维人在 AI 时代的护城河。 AI 造出来的产品，最后不还得靠运维上线？

补充：很多人忽略的备案环节

说到上线，还有一件事很多第一次做网站的人会踩坑------备案。

个人博客要在国内正常访问，至少需要两个备案：

ICP 备案（工信部）：这个是基础，没有的话域名不能解析到国内服务器。阿里云/腾讯云都有免费代办通道，一般 7-20 个工作日下来
公安备案（公安部全国互联网安全管理服务平台）：ICP 下来之后 30 天内要做公安备案，否则可能被警告或罚款。很多人只做了 ICP 忘了这个

两个备案都通过之后，要在网站 footer 底部展示备案号和跳转链接------这是合规要求，不是可选项。

我的博客 footer：ICP 备案号 + 公安备案号，都链到对应官网

很多用 AI 做网站的朋友，代码写得飞快，上线的时候卡在备案上半个月------建议域名一注册就开始走备案流程，别等代码写完了才想起来。

步骤 09：迭代维护------比上线更重要

那张图说"新需求记录，重新走流程"。但实际做起来，迭代的节奏和方式比这句话重要得多。

我博客上线 48 小时内，提交了 30+ 个 commit，全是用户反馈驱动的：

用户反馈"朗读没声音" → 排查 → 修 10 个版本
用户反馈"评论要填邮箱太麻烦" → 改成选填
用户反馈"地铁没信号读不了" → 加 PWA 离线

"上线不是终点，反馈才是起点。"

这是我做完国学板块后最大的认知升级。

老张总结：vibe coding 的 5 条方法论

最后再感谢一下分享那张 10 步工作流图的朋友------没有那个框架，我可能还在零散地踩坑，不会这么系统地把项目走下来。

照着人家的步骤做，再加上一点点自己的实战细节------这就是这篇文章的全部内容。

走完 4 遍之后，最后给你 5 条可复用的方法论：

方法论 1：痛点必须来自你自己

建仓前问自己："如果做不出来，明天还会被这问题折磨吗？"

不会就别开始。

方法论 2：PRD 写场景，不写功能

场景是给自己看的，功能是给程序员看的。

PRD 的作用是想清楚要不要做，不是让别人照着做。

方法论 3：UI 阶段花的时间 > 编码阶段

AI 时代最反直觉的事：写代码变便宜了，做审美变贵了。

你花在"找参考 → 调风格 → 改细节"的时间必须超过写代码。

方法论 4：AI 提示词必须有验收标准

没有验收标准的提示词，必然翻车。

"做完了"不等于"能用了"。

方法论 5：上线是运维人的主场

AI 造出来的产品，最后不还得靠运维上线？

这是 AI 时代最稳的岗位之一。

互动话题

评论区聊聊：

你做 AI 项目时，最花时间的是哪个阶段？ UI？写代码？还是上线？
你给 AI 的提示词，会写验收标准吗？ 还是只写"帮我实现 XX 功能"？
你觉得 vibe coding 最大的卡点是什么？ 是审美？是产品感？还是别的？

老张我先说我的答案：UI 阶段的审美，是 AI 帮不了的卡点。你怎么看？

别再瞎写提示词了：一个运维老哥的 Vibe Coding 10 步实战流

先看图：别人画的 10 步骨架

PHASE 01 · 准备阶段：这两步决定你会不会放弃

步骤 00：建仓------但不是先建仓，是先验证想法

步骤 01：写 PRD------不要写功能，写场景

PHASE 02 · 视觉阶段：AI 时代最大的卡点

步骤 02：UI 视觉确认------不是"找参考"，是"找你的审美标准"

步骤 03：做页面前端------不是"逐页对照调整"，是"先做最丑的能跑版"

PHASE 03 · 开发阶段：AI 写代码不是"无脑提示词"

步骤 04：拆分 issues------一个 issue = 一个原子任务

步骤 05：正式开发------AI 提示词模板

PHASE 04 · 交付阶段：运维人的主场

步骤 06：全功能验收测试------不要"走查业务流"

步骤 07：UI 细节打磨------不是"对齐间距一致性"

步骤 08：上线------运维老哥的真正主场

补充：很多人忽略的备案环节

步骤 09：迭代维护------比上线更重要

老张总结：vibe coding 的 5 条方法论

方法论 1：痛点必须来自你自己

方法论 2：PRD 写场景，不写功能

方法论 3：UI 阶段花的时间 > 编码阶段

方法论 4：AI 提示词必须有验收标准

方法论 5：上线是运维人的主场

互动话题

相关阅读