qlxxkj Tutorials

Appearance

1. 产品定义：从模糊想法到清晰需求 ​

1.1 为什么产品定义比写代码更重要

很多人拿到AI工具后的第一件事是：直接说"帮我做一个XX"。然后AI生出一堆代码，你打开一看，功能不对、布局难看、数据存不了。问题不在AI，而在你没有想清楚要做什么。

产品定义阶段决定了后续所有工作的方向。方向错了，代码写得越快，返工越多。

  • 没有PRD，AI不知道优先级，会把精力花在次要功能上
  • 没有用户故事，AI不知道为谁设计，做出来的东西没人用
  • 没有功能清单，AI会自由发挥，最后你得到一个不伦不类的产物

产品定义不是浪费时间的环节，它是省时间的环节。花30分钟想清楚，省下3小时返工。

1.2 用一句话描述你的产品（电梯演讲法）

电梯演讲法来自创业圈的标准练习：假设你在电梯里遇到投资人，你有30秒时间说清楚你的产品。30秒大约是一句话。

格式模板：

  • "[产品名称] 是一个 [产品类型]，帮助 [目标用户] 解决 [核心痛点]，通过 [关键方法]"

实战示例：

产品电梯演讲
记账本"随手记是一个个人记账工具，帮助月光族看清钱花在哪了，通过极简的语音输入和自动分类"
简历生成器"简历工厂是一个AI简历生成器，帮助求职者快速生成匹配岗位描述的简历，通过解析JD自动提取关键词并填充"
读书笔记"书摘是一个读书笔记应用，帮助深度阅读者管理自己的书摘和笔记，通过OCR拍照识别和AI摘要自动生成"

练习：现在就用这个格式写一句话描述你想做的产品。写不出来就说明你还想不清楚。

1.3 核心功能清单：必须做 vs 以后做

功能清单不是列一堆想要的功能，而是砍掉不需要的功能。MVP的原则是：只保留验证核心假设所需的最小功能集。

划分方法：

  • P0（必须做）：没有这个功能，产品就不成立。通常只有2-4个。
  • P1（应该做）：有了更好，但没有也能跑。上线后第一个迭代加。
  • P2（以后做）：锦上添花的功能。等用户反馈再说。

示例：个人记账App的功能清单

优先级功能说明
P0添加收支记录金额、分类、日期、备注
P0查看账单列表按时间倒序展示
P0月度统计收入/支出/结余的汇总
P1分类管理自定义收支分类
P1图表展示饼图、折线图
P1数据导出CSV导出
P2多账户现金、银行卡分开管理
P2预算管理设置月度预算并提醒
P2社交分享生成月度账单海报

1.4 用户故事模板

用户故事是从使用者角度描述功能的句式。它强迫你站在用户立场思考，而不是站在技术立场。

格式：

  • 作为 [用户角色]，我想要 [功能]，以便 [获得的價值]

关键：后半句"以便"必须有价值。如果只是"以便能用这个功能"，说明这个功能可能不需要。

示例：

用户故事优先级
作为一个月光族，我想要快速添加一笔支出，以便随时记录不忘记P0
作为一个记账用户，我想要按月份查看收支汇总，以便了解我的财务状况P0
作为一个记账用户，我想要查看各类支出的占比，以便找到消费大户P1
作为一个记账用户，我想要导出账单数据到Excel，以便做更详细的分析P2

1.5 实战练习：定义你的第一个产品

跟着以下步骤走一遍：

  • 第一步：用电梯演讲格式写一句话描述
  • 第二步：列出所有你想要的功能
  • 第三步：砍到只剩P0功能，不超过4个
  • 第四步：为每个P0功能写一条用户故事
  • 第五步：把这份文档保存为 PRD.md，后续开发全程参考

不要跳到下一步，除非这五步都完成了。

2. 技术选型：用什么工具最快 ​

2.1 前端框架选择

前端框架的选择直接影响开发速度和后期维护成本。在AI编程时代，框架的选择标准发生了变化：

框架学习曲线AI友好度适合场景
纯HTML/CSS/JS低高静态页面、原型验证
Vue低高中小型项目、国内团队
React中极高复杂交互、生态丰富
Svelte中中追求性能的轻量项目
Next.js中极高全栈项目、需要SEO

推荐优先级：Next.js > React > Vue > 纯HTML

理由：AI对React生态的训练数据最多，生成的代码质量最高。Next.js同时覆盖前后端，减少技术栈数量，降低上下文切换成本。

2.2 为什么推荐Next.js

Next.js是当前AI编程时代的全栈首选框架，原因很直接：

  • 全栈能力：页面、API路由、服务端组件都在一个项目里，不需要额外搭建后端
  • 部署极简：Vercel一键部署，零配置，自动HTTPS、自动CDN
  • 生态成熟：组件库、UI库、数据库ORM全部有Next.js适配
  • AI训练数据多：GitHub上Next.js项目最多，AI生成的代码准确率高
  • 热更新快：开发时改代码立即生效，AI协作效率高

对比其他方案：

方案优点缺点
Next.js全栈一体、部署简单有一定学习成本
Vite + 独立后端前后端解耦灵活需要维护两套项目
纯静态站点部署最简单无法处理动态数据和API
Django/Rails内置后台管理AI生成代码质量不如JS生态

2.3 样式方案

样式方案的选择看似小事，实际上影响开发效率和最终视觉效果。

方案开发速度灵活性AI生成质量推荐度
Tailwind CSS极快高极高首选
CSS Modules中中中备选
原生CSS慢高低不推荐
Styled Components中高中可选

Tailwind CSS是AI编程时代的样式首选。原因：

  • 类名即语义，AI能准确理解每个class的作用
  • 不需要写额外的CSS文件，所有样式内联在组件中
  • 组件库（shadcn/ui、Headless UI）直接可用，复制粘贴即可
  • 响应式设计一行class搞定，不需要媒体查询

2.4 数据库选择

新手项目的数据库选择很简单：

场景推荐理由
个人工具、MVPSQLite零配置、单文件、AI生成代码准确率高
多用户SaaSPostgreSQL扩展性好、生态成熟、Vercel/Supabase原生支持
实时应用Supabase (PostgreSQL)内置WebSocket、Auth、实时订阅
简单缓存Redis不适合主存储，仅做缓存层

建议：起步用SQLite，跑通流程后再考虑迁移。不要一开始就上PostgreSQL，配置成本会拖慢开发节奏。

2.5 AI托管平台

部署平台的选择决定了你上线的速度和成本。

平台免费额度适合技术栈配置难度推荐度
Vercel充足Next.js、React零配置首选
Railway有限通用低备选
Fly.io有限通用中进阶
Netlify充足静态站点零配置静态项目
Cloudflare Pages充足静态/Edge低低成本

Vercel是Next.js的原生平台，部署流程几乎不需要配置。git push就上线，自动构建、自动部署、自动HTTPS。对于AI编程新手来说，这是降低挫败感的关键一环。

2.6 选型决策树

需要什么？
├── 只是静态页面 → 纯HTML + Tailwind → 部署到Netlify/Vercel
├── 需要用户交互和数据 → Next.js + Tailwind → 部署到Vercel
│   ├── 数据量小/个人用 → SQLite
│   └── 多用户/要扩展 → PostgreSQL (Supabase)
└── 需要移动端优先 → React Native / Expo

记住：选型没有完美答案，只有当前阶段最适合的答案。你的第一个产品不需要完美架构，需要的是尽快上线验证。

3. AI生成页面：让AI替你写代码 ​

3.1 如何用自然语言描述页面结构

AI生成页面的质量，取决于你描述页面的清晰度。不是写代码的能力，而是描述能力。

好的页面描述包含三个层次：

第一层：整体布局

  • "这是一个单栏布局，顶部是导航栏，中间是内容区，底部是页脚"
  • "页面分为左右两栏，左侧是侧边栏菜单，右侧是主内容区"

第二层：组件拆解

  • "导航栏包含：Logo（左侧）、三个链接（右侧）、一个登录按钮"
  • "主内容区是一个卡片列表，每张卡片包含标题、描述、创建时间"

第三层：样式细节

  • "卡片圆角12px，阴影轻微，hover时上浮2px"
  • "按钮用蓝色背景，白色文字，圆角8px，点击时有缩放动画"

3.2 从首页开始的完整页面生成流程

页面生成遵循一个固定顺序，不要跳步：

第一步：生成首页（Landing Page）

提示词示例：
"请用Next.js + Tailwind CSS创建一个个人记账App的首页。
布局要求：
- 顶部导航栏：左边是Logo'随手记'，右边是'登录'和'注册'按钮
- 中间区域：大标题'轻松记账，告别月光'，副标题'3秒记录每一笔支出'，下方一个'开始使用'的主按钮
- 底部：三个功能卡片，分别是'快速记账'、'月度统计'、'智能分类'
样式要求：
- 整体色调：白色背景，蓝色主色(#3B82F6)，灰色文字
- 响应式：手机端单列，桌面端三列
- 卡片圆角16px，轻微阴影"

第二步：生成核心功能页

  • 首页确认后，再生成"添加记账"页面
  • 然后生成"账单列表"页面
  • 最后生成"统计页面"

第三步：生成辅助页面

  • 登录/注册页
  • 个人中心页
  • 设置页

关键原则：一次只让AI做一个页面。不要说"帮我做整个App"，要说"帮我做首页"。页面确认无误后，再说下一个页面。

3.3 关键技巧：一次只让AI做一个页面

为什么不能一次性生成所有页面？

  • AI的注意力会分散，每个页面都只做一半
  • 出错时无法定位是哪个页面的问题
  • 无法逐个确认，最终拿到手的一堆代码没法用

正确的做法：

  • 每次对话只聚焦一个页面
  • 生成后先在本地运行查看效果
  • 确认满意后再进行下一个页面
  • 如果某个页面有问题，回到那个页面单独修改，不影响其他页面

3.4 代码审查：AI生成的代码怎么看对不对

AI生成的代码不能直接相信，需要基本审查能力。以下是审查清单：

检查项怎么看常见问题
依赖是否安装查看package.jsonAI可能用了未安装的库
组件是否正确引用检查import语句AI可能引用了不存在的组件
API路径是否一致对比前后端路由AI可能前后端路由不匹配
样式是否生效运行后肉眼检查Tailwind类名拼写错误
数据库连接检查.env配置缺少环境变量或连接字符串错误
错误处理查看try-catch块AI经常省略错误处理

最简单的审查方法：运行项目，看报错。有报错就说明有问题，让AI修复即可。没有报错不代表没问题，但至少说明代码能跑。

3.5 常见陷阱

陷阱一：AI"幻觉"出不存在的API

AI有时会编造不存在的函数或属性。例如：

javascript
// AI可能生成：
const data = await db.users.findAll()  // findAll不存在于Prisma

对策：让AI生成的代码使用你已经确认过的API。如果不确定，先用官方文档查一下。

陷阱二：AI过度设计

AI倾向于生成过于复杂的代码。一个简单的页面，AI可能给你整一套状态管理模式、一个自定义Hook、三个组件文件。

对策：在提示词中明确要求"保持简单"、"用最少的代码实现"、"不要过度设计"。

陷阱三：AI忽略响应式

AI生成的代码往往是桌面端优先的，手机端适配可能一团糟。

对策：在每次页面描述的提示词中，显式加上响应式要求。

陷阱四：AI忘记处理空状态

列表页没有数据时显示什么？AI经常忽略空状态的UI。

对策：在提示词中加上"空状态处理"的要求，比如"当列表为空时显示'暂无数据'的占位提示"。

4. 前端交互逻辑 ​

4.1 表单处理：用户输入、验证、提交

表单是用户与产品交互的主要方式。一个完整的表单处理流程包含：

  • 用户输入：表单字段的获取
  • 前端验证：必填项检查、格式校验
  • 提交数据：发送到后端API
  • 反馈结果：成功提示或错误信息

React中的表单处理模式：

javascript
// 受控组件模式
const [formData, setFormData] = useState({ amount: '', category: '' })

const handleSubmit = async (e) => {
  e.preventDefault()
  // 验证
  if (!formData.amount || !formData.category) {
    alert('请填写完整信息')
    return
  }
  // 提交
  const res = await fetch('/api/records', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(formData)
  })
  // 反馈
  if (res.ok) {
    alert('添加成功')
    setFormData({ amount: '', category: '' })
  }
}

让AI写表单的技巧：

  • 明确每个字段的类型、是否必填、长度限制
  • 明确提交成功和失败的UI反馈
  • 明确是否需要加载状态（防止重复提交）

4.2 状态管理

状态管理的选择取决于应用复杂度：

复杂度方案适用场景
简单useState单个组件内的状态
中等useReducer组件内有多个相互关联的状态
中等Context API跨组件共享状态（主题、用户信息）
复杂Zustand / Jotai大型应用的全局状态

新手建议：先用useState和Context。够用再说。不要一上来就引入Redux或Zustand，你的第一个产品大概率不需要。

Context的典型用法：

javascript
// 创建全局状态
const UserContext = createContext()

function UserProvider({ children }) {
  const [user, setUser] = useState(null)
  return (
    <UserContext.Provider value={{ user, setUser }}>
      {children}
    </UserContext.Provider>
  )
}

// 子组件中使用
const { user, setUser } = useContext(UserContext)

4.3 路由导航

Next.js使用文件系统路由，这是它相比React Router最大的优势之一。

  • 创建 app/page.js 就是首页
  • 创建 app/dashboard/page.js 就是 /dashboard 页面
  • 创建 app/blog/[slug]/page.js 就是动态路由

页面间跳转：

javascript
// Next.js 13+ 的app router
'use client'
import { useRouter } from 'next/navigation'

function MyComponent() {
  const router = useRouter()
  return (
    <button onClick={() => router.push('/dashboard')}>
      去仪表盘
    </button>
  )
}

路由保护的典型模式：

  • 在页面组件中检查用户登录状态
  • 未登录时重定向到登录页
  • 用Layout组件包裹需要认证的路由组

4.4 动画和过渡

不需要自己写动画库，AI能帮你生成。关键是知道要什么效果：

效果实现方式适用场景
淡入淡出CSS opacity transition页面加载、模态框
滑动CSS transform translate侧边栏、下拉菜单
缩放CSS transform scale按钮点击、卡片hover
骨架屏CSS渐变动画数据加载等待

让AI生成动画的提示词技巧：

  • 描述触发条件："鼠标悬停时"、"组件挂载时"、"点击后"
  • 描述运动方式："从左向右滑入"、"渐显"、"弹性缩放"
  • 描述时长："300ms过渡"、"500ms动画"

4.5 AI协作：让AI帮你写交互逻辑的技巧

交互逻辑是AI编程最容易出错的环节，因为涉及多个组件的联动。协作要点：

  • 先画草图：用纸笔画出页面布局和交互流程，再让AI实现
  • 描述数据流：明确告诉AI数据从哪里来、到哪里去
  • 分步实现：先做基础功能，再做增强效果
  • 让AI解释：不理解某段交互代码时，让AI逐行解释

示例提示词：

"在账单列表页面，我需要以下交互：
1. 页面加载时从API获取数据
2. 数据加载期间显示骨架屏
3. 加载完成后渲染列表
4. 每条记录支持左滑删除
5. 删除后重新拉取列表
请按这个顺序生成代码，每一步确认无误后再进行下一步。"

5. 数据层：存储和读取用户数据 ​

5.1 数据库基本概念

不需要成为数据库专家，但需要理解三个核心概念：

  • 表（Table）：相当于Excel的一张工作表，存放一类数据。比如"用户表"、"账单表"。
  • 行（Row）：表中的一条记录。比如用户表中的一行就是一个用户的信息。
  • 字段（Column）：表中的一个属性。比如用户表有"姓名"、"邮箱"、"密码"三个字段。

5.2 用AI生成数据库Schema

Schema定义了数据的结构和关系。让AI生成Schema的提示词：

"请为个人记账App设计数据库Schema，需要以下表：
1. 用户表：id、email、password_hash、created_at
2. 账单表：id、user_id、amount、type(收入/支出)、category、note、created_at
3. 分类表：id、name、type(收入/支出)、icon

关系：
- 一个用户可以有多条账单
- 账单关联一个分类

请使用Prisma ORM的schema.prisma格式输出。"

AI生成的Schema需要检查的点：

  • 外键关系是否正确
  • 字段类型是否合理（金额用Decimal不要用Float）
  • 索引是否覆盖了常用查询字段
  • 是否有必要的时间戳字段

5.3 CRUD操作：增删改查的AI实现

CRUD是后端开发的核心。在AI编程时代，你不需要手写这些操作：

操作提示词示例
Create（创建）"创建一个API路由 POST /api/records，接收金额、类型、分类、备注，保存到数据库"
Read（读取）"创建一个API路由 GET /api/records，支持按月份筛选，返回分页结果"
Update（更新）"创建一个API路由 PUT /api/records/:id，更新指定记录的金额和分类"
Delete（删除）"创建一个API路由 DELETE /api/records/:id，删除指定记录"

用Prisma的CRUD示例：

javascript
// Create
await prisma.record.create({
  data: { amount, type, category, userId }
})

// Read
await prisma.record.findMany({
  where: { userId, month },
  orderBy: { createdAt: 'desc' }
})

// Update
await prisma.record.update({
  where: { id },
  data: { amount, category }
})

// Delete
await prisma.record.delete({
  where: { id }
})

5.4 文件上传：图片、文档的处理

文件上传是相对复杂的场景，AI能帮你处理，但需要明确细节：

  • 上传到哪里：本地磁盘、Cloudinary、AWS S3
  • 文件大小限制：图片不超过5MB
  • 文件类型限制：只允许jpg/png
  • 命名策略：用UUID重命名，避免中文文件名问题

提示词示例：

"实现头像上传功能：
- 使用Cloudinary作为存储服务
- 只接受jpg/png，最大5MB
- 上传后返回图片URL
- 前端使用拖拽上传，带进度条
- 删除旧头像时同步删除Cloudinary上的文件"

5.5 数据安全：认证、授权、数据隔离

安全不是上线前才考虑的事，从一开始就要设计。

认证（你是谁）：

  • 新手推荐：NextAuth.js（原NextAuth），支持邮箱密码、Google登录、GitHub登录
  • AI生成认证流程的提示词："用NextAuth.js实现邮箱密码登录，包含注册、登录、忘记密码功能"

授权（你能做什么）：

  • 用户只能操作自己的数据，不能查看他人的
  • 在API层做数据隔离，不要信任前端传来的userId

数据隔离的实现：

javascript
// 错误做法：信任前端传来的userId
const records = await prisma.record.findMany({
  where: { id: req.body.recordId }  // 用户可以删除别人的记录！
})

// 正确做法：从session中获取userId
const session = await getSession()
const records = await prisma.record.findMany({
  where: { id: req.body.recordId, userId: session.user.id }
})

AI协作的安全检查清单：

  • [ ] 所有API路由是否做了身份验证？
  • [ ] 数据查询是否都带了userId过滤？
  • [ ] 敏感信息（密码、密钥）是否没有硬编码在代码中？
  • [ ] 环境变量是否添加到.gitignore？
  • [ ] 前端是否没有暴露API密钥？

6. AI协作修改与Debug ​

6.1 如何让AI修改已有代码

修改已有代码比从头生成更难，因为AI需要理解现有代码的上下文。

有效的方法：

  • 指明文件路径：告诉AI具体修改哪个文件的哪一部分
  • 说明改动原因：AI理解了为什么改，才能改得正确
  • 限定改动范围：明确告诉AI"只改这里，不要动别的"

对比两种提示词：

差的提示词：
"把登录页改好看一点"

好的提示词：
"修改 app/login/page.js 中的登录表单。
当前问题是输入框太窄，在手机上看不全。
改成：输入框宽度100%，圆角12px，padding 16px，
标签文字加粗，颜色用#1E293B。
不要修改其他组件，只改这个文件。"

6.2 Bug描述的技巧

AI Debug的效率，取决于你描述Bug的准确度。

好的Bug描述包含四个要素：

要素说明示例
上下文在什么页面、什么操作后出现的"在账单列表页，添加了3条记录后"
期望行为你觉得应该发生什么"应该显示3条记录"
实际行为实际发生了什么"只显示了2条，第三条不见了"
错误信息控制台报错、网络请求失败等"Network Error: 404 Not Found"

完整示例：

Bug：账单列表分页异常

上下文：在 /dashboard 页面，我添加了25条测试记录。

期望行为：列表应该显示10条/页，共3页。

实际行为：第一页显示10条正常，点击"下一页"后页面空白，控制台报错：
"TypeError: Cannot read properties of undefined (reading 'map')"

错误信息：
at RecordList (app/dashboard/page.js:45:28)
at Component (react-dom.development.js:18132:0)

相关代码片段：
const records = data?.records ?? []
return records.map(r => <RecordCard key={r.id} {...r} />)

6.3 调试方法论：二分法定位问题

当Bug比较复杂时，用二分法定位：

  • 第一步：确定Bug发生的范围。是前端问题还是后端问题？
  • 第二步：缩小范围。如果是前端，是哪个组件？如果是后端，是哪个API？
  • 第三步：逐层排除。从大到小，像二分查找一样快速收敛
  • 第四步：定位根因。找到问题后，分析为什么会这样

AI在二分法中的角色：

  • 你负责提出假设："可能是API返回的数据格式不对"
  • AI负责验证："让我检查一下API的响应和前端的数据解析"
  • 你负责决策："确认了，是后端少返回了一个字段"
  • AI负责修复："修复代码并解释改动"

6.4 AI Debug的效率提升

传统Debug流程：

  1. 看错误信息 -> 2. 搜索StackOverflow -> 3. 阅读文档 -> 4. 猜测原因 -> 5. 尝试修复 -> 6. 验证

AI Debug流程：

  1. 贴错误信息 + 上下文 -> 2. AI分析可能的原因 -> 3. AI给出修复方案 -> 4. 你确认 -> 5. AI直接修改代码

时间对比：

场景传统DebugAI Debug
拼写错误5-15分钟30秒
API路径错误10-30分钟1分钟
数据库查询问题30-60分钟5分钟
组件状态不一致1-3小时15分钟
跨组件数据流Bug2-6小时30分钟

关键差异不在于AI有多聪明，而在于AI能同时读取多个文件、理解项目结构、搜索历史对话。你不需要自己记住所有上下文。

6.5 代码质量保障

AI生成的代码需要质量保障，否则越积越多，最后变成屎山。

三道防线：

第一道：Lint

  • ESLint自动检查代码规范
  • 让AI在生成代码时自动运行lint
  • 提示词中加入"代码需要通过ESLint检查"

第二道：手动Review

  • 每次AI提交代码后，至少抽查关键文件
  • 重点关注：数据流、安全性、边界情况
  • 不需要逐行看，但要看懂主干逻辑

第三道：测试

  • 新手不必一开始就写测试
  • 但至少要对核心功能做手动测试
  • 测试清单：
    • [ ] 正常流程能跑通吗？
    • [ ] 空数据能处理吗？
    • [ ] 错误输入有反馈吗？
    • [ ] 网络断开有提示吗？
    • [ ] 手机端显示正常吗？

7. 完整实战案例：从0到上线 ​

7.1 案例：个人记账Web App

下面展示一个完整的两天开发案例。产品名"随手记"，核心功能：快速记账、账单列表、月度统计。

技术栈：Next.js + Tailwind CSS + Prisma + SQLite + Vercel

7.2 第一天：产品定义 + 首页 + 数据层

上午（3小时）：

  • 09:00-09:30 产品定义

    • 电梯演讲："随手记是一个极简记账工具，帮助月光族3秒记录每一笔支出"
    • P0功能：添加记录、查看列表、月度统计
    • 用户故事x3，写入PRD.md

  • 09:30-10:00 项目初始化

    • npx create-next-app@latest suishouji --typescript --tailwind
    • 配置Prisma：npx prisma init
    • 设计Schema：用户表、账单表、分类表
    • 运行迁移：npx prisma migrate dev

  • 10:00-12:00 首页生成

    • 提示词："创建landing page，大标题'轻松记账告别月光'，CTA按钮'开始使用'"
    • AI生成代码 -> 本地运行 -> 调整间距和字号
    • 添加三个功能卡片："3秒记账"、"月度统计"、"智能分类"
    • 响应式适配手机端

下午（4小时）：

  • 13:00-15:00 数据层API

    • 提示词："创建API路由 POST /api/records，接收金额、类型、分类，存入数据库"
    • 创建GET /api/records，支持月份筛选
    • 创建DELETE /api/records/:id
    • 每个API都加了错误处理和输入验证

  • 15:00-17:00 添加记录页面

    • 表单：金额输入、类型选择（收入/支出）、分类下拉、备注
    • 提交后跳转到账单列表
    • 表单验证：金额为正数、分类必选

关键决策点：

  • 选择SQLite而非PostgreSQL：因为是个人工具，数据量小，SQLite零配置
  • 选择NextAuth而非自建认证：NextAuth开箱即用，支持邮箱密码登录
  • 选择Prisma而非直接写SQL：AI对Prisma的生成质量远高于raw SQL

7.3 第二天：交互逻辑 + 测试 + 部署

上午（3小时）：

  • 09:00-10:30 账单列表页

    • 列表渲染：金额、分类、备注、日期
    • 左滑删除功能
    • 空状态：显示"还没有记账，快去记一笔吧"
    • 分页：每页10条

  • 10:30-12:00 月度统计页

    • 总收入、总支出、结余的大数字展示
    • 分类占比饼图（使用recharts库）
    • 按月切换功能

下午（3小时）：

  • 13:00-14:30 测试

    • 正常流程测试：添加->查看->删除，全流程跑通
    • 边界测试：金额为0、负数、超大数字
    • 空数据测试：新用户第一次打开
    • 手机端测试：iPhone SE尺寸下的显示效果
    • 发现2个Bug：分页参数错误、饼图数据格式不对，让AI修复

  • 14:30-15:30 部署

    • 代码push到GitHub
    • Vercel连接GitHub仓库，自动部署
    • 配置环境变量：DATABASE_URL、NEXTAUTH_SECRET
    • 验证线上地址可访问

  • 15:30-16:00 收尾

    • 添加favicon和meta标签
    • 生成OG image（分享给微信/Twitter时的预览图）
    • 写README.md：项目介绍、技术栈、启动方式

7.4 实际耗时统计

环节耗时
产品定义（PRD）30分钟
项目初始化30分钟
首页生成2小时
数据层API2小时
添加记录页2小时
账单列表页1.5小时
月度统计页1.5小时
测试和Bug修复2小时
部署上线1小时
收尾工作30分钟
总计约14小时（2天）

7.5 从Demo到可展示产品的标准

很多产品停留在Demo阶段，原因是不知道"可展示"的标准是什么。以下是检查清单：

功能层面：

  • [ ] 核心功能完整可用，不是假数据
  • [ ] 空状态有提示，不是空白页面
  • [ ] 错误有反馈，不是静默失败
  • [ ] 移动端能正常使用

视觉层面：

  • [ ] 字体大小一致，没有忽大忽小
  • [ ] 颜色不超过3种主色
  • [ ] 间距统一，没有随意调整的像素
  • [ ] 加载状态有提示，不是卡住不动

体验层面：

  • [ ] 页面切换有过渡效果
  • [ ] 按钮点击有反馈（变色/缩放）
  • [ ] 表单提交后有成功提示
  • [ ] 操作有撤销机制（尤其是删除）

技术层面：

  • [ ] 代码能通过ESLint检查
  • [ ] 没有console.error
  • [ ] 环境变量正确配置
  • [ ] 线上地址可正常访问

7.6 关键心得

  • 第一天最重要：产品定义 + 核心页面 + 数据层，这三样搭好了，后面就是填肉
  • AI生成代码的速度很快，但审查和调整的时间不可省略。不要跳过Review
  • 部署比想象中简单。Vercel + GitHub的零配置部署，新手也能一次成功
  • 14小时做出一个可展示的产品，这在AI时代是常态。传统开发需要2-4周
  • 不要追求完美。第一个产品的目标是验证想法，不是写出生产级代码。能用就行

Released under the MIT License.

Copyright © 2026 qlxxkj