From 8e0597cda027dec4a0c4d9447ef364293a9f9801 Mon Sep 17 00:00:00 2001
From: nchj <28175310+nchj@users.noreply.github.com>
Date: Mon, 4 May 2026 23:02:34 +0800
Subject: [PATCH] add vibe coding post summary

---
 ...026-05-04-vibecoding-experience-summary.md | 292 ++++++++++++++++++
 1 file changed, 292 insertions(+)
 create mode 100644 docs/posts/talks/2026-05-04-vibecoding-experience-summary.md

diff --git a/docs/posts/talks/2026-05-04-vibecoding-experience-summary.md b/docs/posts/talks/2026-05-04-vibecoding-experience-summary.md
new file mode 100644
index 0000000..6d96106
--- /dev/null
+++ b/docs/posts/talks/2026-05-04-vibecoding-experience-summary.md
@@ -0,0 +1,292 @@
+---
+title: Vibe Coding 实践经验总结：流程、观点与方法论
+date: 2026-05-04
+categories:
+  - 杂谈
+tags:
+  - AI
+  - Vibe Coding
+  - 软件工程
+  - 工作提效
+---
+
+> 原文：[一位VibeCoding开发者的浅薄经验自述](https://cloud.tencent.com/developer/article/2648026)，作者：程序员唱见，发布于腾讯云开发者社区（2026-03-31）。本文为阅读笔记，目的是快速提取与回顾原文知识点。
+
+---
+
+## 一、什么是 Vibe Coding？先破除三个误解
+
+很多人对 Vibe Coding 存在误解，常见的三种：
+
+- ❌ **"想到什么就让 AI 生成什么"** —— 把 AI 当即兴创作工具，跳过需求思考
+- ❌ **"少写代码、全靠模型"** —— 把工程师职责外包给模型，自己退场
+- ❌ **"先有感觉，再看结果，能跑就行"** —— 以结果凑合为目标，忽略工程质量
+
+这三种理解都是片面的。Vibe Coding 的核心不是"让 AI 生成代码"，而是**以 AI 为加速器，重走一遍完整的软件工程流程**。速度变快了，但工程该有的环节一个都不能少。
+
+---
+
+## 二、完整流程概览
+
+作者将自己实践的 Vibe Coding 工作流程前置，整体如下：
+
+```
+需求收敛
+  → 原型验证
+    → Prompt 契约化
+      → 模块化代码生成
+        → 测试先行
+          → 日志与可观测性内置
+            → AI Review + 工程 Review
+              → 部署回归 + 人工体验测试
+                → 文档随交付
+```
+
+每一步都有明确意图，不是线性流水线，而是迭代螺旋——尤其在原型阶段可以快速反复。
+
+---
+
+## 三、各阶段详解
+
+### 1. 需求收敛：最重要的一步
+
+> **需求没有收敛，就开始让 AI 放大误解。**
+
+需求收敛需要回答三个问题：
+
+| 问题 | 作用 |
+|------|------|
+| **要做什么？** | 明确功能边界 |
+| **不做什么？** | 排除范围同等重要，防止范围蔓延 |
+| **怎么算做完？** | 定义 Done 的标准（DoD），避免模糊交付 |
+
+模糊需求交给 AI，会被无限放大成模糊实现。需求写清楚，AI 才能生成有效代码。
+
+---
+
+### 2. 原型优先：最便宜的纠错工具
+
+原型阶段的错误成本最低。在进入"真正写代码"之前，先让 AI 帮你跑一版原型，可以：
+
+- 验证方向是否正确
+- 发现需求理解的偏差
+- 以最低代价纠错
+
+原型不是装饰，它是 Vibe Coding 里错误成本最低的验证手段。
+
+---
+
+### 3. Prompt 契约化：不是聊天，是开发文档
+
+> **Prompt 在 VibeCoding 里不是聊天记录，而是开发契约。**
+
+每个模块的 Prompt 应该包含：
+
+- 功能描述（做什么）
+- 输入输出约定
+- 技术约束（用什么框架、不能依赖什么）
+- 完成标准（怎么验收）
+
+写 Prompt 的态度应该和写需求文档一样严肃。越随意的 Prompt，生成越随机的结果。
+
+---
+
+### 4. 测试先行：而非代码先行
+
+> **真正拉开差距的，是测试先行而不是代码先行。**
+
+在写代码之前，先列出测试清单，涵盖三类：
+
+| 测试类型 | 关注点 |
+|---------|--------|
+| **功能测试** | 核心功能是否正常 |
+| **边界测试** | 极端情况、异常输入下的表现 |
+| **体验测试** | 用户实际使用的感受和流畅度 |
+
+测试清单先行，可以倒逼 Prompt 写得更清晰，也能让代码生成后有明确的验收标准。
+
+---
+
+### 5. 日志与可观测性：第一版就要有
+
+不要等 bug 出现了才补日志。可观测性应该是第一版的标配，而不是后期修缮的补丁。
+
+在 Vibe Coding 中，这一点尤其重要：AI 生成的代码更难追踪行为，如果没有日志，出了问题根本无从排查。
+
+---
+
+### 6. 双重 Review：AI Review + 工程 Review
+
+AI Review 和人工工程 Review 各有侧重：
+
+- **AI Review**：快速扫描语法、常见安全问题、代码风格、潜在 bug
+- **工程 Review**：关注架构一致性、业务逻辑正确性、可维护性、团队规范
+
+两者缺一不可，不能用 AI Review 替代工程 Review。
+
+---
+
+### 7. 交付要有文档
+
+交付时要附带文档，而不是把代码仓库直接甩出去。AI 生成代码很快，但如果没有文档，接手的人（包括未来的自己）照样一头雾水。
+
+---
+
+## 四、完整案例：从 0 VibeCoding 一个 TodoList 项目
+
+作者以 TodoList 为例，完整走一遍 8 步流程，并附上每步的参考提示词。
+
+---
+
+**第一步：把需求写成"项目边界"，而不是一句愿望**
+
+> 核心意图：需求收敛
+
+❌ 错误方式：`帮我做一个 TodoList`
+
+✅ 正确方式（项目边界文档）：
+
+```
+项目名称：TodoList Web App
+要做什么：支持新增、编辑、删除、标记完成的任务管理页面
+不做什么：不需要用户登录、不需要多人协作、不需要移动端适配
+技术栈：React + TypeScript，无后端，数据存 localStorage
+怎么算做完：能在浏览器里完整操作任务的增删改查，刷新后数据不丢失
+```
+
+---
+
+**第二步：先让 AI 做拆解和原型，而不是直接写代码**
+
+> 核心意图：方向验证
+
+参考提示词：
+
+```
+根据以下项目边界，帮我拆解功能模块，并给出一个最简原型的组件结构：
+
+[粘贴第一步的项目边界文档]
+
+要求：
+- 列出核心组件清单
+- 每个组件的职责一句话描述
+- 不用写代码，先给结构图
+```
+
+---
+
+**第三步：编写 Prompt 契约，按模块逐步生成**
+
+> 核心意图：契约化生成
+
+每个模块单独一个 Prompt，格式如下：
+
+```
+模块名称：TaskItem 组件
+功能描述：展示单条任务，支持标记完成、编辑、删除
+输入：{ id, title, completed } 类型的 task 对象 + 三个回调函数
+输出：一个 React 函数组件，TypeScript 类型完整
+约束：不引入额外依赖，样式用 CSS Module
+验收标准：completed 为 true 时标题有删除线，三个按钮 hover 有反馈
+```
+
+---
+
+**第四步：先写测试清单，再进入实现验证**
+
+> 核心意图：测试先行
+
+参考提示词：
+
+```
+我即将实现 TodoList 的 TaskList 模块，在写代码之前，
+请帮我列出完整的测试清单，涵盖三类：
+1. 功能测试：核心功能的正常路径
+2. 边界测试：空列表、超长标题、快速连续操作等
+3. 体验测试：操作反馈是否及时、错误提示是否清晰
+```
+
+---
+
+**第五步：强制补日志，别等 bug 出现了再加**
+
+> 核心意图：可观测性内置
+
+参考提示词：
+
+```
+在以下代码中，帮我在关键操作节点加上 console 日志，
+要求：新增/删除/编辑/完成切换都要有日志，
+日志格式：[TodoList][操作类型] 操作内容 时间戳
+
+[粘贴当前代码]
+```
+
+---
+
+**第六步：AI review 一遍，人工 review 一遍**
+
+> 核心意图：双重质量保障
+
+AI Review 提示词：
+
+```
+请对以下代码做 code review，重点检查：
+1. 有没有潜在的运行时错误
+2. TypeScript 类型有没有不安全的地方
+3. 有没有明显的性能问题
+4. 代码风格是否一致
+
+[粘贴代码]
+```
+
+人工 Review 关注点（不能外包给 AI）：
+- 架构与已有项目是否一致
+- 业务逻辑是否符合实际需求
+- 命名是否符合团队规范
+
+---
+
+**第七步：部署测试环境，跑回归，再做人工体验测试**
+
+> 核心意图：完整验收
+
+- 跑第四步列出的测试清单，逐条确认
+- 人工实际操作一遍完整流程，感受是否顺畅
+- 发现问题回到对应步骤修复，而不是继续往下走
+
+---
+
+**第八步：补文档后再交付**
+
+> 核心意图：可维护交付
+
+参考提示词：
+
+```
+根据以下代码，生成一份简洁的开发文档，包括：
+1. 项目结构说明
+2. 核心组件职责
+3. 本地运行方法
+4. 已知限制与未来扩展点
+
+[粘贴代码或目录结构]
+```
+
+---
+
+## 五、Vibe Coding 的核心价值（作者总结）
+
+> 不是"快"，而是"稳"。
+
+作者最终给出三个核心价值：
+
+1. **更快地收敛问题** —— AI 加速了问题定义和边界确认的过程
+2. **更快地形成初稿** —— 快速产出可迭代的第一版，缩短从 0 到 1 的周期
+3. **更容易把工程流程补完整** —— AI 辅助下，测试、文档、日志等工程规范更容易落地
+
+**VibeCoding 的终极目标不是速度，而是稳定性和可靠性。**
+
+---
+
+**原文链接**：[一位VibeCoding开发者的浅薄经验自述 - 腾讯云开发者社区](https://cloud.tencent.com/developer/article/2648026)