作者bugyuan标签Vibe CodingAI编程MVPCursorClaude产品开发零代码交付阅读时长约 25 分钟写作背景一次真实的 48 小时实验从想法到上线先说结果产品名BriefMate—— 一个帮助用户把长文章/会议录音一键转成结构化简报的 SaaS 工具。用户可上传文档或粘贴文本AI 自动提炼摘要、要点、行动项支持导出 PDF / Markdown有用户注册登录、订阅计划、使用额度管理48 小时内完成全程没有手写一行代码。不是玩具不是截图演示。在文章最后有线上地址。这篇文章记录的是完整的过程、工具选择、遇到的坑以及我对Vibe Coding 到底是什么这件事最后的判断。什么是 Vibe Coding这个词是 Andrej Karpathy 在 2025 年初造的。原话大意是你完全沉浸在项目里不在乎代码本身只描述你想要什么让 AI 生成你接受它、运行它、报错了就把错误扔回给 AI 继续修。你甚至不读那些代码。这听起来像在开玩笑但它描述的其实是一种真实的工作流转变程序员从写代码的人变成描述需求审查结果的人。Vibe Coding 不等于不懂技术也能开发这是最常见的误解。它更像是技术背景决定了你能描述多精确的需求决定了你能发现多深层的问题决定了你能把 AI 推多远。我的十年技术背景在这 48 小时里用到了每一处——只是用的方式完全不同。工具栈选择在开始之前花了大约两个小时确定工具组合。选择的标准只有一个AI 对这套技术栈的理解有多深。前端Next.js 14 (App Router) Tailwind CSS shadcn/ui 后端Next.js API Routes全栈减少跨服务复杂度 数据库SupabasePostgreSQL Auth Storage 一体 AIAnthropic Claude API文档处理核心 支付Stripe订阅 额度管理 部署Vercel一键部署免运维 AI 编程工具Cursor主力 Claude.ai架构设计讨论为什么这套组合这些技术有一个共同特点它们都是 2022 年后的主流选型AI 训练数据里充斥着大量相关代码LLM 对它们的掌握程度远高于老旧技术栈。用 Spring Boot Oracle 来做 Vibe Coding 会痛苦得多不是因为技术差是因为 AI 对这套组合的肌肉记忆更强。Day 10~24小时从混沌到跑通核心流程第一步用 Claude 做架构设计不是写代码是对话在 Cursor 第一行代码之前我在 Claude.ai 里花了一个半小时做需求澄清和架构对话。我的提问方式不是帮我设计一个 SaaS 系统而是刻意把约束条件说清楚我要在 48 小时内独立交付一个 SaaS MVP技术栈是 Next.js 14 Supabase Stripe Vercel。 核心功能 1. 用户上传文档PDF/txt/mdAI 生成结构化简报 2. 免费计划每月10次付费计划无限次 3. 简报可导出 PDF 和 Markdown 约束 - 我一个人48小时 - 不要过度设计能跑通就行 - 后续可扩展但现在不设计扩展点 请告诉我 1. 数据库表结构设计Supabase 2. 核心 API 路由设计 3. 哪些功能可以用现成服务替代不要自己造轮子 4. 48小时内最可能卡住的地方是哪里这一步产出了整个项目的骨架。Claude 给出的数据库设计-- 用户表Supabase Auth 自动创建只需扩展createtableprofiles(id uuidreferencesauth.usersprimarykey,emailtext,plantextdefaultfree,-- free / prousage_countintegerdefault0,-- 本月已用次数usage_reset_at timestamptz,-- 下次重置时间stripe_customer_idtext,stripe_subscription_idtext,created_at timestamptzdefaultnow());-- 简报表createtablebriefs(id uuiddefaultgen_random_uuid()primarykey,user_id uuidreferencesprofiles(id),titletext,source_typetext,-- text / file / urlsource_contenttext,-- 原始内容或文件路径summarytext,-- AI 生成的摘要key_points jsonb,-- 要点列表action_items jsonb,-- 行动项列表metadata jsonb,-- 字数、处理时间等created_at timestamptzdefaultnow());-- RLS 策略用户只能访问自己的数据altertablebriefsenablerowlevelsecurity;createpolicyUsers can CRUD own briefsonbriefsforallusing(auth.uid()user_id);这个设计我看了五分钟确认没问题直接在 Supabase Dashboard 里执行。零修改。第二步初始化项目10分钟npx create-next-applatest briefmate--typescript--tailwind--appcdbriefmate npx shadcn-uilatest init npx shadcn-uilatestaddbutton card input textarea dialog toast然后打开 Cursor把整个项目目录加进来。接下来的所有操作基本在 Cursor 的 Composer 里完成。第三步Cursor Composer 的正确打开方式很多人用 Cursor 的方式是让它写完整的文件然后发现效果很一般。我这次用的方式完全不同。核心原则每次只做一件事把上下文控制到最小。我不会说帮我写完用户认证模块而是在 app/auth/login/page.tsx 创建登录页面。 要求 - 使用 shadcn/ui 的 Card、Input、Button 组件 - 表单邮箱 密码一个登录按钮一个注册链接 - 调用 Supabase Auth 的 signInWithPassword - 登录成功跳转 /dashboard - 错误状态显示 Toast 提示 - 样式居中卡片简洁 Supabase client 已在 lib/supabase.ts 初始化完毕。这条 Prompt 产出了一个可以直接运行的登录页。跑起来手动测试没问题提交下一个。第四步核心功能——文档处理 Pipeline这是整个产品最核心的部分我花时间最认真地写了这条 Prompt在 app/api/brief/generate/route.ts 创建 POST 接口。 功能接收用户上传的文本内容调用 Claude API 生成结构化简报。 入参JSON { content: 原始文本内容, title: 用户给的标题可选 } 处理流程 1. 验证用户已登录从 Supabase session 获取 user_id 2. 检查用户额度profiles 表的 usage_countfree 计划 10 3. 调用 Claude API使用 claude-sonnet-4-6 模型 4. 将生成结果存入 briefs 表 5. usage_count 1 6. 返回生成的 brief 对象 Claude Prompt 要求生成 - summary200字以内的核心摘要 - key_points5~8个要点每条 1 句话 - action_items可执行的行动项如果原文有的话 返回格式严格 JSON方便前端解析。 错误处理 - 401未登录 - 429额度不足提示升级 - 500AI 调用失败 环境变量ANTHROPIC_API_KEY 已配置。Cursor 生成了这个文件我读了一遍大约 120 行发现了两个问题Claude Prompt 写得太宽泛生成质量不稳定额度检查和扣减之间没有加锁并发可能超扣这两个问题我用口语描述给 Cursor问题1Claude 的 system prompt 需要更严格要求它只输出 JSON 不要有任何解释文字否则 JSON.parse 会失败。 在 prompt 最后加你必须只返回合法的 JSON 对象 不要有任何前缀或后缀文字不要用代码块包裹。 问题2usage_count 检查和更新之间需要用 Supabase 的 select...for update 加行级锁防止并发超扣。两条修复各用了 30 秒。第一个 24 小时结束时完成了什么✅ 用户注册 / 登录 / 退出✅ 文本输入 文档上传PDF/txt✅ AI 生成简报核心功能跑通✅ 简报列表页 详情页✅ 基础的额度检查Day 224~48小时打磨、支付、上线Stripe 集成最容易踩坑的地方Stripe 是整个 48 小时里最复杂的部分不是因为代码难写是因为有太多细节需要理解Webhook 签名验证、订阅状态同步、测试卡号、沙盒环境……我的处理方式先和 Claude 聊清楚流程再让 Cursor 写代码。在 Claude.ai 里我要用 Stripe 实现一个简单的订阅系统 - 免费计划默认每月 10 次 - Pro 计划$9.9/月无限次 用户点击升级按钮 → 跳转 Stripe Checkout → 支付成功 → Webhook 通知后端 → 更新数据库 我用的是 Next.js 14 Supabase。 请帮我梳理 1. 需要哪些 Stripe API 调用 2. Webhook 需要处理哪些事件 3. 最容易出错的地方是哪里Claude 给出的流程图用户点击升级 ↓ POST /api/stripe/checkout → 创建或获取 Stripe Customer → 创建 Checkout Sessionmode: subscription → 返回 session.url ↓ 前端 redirect 到 Stripe 托管页面 ↓ 用户完成支付 ↓ Stripe POST /api/stripe/webhook 处理以下事件 ├── checkout.session.completed │ → 更新 profiles.plan pro │ → 存储 stripe_subscription_id ├── customer.subscription.deleted │ → 降级回 free └── invoice.payment_failed → 发邮件提醒这次先跳过 ↓ 用户回到 /dashboard?upgradesuccess明确了这个流程再让 Cursor 写就清晰多了创建 app/api/stripe/checkout/route.ts。 流程 1. 获取当前登录用户 2. 从 profiles 取 stripe_customer_id 没有则调用 stripe.customers.create 创建并存入数据库 3. 调用 stripe.checkout.sessions.create - mode: subscription - price: process.env.STRIPE_PRO_PRICE_ID - success_url: /dashboard?upgradesuccess - cancel_url: /pricing 4. 返回 { url: session.url } 使用 stripe npm 包已安装。 STRIPE_SECRET_KEY 在环境变量中。Webhook 处理器同理每个事件单独描述分批生成分批测试。整个 Stripe 集成花了大约 4 小时其中 1 小时是在 Stripe Dashboard 配置产品和价格1 小时是测试 Webhook用 Stripe CLI 本地转发2 小时是处理各种边界情况。让我卡了最久的问题不是技术问题是AI 生成的代码有一个隐藏 bug我花了两小时才定位到。现象用户上传 PDF 后偶尔生成的简报是乱码或截断的。我把报错扔给 Cursor它修了几次问题依然偶发。最后我决定自己读生成的 PDF 解析代码这是 48 小时里我唯一一次认真读代码发现问题所在// AI 生成的代码有 bugconsttextawaitpdf(buffer);returntext.text;// ← 这里在 PDF 很大时会截断// 正确的写法我告诉 Cursor 怎么修constdataawaitpdf(buffer);// 按页拼接保留完整内容consttextdata.Pages.map(pagepage.Texts.map(tt.R.map(rr.T).join()).join( )).join(\n);returndecodeURIComponent(text);这就是我说的技术背景的价值——我能识别出 AI 的错误在哪里能告诉它怎么修而不是在相信AI 一定是对的的前提下盲目调试。UI 打磨最后几个小时专门用来让产品看起来像一个真正的产品。这里我换了一种 Vibe Coding 方式不描述代码描述感受。现在的 Dashboard 页面感觉太工程师风格太朴素。 我希望它看起来像 Linear 或 Vercel 的 Dashboard—— 干净、现代、有层次感。 具体改动 1. 顶部加一个欢迎语Good morning, {name} 字体大带当前日期 2. 使用情况用一个漂亮的进度条展示free: 已用x/10次 3. 简报列表改成卡片网格每张卡片显示标题、摘要前50字、创建时间 4. 空状态要好看不要显示空列表 显示一个大的居中 CTA创建你的第一份简报这类 Prompt 效果非常好。UI 是 AI 最擅长的领域之一只要描述清楚感觉它能实现得比你手写快很多。上线前的最后 1 小时# 环境变量检查# Vercel 项目配置# 自定义域名绑定# Supabase 生产环境迁移把本地 SQL 在生产 DB 执行# Stripe Webhook 换成生产地址这些操作全部是手工在各个控制台里点的和写代码没关系。48 小时整BriefMate 上线。复盘Vibe Coding 真正的边界在哪里做完之后我认真想了这个问题。✅ AI 真正擅长的样板代码Boilerplate登录、注册、CRUD、表单验证——这类代码有固定的模式AI 写得又快又好准确率接近 100%。手写这些是在浪费生命。UI 组件给一个描述给一个参考“类似 Linear 的风格”AI 能快速产出可用的界面代码。已知方案的标准实现Stripe 集成、OAuth、文件上传、PDF 解析——这些有明确的官方文档和大量示例AI 的成功率很高。调试已知类型的错误把报错信息和相关代码一起扔给 AI大部分时候它能定位和修复。⚠️ AI 容易出问题的并发和竞态条件上面的额度超扣 bug 是典型例子。AI 写的单线程逻辑通常没问题但多用户并发场景下的正确性它容易忽视。性能边界AI 不会主动帮你想如果用户上传一个 100MB 的 PDF 会怎样这需要你主动提出。复杂的业务逻辑越接近真实业务的特殊规则“VIP 用户在促销期间的折扣计算”AI 越容易理解偏差需要你用非常精确的语言描述并仔细验证结果。跨文件的一致性当项目变大AI 有时会在不同文件里用不同的错误处理方式、不同的命名规范你需要主动维护一致性。❌ AI 做不了的定义做什么功能范围、优先级、哪些 feature 是 MVP 必须的——这些判断 AI 给不了。它能提建议但最终决策永远是人的。识别这个不对劲上面的 PDF 解析 bugAI 自己不知道它的输出是错的需要你运行、测试、感觉不对、深入排查。这个直觉是积累出来的不是 AI 能替代的。审美和品味AI 能实现你描述的 UI但这个设计让人想点这个判断依然是人的工作。给想尝试 Vibe Coding 的人一些真实的建议选对工具栈优先选 AI 熟悉的技术组合。不要在 48 小时内挑战用 Rust 写后端那不是 Vibe Coding那是给自己找麻烦。每次 Prompt 只做一件事上下文越小AI 的准确率越高。帮我写整个用户模块是烂 Prompt在这个文件里加一个检查邮箱格式的函数是好 Prompt。不要跳过测试。每写完一块就手动跑一下发现问题及时修不要攒到最后。Vibe Coding 的 bug 如果攒多了解决起来比传统方式更难因为你对代码的理解是浅的。遇到卡点先想清楚再让 AI 写。越复杂的问题越要先和 Claude 聊清楚逻辑再让 Cursor 实现。顺序反了会绕很多弯路。技术背景真的重要。Vibe Coding 不会让不懂技术的人变成工程师但会让工程师的产出速度提高几倍。门槛没有降低但杠杆变大了。最后48 小时一个能收钱的产品全程没有手写代码。这在两年前是不可能的。现在它是真实发生的事情。我不觉得这是程序员的终结。我觉得这更像是印刷机的发明——它不消灭了作家它让作家能写更多、传播更广。只是能写字本身从此不再是稀缺能力。真正稀缺的永远是知道该写什么知道写出来的东西对不对知道为什么它对或不对。这些依然是人的工作。
Vibe Coding 实战：不写一行代码，48小时交付完整MVP产品
发布时间：2026/5/20 1:06:36
作者bugyuan标签Vibe CodingAI编程MVPCursorClaude产品开发零代码交付阅读时长约 25 分钟写作背景一次真实的 48 小时实验从想法到上线先说结果产品名BriefMate—— 一个帮助用户把长文章/会议录音一键转成结构化简报的 SaaS 工具。用户可上传文档或粘贴文本AI 自动提炼摘要、要点、行动项支持导出 PDF / Markdown有用户注册登录、订阅计划、使用额度管理48 小时内完成全程没有手写一行代码。不是玩具不是截图演示。在文章最后有线上地址。这篇文章记录的是完整的过程、工具选择、遇到的坑以及我对Vibe Coding 到底是什么这件事最后的判断。什么是 Vibe Coding这个词是 Andrej Karpathy 在 2025 年初造的。原话大意是你完全沉浸在项目里不在乎代码本身只描述你想要什么让 AI 生成你接受它、运行它、报错了就把错误扔回给 AI 继续修。你甚至不读那些代码。这听起来像在开玩笑但它描述的其实是一种真实的工作流转变程序员从写代码的人变成描述需求审查结果的人。Vibe Coding 不等于不懂技术也能开发这是最常见的误解。它更像是技术背景决定了你能描述多精确的需求决定了你能发现多深层的问题决定了你能把 AI 推多远。我的十年技术背景在这 48 小时里用到了每一处——只是用的方式完全不同。工具栈选择在开始之前花了大约两个小时确定工具组合。选择的标准只有一个AI 对这套技术栈的理解有多深。前端Next.js 14 (App Router) Tailwind CSS shadcn/ui 后端Next.js API Routes全栈减少跨服务复杂度 数据库SupabasePostgreSQL Auth Storage 一体 AIAnthropic Claude API文档处理核心 支付Stripe订阅 额度管理 部署Vercel一键部署免运维 AI 编程工具Cursor主力 Claude.ai架构设计讨论为什么这套组合这些技术有一个共同特点它们都是 2022 年后的主流选型AI 训练数据里充斥着大量相关代码LLM 对它们的掌握程度远高于老旧技术栈。用 Spring Boot Oracle 来做 Vibe Coding 会痛苦得多不是因为技术差是因为 AI 对这套组合的肌肉记忆更强。Day 10~24小时从混沌到跑通核心流程第一步用 Claude 做架构设计不是写代码是对话在 Cursor 第一行代码之前我在 Claude.ai 里花了一个半小时做需求澄清和架构对话。我的提问方式不是帮我设计一个 SaaS 系统而是刻意把约束条件说清楚我要在 48 小时内独立交付一个 SaaS MVP技术栈是 Next.js 14 Supabase Stripe Vercel。 核心功能 1. 用户上传文档PDF/txt/mdAI 生成结构化简报 2. 免费计划每月10次付费计划无限次 3. 简报可导出 PDF 和 Markdown 约束 - 我一个人48小时 - 不要过度设计能跑通就行 - 后续可扩展但现在不设计扩展点 请告诉我 1. 数据库表结构设计Supabase 2. 核心 API 路由设计 3. 哪些功能可以用现成服务替代不要自己造轮子 4. 48小时内最可能卡住的地方是哪里这一步产出了整个项目的骨架。Claude 给出的数据库设计-- 用户表Supabase Auth 自动创建只需扩展createtableprofiles(id uuidreferencesauth.usersprimarykey,emailtext,plantextdefaultfree,-- free / prousage_countintegerdefault0,-- 本月已用次数usage_reset_at timestamptz,-- 下次重置时间stripe_customer_idtext,stripe_subscription_idtext,created_at timestamptzdefaultnow());-- 简报表createtablebriefs(id uuiddefaultgen_random_uuid()primarykey,user_id uuidreferencesprofiles(id),titletext,source_typetext,-- text / file / urlsource_contenttext,-- 原始内容或文件路径summarytext,-- AI 生成的摘要key_points jsonb,-- 要点列表action_items jsonb,-- 行动项列表metadata jsonb,-- 字数、处理时间等created_at timestamptzdefaultnow());-- RLS 策略用户只能访问自己的数据altertablebriefsenablerowlevelsecurity;createpolicyUsers can CRUD own briefsonbriefsforallusing(auth.uid()user_id);这个设计我看了五分钟确认没问题直接在 Supabase Dashboard 里执行。零修改。第二步初始化项目10分钟npx create-next-applatest briefmate--typescript--tailwind--appcdbriefmate npx shadcn-uilatest init npx shadcn-uilatestaddbutton card input textarea dialog toast然后打开 Cursor把整个项目目录加进来。接下来的所有操作基本在 Cursor 的 Composer 里完成。第三步Cursor Composer 的正确打开方式很多人用 Cursor 的方式是让它写完整的文件然后发现效果很一般。我这次用的方式完全不同。核心原则每次只做一件事把上下文控制到最小。我不会说帮我写完用户认证模块而是在 app/auth/login/page.tsx 创建登录页面。 要求 - 使用 shadcn/ui 的 Card、Input、Button 组件 - 表单邮箱 密码一个登录按钮一个注册链接 - 调用 Supabase Auth 的 signInWithPassword - 登录成功跳转 /dashboard - 错误状态显示 Toast 提示 - 样式居中卡片简洁 Supabase client 已在 lib/supabase.ts 初始化完毕。这条 Prompt 产出了一个可以直接运行的登录页。跑起来手动测试没问题提交下一个。第四步核心功能——文档处理 Pipeline这是整个产品最核心的部分我花时间最认真地写了这条 Prompt在 app/api/brief/generate/route.ts 创建 POST 接口。 功能接收用户上传的文本内容调用 Claude API 生成结构化简报。 入参JSON { content: 原始文本内容, title: 用户给的标题可选 } 处理流程 1. 验证用户已登录从 Supabase session 获取 user_id 2. 检查用户额度profiles 表的 usage_countfree 计划 10 3. 调用 Claude API使用 claude-sonnet-4-6 模型 4. 将生成结果存入 briefs 表 5. usage_count 1 6. 返回生成的 brief 对象 Claude Prompt 要求生成 - summary200字以内的核心摘要 - key_points5~8个要点每条 1 句话 - action_items可执行的行动项如果原文有的话 返回格式严格 JSON方便前端解析。 错误处理 - 401未登录 - 429额度不足提示升级 - 500AI 调用失败 环境变量ANTHROPIC_API_KEY 已配置。Cursor 生成了这个文件我读了一遍大约 120 行发现了两个问题Claude Prompt 写得太宽泛生成质量不稳定额度检查和扣减之间没有加锁并发可能超扣这两个问题我用口语描述给 Cursor问题1Claude 的 system prompt 需要更严格要求它只输出 JSON 不要有任何解释文字否则 JSON.parse 会失败。 在 prompt 最后加你必须只返回合法的 JSON 对象 不要有任何前缀或后缀文字不要用代码块包裹。 问题2usage_count 检查和更新之间需要用 Supabase 的 select...for update 加行级锁防止并发超扣。两条修复各用了 30 秒。第一个 24 小时结束时完成了什么✅ 用户注册 / 登录 / 退出✅ 文本输入 文档上传PDF/txt✅ AI 生成简报核心功能跑通✅ 简报列表页 详情页✅ 基础的额度检查Day 224~48小时打磨、支付、上线Stripe 集成最容易踩坑的地方Stripe 是整个 48 小时里最复杂的部分不是因为代码难写是因为有太多细节需要理解Webhook 签名验证、订阅状态同步、测试卡号、沙盒环境……我的处理方式先和 Claude 聊清楚流程再让 Cursor 写代码。在 Claude.ai 里我要用 Stripe 实现一个简单的订阅系统 - 免费计划默认每月 10 次 - Pro 计划$9.9/月无限次 用户点击升级按钮 → 跳转 Stripe Checkout → 支付成功 → Webhook 通知后端 → 更新数据库 我用的是 Next.js 14 Supabase。 请帮我梳理 1. 需要哪些 Stripe API 调用 2. Webhook 需要处理哪些事件 3. 最容易出错的地方是哪里Claude 给出的流程图用户点击升级 ↓ POST /api/stripe/checkout → 创建或获取 Stripe Customer → 创建 Checkout Sessionmode: subscription → 返回 session.url ↓ 前端 redirect 到 Stripe 托管页面 ↓ 用户完成支付 ↓ Stripe POST /api/stripe/webhook 处理以下事件 ├── checkout.session.completed │ → 更新 profiles.plan pro │ → 存储 stripe_subscription_id ├── customer.subscription.deleted │ → 降级回 free └── invoice.payment_failed → 发邮件提醒这次先跳过 ↓ 用户回到 /dashboard?upgradesuccess明确了这个流程再让 Cursor 写就清晰多了创建 app/api/stripe/checkout/route.ts。 流程 1. 获取当前登录用户 2. 从 profiles 取 stripe_customer_id 没有则调用 stripe.customers.create 创建并存入数据库 3. 调用 stripe.checkout.sessions.create - mode: subscription - price: process.env.STRIPE_PRO_PRICE_ID - success_url: /dashboard?upgradesuccess - cancel_url: /pricing 4. 返回 { url: session.url } 使用 stripe npm 包已安装。 STRIPE_SECRET_KEY 在环境变量中。Webhook 处理器同理每个事件单独描述分批生成分批测试。整个 Stripe 集成花了大约 4 小时其中 1 小时是在 Stripe Dashboard 配置产品和价格1 小时是测试 Webhook用 Stripe CLI 本地转发2 小时是处理各种边界情况。让我卡了最久的问题不是技术问题是AI 生成的代码有一个隐藏 bug我花了两小时才定位到。现象用户上传 PDF 后偶尔生成的简报是乱码或截断的。我把报错扔给 Cursor它修了几次问题依然偶发。最后我决定自己读生成的 PDF 解析代码这是 48 小时里我唯一一次认真读代码发现问题所在// AI 生成的代码有 bugconsttextawaitpdf(buffer);returntext.text;// ← 这里在 PDF 很大时会截断// 正确的写法我告诉 Cursor 怎么修constdataawaitpdf(buffer);// 按页拼接保留完整内容consttextdata.Pages.map(pagepage.Texts.map(tt.R.map(rr.T).join()).join( )).join(\n);returndecodeURIComponent(text);这就是我说的技术背景的价值——我能识别出 AI 的错误在哪里能告诉它怎么修而不是在相信AI 一定是对的的前提下盲目调试。UI 打磨最后几个小时专门用来让产品看起来像一个真正的产品。这里我换了一种 Vibe Coding 方式不描述代码描述感受。现在的 Dashboard 页面感觉太工程师风格太朴素。 我希望它看起来像 Linear 或 Vercel 的 Dashboard—— 干净、现代、有层次感。 具体改动 1. 顶部加一个欢迎语Good morning, {name} 字体大带当前日期 2. 使用情况用一个漂亮的进度条展示free: 已用x/10次 3. 简报列表改成卡片网格每张卡片显示标题、摘要前50字、创建时间 4. 空状态要好看不要显示空列表 显示一个大的居中 CTA创建你的第一份简报这类 Prompt 效果非常好。UI 是 AI 最擅长的领域之一只要描述清楚感觉它能实现得比你手写快很多。上线前的最后 1 小时# 环境变量检查# Vercel 项目配置# 自定义域名绑定# Supabase 生产环境迁移把本地 SQL 在生产 DB 执行# Stripe Webhook 换成生产地址这些操作全部是手工在各个控制台里点的和写代码没关系。48 小时整BriefMate 上线。复盘Vibe Coding 真正的边界在哪里做完之后我认真想了这个问题。✅ AI 真正擅长的样板代码Boilerplate登录、注册、CRUD、表单验证——这类代码有固定的模式AI 写得又快又好准确率接近 100%。手写这些是在浪费生命。UI 组件给一个描述给一个参考“类似 Linear 的风格”AI 能快速产出可用的界面代码。已知方案的标准实现Stripe 集成、OAuth、文件上传、PDF 解析——这些有明确的官方文档和大量示例AI 的成功率很高。调试已知类型的错误把报错信息和相关代码一起扔给 AI大部分时候它能定位和修复。⚠️ AI 容易出问题的并发和竞态条件上面的额度超扣 bug 是典型例子。AI 写的单线程逻辑通常没问题但多用户并发场景下的正确性它容易忽视。性能边界AI 不会主动帮你想如果用户上传一个 100MB 的 PDF 会怎样这需要你主动提出。复杂的业务逻辑越接近真实业务的特殊规则“VIP 用户在促销期间的折扣计算”AI 越容易理解偏差需要你用非常精确的语言描述并仔细验证结果。跨文件的一致性当项目变大AI 有时会在不同文件里用不同的错误处理方式、不同的命名规范你需要主动维护一致性。❌ AI 做不了的定义做什么功能范围、优先级、哪些 feature 是 MVP 必须的——这些判断 AI 给不了。它能提建议但最终决策永远是人的。识别这个不对劲上面的 PDF 解析 bugAI 自己不知道它的输出是错的需要你运行、测试、感觉不对、深入排查。这个直觉是积累出来的不是 AI 能替代的。审美和品味AI 能实现你描述的 UI但这个设计让人想点这个判断依然是人的工作。给想尝试 Vibe Coding 的人一些真实的建议选对工具栈优先选 AI 熟悉的技术组合。不要在 48 小时内挑战用 Rust 写后端那不是 Vibe Coding那是给自己找麻烦。每次 Prompt 只做一件事上下文越小AI 的准确率越高。帮我写整个用户模块是烂 Prompt在这个文件里加一个检查邮箱格式的函数是好 Prompt。不要跳过测试。每写完一块就手动跑一下发现问题及时修不要攒到最后。Vibe Coding 的 bug 如果攒多了解决起来比传统方式更难因为你对代码的理解是浅的。遇到卡点先想清楚再让 AI 写。越复杂的问题越要先和 Claude 聊清楚逻辑再让 Cursor 实现。顺序反了会绕很多弯路。技术背景真的重要。Vibe Coding 不会让不懂技术的人变成工程师但会让工程师的产出速度提高几倍。门槛没有降低但杠杆变大了。最后48 小时一个能收钱的产品全程没有手写代码。这在两年前是不可能的。现在它是真实发生的事情。我不觉得这是程序员的终结。我觉得这更像是印刷机的发明——它不消灭了作家它让作家能写更多、传播更广。只是能写字本身从此不再是稀缺能力。真正稀缺的永远是知道该写什么知道写出来的东西对不对知道为什么它对或不对。这些依然是人的工作。
 SMD 板对板与背板连接器)
