Vibe Coding 自习 Log
概念都来的很快啊。
目录
计划
今天是
核心概念与体系设计
1 阅读定义性文章：什么是Vibe Coding ，它与传统编码的区别
不得不说，
我简单的理解氛围编程就是，我给
2 整理vibe coding prompt engineering
好了，到了
我的整理：
然后我让
一句话结论
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 列出你计划实践的应用（每日工作反馈器）的 需求拆解（高层功能+ 输出字段）
我开始就想了下，我想
这是我目前的构想，我自己能描述就是这样了，不知道其他的人能不能看懂，不知道机器能不能懂。实话说
我现在发现全靠自己先趟一遍，真的很慢啊，这学习计划，不知道一天能不能完成
我先随便找了一篇需求拆解的文章，因为我不会：研发视角：一个需求应该怎么拆解与实现？。发现有点复杂。幸好我的需求简单，不需要这么全面。
我的拆解：
怎么说呢，看了
一、产品目标与边界
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 功能规格文档（输入、输出、流程）
让
确定要使用的AI 编程工具
工具与提示工程基础
我靠我感觉不用学了，直接把
