Vibe Coding 自习 Log
感觉以后是产品经理的天下了！！
但是报 500 了！没 token 了不让试用了！可恶，逼人花钱，我自己 debug！
Vibe Coding 自习 Log
计划
今天是 Day 4，我将从 Day 1 开始，把前面的都补上，七天计划可以压缩到两天了，Day 1 ～ Day 4 一天，Day 5 ～ Day 7 一天。真是跟上学的时候是一脉相承的啊，计划从来不是线性完成的。
核心概念与体系设计
1 阅读定义性文章：什么是 Vibe Coding，它与传统编码的区别
不得不说，Google 写的真不错，清晰简单，还推荐了自己的工具。
我简单的理解氛围编程就是，我给 LLM 提需求，它帮我写整个项目代码，我提修改，它帮我完善，我只需要考虑需求和目标，测试部署就够了。
Google 的产品我觉得都不错，回头我把 Google AI Studio，Firebase Studio，Gemini Code Assist 全试一下去。
2 整理 vibe coding 与 prompt engineering 的关系图
好了，到了 Check List 的第二条，开始犯难了，我目前是已经不会自己思考了，啥都找 GPT，终于能理解大雄啥事都喊哆啦A梦了，不是他废，我也一样啊。幸好我上学的时候没有 GPT。我先自己整理一个，然后再求助 GPT 吧。
我的整理：
然后我让 GPT 来回答了一下，深深体会到了，我是狗嘴里吐不出象牙来...... 自己写文章是不是现在已经消亡了，不知道大师们是怎么样，反正我已经被全面碾压了。学习！
ChatGPT 的整理：
一句话结论
Prompt Engineering 是能力与方法论，Vibe Coding 是以该能力为核心的一种开发工作流与范式。
二者不是并列关系，而是“能力 ⟶ 实践形态”的关系。关系图
flowchart TD A[Prompt Engineering<br/>提示工程] -->|提供核心能力| B[Vibe Coding<br/>氛围编程] A --> A1[Prompt 设计<br/>结构化表达] A --> A2[约束与上下文控制] A --> A3[多轮迭代与修正] A --> A4[错误引导与纠偏] B --> B1[对话式开发流程] B --> B2[AI 生成代码为主] B --> B3[人类负责目标与判断] B --> B4[快速原型与探索式开发] B1 -->|高度依赖| A关系拆解（从“层级”看）
1 Prompt Engineering（底层能力 / 技术方法）
定位：
“如何与模型有效沟通”
关注点：
- 如何描述需求
- 如何控制输出结构与边界
- 如何通过反馈引导模型修正
- 如何减少幻觉、提高可控性
典型场景：
- 让模型写对代码
- 让模型提取准参数
- 让模型按预期格式输出
- 让模型在错误时自我修正
2 Vibe Coding（上层实践 / 工作流范式）
定位：
“以 AI 为主要代码生产者的软件开发方式”
关注点：
- 开发者角色从「写代码」→「定义目标 + 调整方向」
- 通过自然语言推进整个开发生命周期
- 快速试错、快速收敛
典型场景：
- 周末项目 / 原型验证
- 低代码 / 无代码应用
- 产品经理或非专业开发者构建应用
- AI-first 的开发模式
对比表
维度 Prompt Engineering Vibe Coding 本质 技术方法 / 能力 开发范式 / 工作流 层级 底层 上层 核心问题 “怎么问 AI” “怎么用 AI 写软件” 是否独立存在 ✅ 是 ❌ 强依赖 Prompt 覆盖范围 不限于编程 主要在编程 失败风险 输出不稳定 架构与质量风险 形象类比
Prompt Engineering ≈ 驾驶技术
Vibe Coding ≈ 自动驾驶 + 你坐在驾驶位指路
- 驾驶技术差 → 自动驾驶一直撞墙
- 驾驶技术好 → 自动驾驶才真能解放精力
3 列出你计划实践的应用（每日工作反馈器）的 需求拆解（高层功能 + 输出字段）
我开始就想了下，我想 Demo 做个啥，做个又有用，有不难的东西。结合自身我想做一个每日工作反馈器，因为我不是有每天都记录的习惯，这些东西可以用起来，先做个最简单的。我想做一个页面，能输入文本框，然后点击总结反馈，在一个模块帮我总结我一天做的内容，并且帮我理清能汇报的价值，摘掉没有价值的部分（我怀疑就没啥了），在另一个模块，帮我生成反馈，我需要注意的，我哪儿能优化的，我做的方向有没有偏差。还有另一个按钮，一键生成 Jira 单据（这个我天天让 GPT 帮我做，效果挺不错的）然后我可以 Review 生成的单据表格，并做一些修改，然后点击提交，一键掉 Jira API 填工时。
这是我目前的构想，我自己能描述就是这样了，不知道其他的人能不能看懂，不知道机器能不能懂。实话说 Prompt 这一块，我也没体系研究过，全靠随意，有时候直骂 GPT 笨，不知道是不是我自己的问题。那其实跟人沟通我也全靠随意，也没体系研究过，别人能不能懂也是靠缘分......
我现在发现全靠自己先趟一遍，真的很慢啊，这学习计划，不知道一天能不能完成 4 天的。给 GPT 干肯定已经都干完了。但是还是得学习嘛，唉，幸好我上学的时候没有 GPT，要不我还得早几年成废人一个。
我先随便找了一篇需求拆解的文章，因为我不会：研发视角：一个需求应该怎么拆解与实现？。发现有点复杂。幸好我的需求简单，不需要这么全面。
我的拆解：
怎么说呢，看了 GPT 给的，我觉得自己都是在浪费时间，我得改变一下方式了，时间有限，还是都交给 GPT 吧，又快又好，不使工具来学习这种思维太老式了！
ChatGPT 的拆解：
一、产品目标与边界
1. 核心目标（一句话）
将「一天的零散工作记录」→ 结构化总结 + 价值提炼 + 行动反馈 + Jira 工时单据 的闭环工具。
你不是要：
- 再做一个 Todo App
- 再做一个 Chat UI
你要的是一个“个人工作复盘与对外汇报转换器”。
2. 非目标（明确不做的）
- ❌ 自动判断 KPI / OKR 完成度（太主观）
- ❌ 自动提交 Jira（必须人工 Review）
- ❌ 长期绩效分析（这是下一阶段）
二、用户流程（核心）
flowchart LR A[输入当天原始工作记录] --> B[点击：总结与分析] B --> C[模块1：工作总结与可汇报价值] B --> D[模块2：反馈与优化建议] C --> E[点击：生成 Jira 单据] E --> F[可编辑的 Jira 表格] F --> G[点击：提交到 Jira API]
三、页面结构拆解（UI 层）
1️⃣ 输入区（Raw Input）
组件
- 多行文本框（核心）
- 支持：
- 时间线式
- 碎片化
- 情绪化表达（“今天被打断三次”）
输入约定（隐式）
- 不要求结构
- 不要求语法
- 不要求“像汇报”
这是给真实工作流用的，不是给展示用的。
2️⃣ 模块一：总结 & 可汇报价值
输出结构（固定）
【今日工作概述】 - … 【可对外汇报的价值】 - … 【建议弱化或不汇报的内容】 - …核心判断逻辑（需求层）
- 什么是「可汇报价值」
- 产出（文档、代码、方案、修复）
- 决策（明确取舍、方案选择）
- 风险（识别、阻断、缓解）
- 沉淀（模板、规则、自动化）
- 什么是「可删减内容」
- 情绪宣泄
- 被动响应但无结果
- 未闭环的杂事
- 纯沟通无结论
⚠️ 这里是第一个 Prompt 核心点
3️⃣ 模块二：反馈 & 方向校准
输出结构（固定）
【值得肯定的地方】 - … 【可以优化的点】 - … 【潜在方向偏差或风险】 - … 【明日可执行的调整建议】 - …特殊要求（非常重要）
- 反馈必须：
- 偏管理者视角
- 偏系统性，而非鸡汤
- 允许指出：
- 精力错配
- 价值密度偏低
- 过度执行 / 过度打杂
你这个模块，本质是「自用的一对一复盘经理」。
4️⃣ Jira 单据生成模块
触发方式
- Button：生成 Jira 单据
4.1 Jira 单据生成逻辑（AI 侧）
输入来源
- 原始输入
- 模块一的「可汇报价值」
输出为表格结构（非常关键）
字段 含义 Issue Type Task / Story / Bug Summary Jira 标题 Description 工作描述 Time Spent 工时（小时） Project / Component 可选 Date 工时日期 ⚠️ 不能直接生成 JSON 或直接调 API
必须先给你 Review 表格
4.2 Jira 单据 Review & 编辑
功能点
- 表格可编辑：
- 文案
- 工时
- Issue Type
- 支持：
- 合并
- 删除
- 拆分
这是第二个核心风险控制点。
4.3 Jira API 提交
功能
- Button：提交 Jira 工时
- 批量提交
- 成功 / 失败提示
技术要求（需求层）
- Token / Auth 外部配置
- 失败要返回具体原因（权限 / 字段错误）
四、功能模块拆解（工程视角）
1️⃣ 前端模块
模块 职责 InputEditor 原始工作输入 SummaryPanel 总结 & 价值 FeedbackPanel 反馈与方向 JiraDraftTable Jira 草稿编辑 SubmitHandler 提交控制
2️⃣ 后端 / 服务模块
模块 职责 Prompt Orchestrator 管理多段 Prompt Summary Engine 总结 & 价值判断 Feedback Engine 反馈与校准 Jira Formatter Jira 结构化生成 Jira API Client 工时提交
3️⃣ Prompt 责任拆分（非常关键）
不要一个 Prompt 干所有事
Prompt 职责 P1 原始记录 → 结构化总结 P2 总结 → 价值筛选 P3 总结 + 价值 → 反馈 P4 价值 → Jira Draft
五、第一版 MVP 建议（现实可落地）
必须有
- 输入框
- 总结模块
- 反馈模块
- Jira 草稿表格
- 手动提交 Jira
可以后做
- 历史记录
- 模板对比
- 管理者视角切换
- 多天合并
4 创建你的 MVP 功能规格文档（输入、输出、流程）
让 GPT 帮我综合写了个：
确定要使用的 AI 编程工具
工具与提示工程基础
Cursor 快速上手：Quickstart | Cursor Docs
我靠我感觉不用学了，直接把 MVP 文档给到 Cursor 了，现在过了不到一个小时，全有了，那我今天先把这样原型先跑起来吧。我感觉我根本就不应该浪费时间学，我带着我的需求去，然后就没有啥然后了！开干就完事了！唯一的问题是到 limit 了，让我升级了。希望起起来发现没有需要改的了吧。🙏
本文作者：ZZN而已
本文链接：https://www.cnblogs.com/zerozhao/p/19498775/vibe_coding_study_log
版权声明：本博客所有文章除特别声明外，均采用 CC BY-NC-ND 4.0 许可协议。
浙公网安备 33010602011771号