拖了很久，终于把这篇复盘写完了。记录了我如何借助 TRAE，把一个想法一步步做成真正上线的产品，希望也能给有产品想法的你一点参考。
原文链接在此 https://mp.weixin.qq.com/s/mwwUPCDgb77LlTdhR9Lotg
欢迎各位大佬关注我的公众号：#中登前端自救之旅，会分享失业后寻求 agent 转型的实操与思考，十分感谢~
下面进入正文：
前段时间，我参加了 TRAE AI 大赛，做了一款叫 Shake Drink Talk 的 H5 小产品。
它的核心逻辑很简单。
用户进入页面，先抽一张调酒卡，按照配方和步骤调一杯简单的便利店调酒。调完之后，再抽一张聊天话题卡，两个人就着这个话题聊一次更深入的交流。
听起来不复杂对吧。
但做这个产品的起点，其实不是一个多宏大的商业想法。它更像是一个很小的生活观察。我发现很多情侣不是不想认真聊天，而是缺少一个自然、不尴尬、又有点仪式感的开场。调酒在这里不是目的，它只是一个入口。真正想解决的问题，是让两个人更容易进入一次认真对话。
如果只是做个静态 Demo，这件事并不难。
但我这次想完整走一遍从想法到上线的流程。也就是说，它不只是一个前端页面，还要有数据库、图片存储、API、部署地址，最好还有后续继续扩展的空间。
这对我来说有一点挑战。
我是前端出身，页面、交互、组件这些相对熟悉，但后端、数据库、云存储、部署、域名解析，都不是我的舒适区。过去做类似小产品，我很容易做成一个纯前端 Demo，能展示，但离真正上线还有一段距离。
这次借着 TRAE AI 大赛，我想逼自己把这段距离走完。
7 月 22 日那天，TRAE AI 大赛的复赛名单公布了。
我刷新了好几遍页面，没看到 Shake Drink Talk 的名字。
说不失落是假的。毕竟从一句粗糙的 idea，到一个真的能打开、能交互、有数据、有图片、能部署的小产品，中间确实花了不少时间。没进复赛，当然会有一瞬间的「啊，就这样了吗」。
但缓过来之后，我又觉得，这次经历里最值钱的部分，其实根本不在那张名单上。
它在于我真的完整走了一遍「从想法到上线」。对于一个前端出身的人来说，能把后端、数据库、云存储、部署、域名这些原本不太敢碰的东西全部串起来，这比一个比赛结果重要太多了。
所以我决定，还是把整个过程拆出来。
不是想诉苦，也不是想证明自己有多努力。这篇文章不是单纯介绍 Shake Drink Talk，也不是只讲 Next.js 或 Supabase 怎么配置。我更想拆解的是，一名偏前端的开发者，怎么借助 TRAE 和 Agent，把一个粗糙想法一步一步推进成一个可以访问、可以演示、可以继续迭代的小产品。
如果你也有一个想法，但不知道怎么开始，希望这篇文章能给你一条可以照着走的路线。
其实这篇文章早就该动笔了。
但坦率的讲，我拖延症晚期，一拖再拖，鸽了很久。
中间通过 TRAE 和各种线下活动认识的小伙伴，催了我好多次。每次见面或聊天，基本都会问一句，你那篇复盘到底什么时候出。
所以最近又熬了几个大夜，把这篇文章翻来覆去改了很多版。
不是为了追求完美，而是想尽量把每个点都写透写细。因为既然决定要拆，就不希望只是浮在表面。
那我们从头说起。
<timeline>
\- 2026.06.25 | 项目启动 | 爬取 6.25 之前的报名帖，让 AI 帮我分析大家都在做些什么
\- 2026.06.29 | 提交报名 | 让 TRAE 帮我完成需求拆解，以及 demo 展示
\- 2026.07.01 - 2026.07.05 | 详细开发 | 让 TRAE 帮我不断完善代码
\- 2026.07.08 | 数据整理及入库 | 让 TRAE 帮我将数据整理成 json，后期存储到 supabase 中去
\- 2026.07.09 - 2026.07.11 | 图片素材生成及入库 | 让豆包帮我批量生成所需要的图片素材，用百度图片助手抠图，批量上传到 supabase 中存储
\- 2026.07.12 | 部署上线 | 腾讯云购买域名
\- 2026.07.13 | 完成初赛贴 |
</timeline>
01 把想法整理成需求文档
我最开始给 TRAE 的输入其实非常粗糙，大概就是想做一个情侣调酒聊天应用。
这个输入并不适合直接写代码。
因为它只描述了一个方向，没有说明用户是谁、页面怎么流转、数据怎么组织、第一版应该做到什么程度。如果直接让 AI 开始写，它大概率会根据自己的理解生成一套看似完整、但很难贴合真实需求的代码。
所以我先在 TRAE 中安装了 brainstorming 这个 skill。用过的都知道，superpowers 这个插件到底有多强大，/brainstorming 可以把这个模糊想法整理成需求文档。
/brainstorming 我想参加 trae ai 创造力大赛，我的创意如下：很多情侣有时候缺乏深度沟通，想做一个可以一边调酒，一边让生成随机话题让情侣进行深度沟通的小程序或者 h5。请将我的创意整理成详细的需求文档。请先用苏格拉底提问法向我确认我的需求，直到你 95% 搞清楚后，再开始生成需求文档。
什么是苏格拉底提问法？
通过连续地提出问题，让被提问者通过理性思考，发现谬误、拓宽思路、获得启发、找到真相的过程，最终得出自己的结论。
核心就在于苏格拉底提问法，它会将你的需求不断拆解得很细，然后来跟你确认。
就比如说，
TRAE 前前后后向我确认了 15 个问题，最终帮我完成了需求文档的编写。
这一步的价值不只是生成一份文档，而是把一堆没有成型的想法压成可以执行的结构。
在这个过程中，AI 会引导我梳理几件事。
产品面向谁。
核心使用场景是什么。
用户从进入页面到完成一次体验，要经过哪些步骤。
第一版 MVP 必须跑通哪条链路。
哪些页面是必要的，哪些功能可以暂时不做。
数据大概需要哪些表，什么样的数据结构。
图片应该放在哪里。
前端页面和后端接口怎么分工。
这些问题看起来基础，但对 AI 辅助开发非常重要。AI 写代码的质量，很大程度取决于你给它的上下文质量。如果需求本身是模糊的，后面代码越写越偏，修起来反而更累。
我当时通过这一步明确了一个关键判断，Shake Drink Talk 里，调酒不是主角，沟通才是主角。
调酒卡负责制造仪式感，聊天话题负责承接真正的产品价值。
这个判断确定后，MVP 就清楚了。
首页只需要完成抽取调酒卡。
详情页展示配方、步骤和图片。
调酒完成后进入话题抽取。
用户看到一个适合当前场景的聊天话题。
第一版只要把这条链路跑通，产品就成立了。
这里有一个很重要的经验。
不要一开始就做完整产品。
用户系统、收藏、历史记录、解锁机制、分享海报、打卡功能，这些都可以后面再加。第一版最重要的是跑通最小闭环。只有最小闭环跑通了，后面的打磨才有意义。
02 确定 UI 风格
做 AI 辅助开发时，很多人会直接对 AI 说，帮我做一个好看的页面。
这个表达太宽泛了。
AI 确实会生成页面，但生成出来的结果往往比较模板化。常见问题是大圆角、渐变背景、毛玻璃、居中大标题、几个标准按钮，看起来不差，但缺少明确的产品气质。
所以我一般不会直接让它自由发挥，而是先去找参考图。
推荐一个让 AI 更好理解 UI 风格的网站，https://styles.refero.design/，里面会将参考网站的 UI 样式拆解出来，便于写代码的时候更好的理解。
直接复制里面的 DESIGN.md 文件，给到你的 AI 工具，它会遵循这套 UI 规范去设计你的页面。
我想尝试的风格在这个网站没找到，后来去花瓣、美叶找了找，让 gpt-image-2 帮我生成了一些参考图。
我这次想要的方向更偏新粗野风格。
我参考了 YouMind 上一些 GPT Image 2 prompt 展示站的视觉形式。它们通常有高对比色块、明显的边框、强阴影、清晰的卡片结构，视觉上更直接，也更适合做一个有记忆点的 H5 产品。
但 Shake Drink Talk 又不是一个纯工具产品，它面向情侣沟通，所以我不希望页面太冷、太硬。最终我的偏好是，在新粗野的结构基础上，保留圆角、绿色主色和比较温和的视觉氛围。
这里我没有只给 AI 一句风格描述。
我给了截图。
然后明确告诉它，页面里需要出现哪些内容，布局上哪些信息最重要，哪些组件要保持一致，整体更偏圆角和绿色，重复出现的卡片与按钮尺寸要统一。
这一步非常影响最终效果。
AI 做 UI 时，最容易出现的问题不是单个页面不能看，而是页面之间不统一。
首页卡片是一种尺寸，详情页卡片又变成另一种尺寸。按钮圆角不一致，阴影不一致，间距也不一致。用户说不出哪里有问题，但整体就会显得不完整。
所以我会不断把反馈具体化。
不是说不好看，而是告诉它，首页、调酒卡页面、调酒步骤页面、话题签页面、话题页面顶部组件需要同高，页面底部按钮高度要统一，绿色不要过脏，页面留白要更稳定，重复组件不要每个页面重新设计。
这也是我建议大家使用 AI 做 UI 时采用的方式。
先给参考图，再给希望出现的元素及呈现形式，如果可以给出具体的尺寸或者颜色，最后再给一致性要求。
如果第一版不对，不要急着推翻。把问题拆成具体的视觉反馈，让 AI 一轮一轮改。AI 不擅长猜审美，但它很擅长根据明确反馈快速调整。
03 技术选型
这次项目我选择的是 Next.js + Supabase。
原因并不复杂。
Next.js 对前端开发者比较友好。页面、路由、组件、API 都可以放在一个项目里完成，适合快速做一个 H5 应用。
Supabase 则提供了数据库、云存储、权限控制等能力。对一个小产品来说，它可以承担大部分后端基础设施，不需要一开始自己搭完整服务。
如果你要做的是卡片类 H5 应用，比如调酒卡、塔罗卡、菜谱卡、旅行灵感卡，这套组合已经足够完成第一版。
在数据库设计上，我建议先做减法。
我的真实表结构里，除了 cocktails 和 topics，还设计过 users、sessions、user_unlocks 等表，用来支持用户、会话和解锁记录。
但如果目标是让一个小白能复刻 MVP，第一版完全可以先不讲这些。
核心只需要两张表。
cocktails 负责调酒卡。
它可以包含 name、meaning、description、ingredients、steps、image_url、theme_color、category、base_liquor、vibe_tag 等字段。
其中 ingredients 和 steps 我会用 JSONB 存储。
原因是配料和步骤天然是列表。它们不适合拆成固定列，用 JSONB 会更灵活。比如某些酒有三步，某些酒有五步，用列表结构更容易展示。
\-- cocktails table
CREATE TABLE IF NOT EXISTS cocktails (
id UUID PRIMARY KEY DEFAULT uuid_generate_v4(),
name TEXT NOT NULL,
meaning TEXT NOT NULL,
description TEXT NOT NULL,
ingredients JSONB NOT NULL DEFAULT '\[\]',
steps JSONB NOT NULL DEFAULT '\[\]',
image_url TEXT,
theme_color TEXT NOT NULL DEFAULT '#FF6B9D',
theme_gradient_start TEXT NOT NULL DEFAULT '#87CEEB',
theme_gradient_mid TEXT NOT NULL DEFAULT '#FFD93D',
theme_gradient_end TEXT NOT NULL DEFAULT '#FF8C42',
type TEXT NOT NULL DEFAULT 'cocktail',
category TEXT NOT NULL DEFAULT '便利店调酒',
base_liquor TEXT,
vibe_tag TEXT,
source TEXT,
created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);
topics 负责聊天话题。
它可以包含 content、category、depth_level、relationship、is_ai_generated、source 等字段。
这里的 depth_level 很重要。
因为聊天话题是有深浅关系的。第一轮话题适合轻一点，后面才适合进入更深的关系表达。如果一开始就给出太重的话题，用户体验会比较突兀。
relationship 字段则用于标记适用关系。第一版可以只支持 couple，后面如果想扩展到朋友、家人、同事，也有继续扩展的空间。
\-- topics table
CREATE TABLE IF NOT EXISTS topics (
id UUID PRIMARY KEY DEFAULT uuid_generate_v4(),
content TEXT NOT NULL,
category TEXT NOT NULL DEFAULT 'general',
depth_level INT NOT NULL DEFAULT 1,
relationship TEXT\[\] NOT NULL DEFAULT ARRAY\['couple'\],
is_ai_generated BOOLEAN NOT NULL DEFAULT FALSE,
source TEXT,
created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);
图片部分不要直接放进数据库。
更合理的做法是，把图片上传到 Supabase Storage，数据库里只保存 image_url。
这样数据库负责结构化内容，Storage 负责文件，页面只需要读取 URL 展示图片。这种分工更清晰，也方便后续替换图片或调整存储策略。
如果要把这个设计抽象成通用模板，可以这样理解。
一张表存调酒卡片内容。
一张表存话题。
一个 Storage bucket 存图片。
数据库里保存图片地址。
前端页面根据 API 返回的数据进行展示。
这就是很多卡片类 H5 应用的最小数据结构。
04 封装 API
我没有让页面直接调用 Supabase，而是用 Next.js API route 做了一层封装。
页面负责展示和交互。
API route 负责处理数据请求。
Supabase 负责数据库和存储。
例如，页面需要调酒卡时，不直接写数据库查询，而是请求自己的 API。API 内部再去读取 cocktails 表，并返回页面需要的数据。
同理，随机抽取调酒卡、读取话题、按深度等级筛选话题，也可以封装到 API 层。
这样做有两个好处。
第一，页面会更干净。
第二，后续如果要调整数据来源，或者增加缓存、权限、日志，都可以在 API 层处理，不需要改动大量页面组件。
不建议页面直接调用 Supabase，不是因为这样一定不能跑，而是因为项目稍微变复杂后，会遇到维护和安全两个问题。
先说维护。
如果首页、详情页、随机抽调酒卡、话题抽取都在各自页面里直接写 Supabase 查询逻辑，后面字段一改、筛选规则一改、随机逻辑一改，就要到多个地方同步修改。
这会让项目越来越难维护。
再说安全。
Supabase 的访问逻辑、环境变量和服务端 key，最好不要散落在前端页面里。即使第一版项目很小，也应该尽量养成把数据访问逻辑收口的习惯。
这也是我建议小白跟做时特别注意的一点。
不要把所有逻辑都堆进页面。
页面只关心用户看见什么、点击什么、状态怎么变化。
数据怎么查、怎么过滤、怎么随机、怎么和 Supabase 通信，尽量交给 API 层。
这个边界一旦建立起来，后面让 AI 继续开发时也会更稳定。你可以要求它先列接口，再写页面，再联调数据，而不是让它在一个组件里把所有逻辑都写完。
05 AI 整理素材
AI 辅助开发不只是写代码。
在这个项目里，内容本身也是一部分工作量。调酒卡需要配方、步骤、描述和氛围标签。聊天话题需要分类、深度等级和适用关系。如果全部手写，会很慢，而且后期很难保持格式统一。
所以我把一部分整理工作交给了 AI。
有些调酒卡和话题参考了小红书上的内容形式，我会让 TRAE 帮我整理成更适合产品使用的结构。
还有一部分话题，我直接把视频交给 AI，让它识别里面出现的话题，再整理成可以导入 topics 表的数据。
这些经历让我意识到，一个产品里有很多工作都适合交给 AI。
比如从视频、图文、笔记里提取内容。
比如把散乱素材整理成统一字段。
比如生成符合数据库结构的 JSON。
比如对话题做分类和深度标记。
这些工作不需要人一条条手动处理，但需要人来做最终判断。哪些内容适合产品，哪些话题太冒犯，哪些表达需要调整，仍然要由人把关。
所以更准确的分工是，人负责方向、取舍和质量判断，AI 负责批量整理和结构化加工。
这套方法很适合迁移到其他小产品里。
如果你做的是菜谱卡，可以让 AI 从视频或笔记里提取食材和步骤。
如果你做的是旅行卡，可以让 AI 把攻略整理成地点、预算、路线和注意事项。
如果你做的是学习卡，可以让 AI 把长文整理成知识点、问题和练习。
重点不是素材来自哪里，而是你能不能把非结构化内容变成数据库可以使用的数据。
06 整理图片素材
图片不是这篇文章的重点，但它会影响项目完成度。
Shake Drink Talk 里，每张调酒卡都需要一张配图。我把图片流程固定了下来：用豆包生成，用百度图片助手处理背景和水印，再上传到 Supabase Storage，数据库里保存对应的 image_url。
一开始我也尝试过 GPT Image 2 和 Midjourney，但多次尝试后发现，效果不够稳定，成本也不算低，后来才切到这套组合。
其中生图我也没有用到很复杂的提示词，直接找到商品图片和想要参考的风格，交给豆包，让其参考图 2 的风格去生成图 1，不要生成多余元素。
生成图片。
筛选可用结果。
处理背景和水印。
统一命名。
上传到 Storage。
把 URL 写回数据库。
页面通过 image_url 展示图片。
这样做的好处是，图片资产不会和代码强绑定。后面想替换某张图，只需要更新 Storage 和数据库里的 URL，不需要去组件里改路径。
对小产品来说，这些工程习惯不需要做得很重，但最好一开始就保持清晰。
07 先跑通 MVP
我这次最核心的执行原则，是先跑通最小闭环。
用户进入首页。
抽取一张调酒卡。
查看配方、步骤和图片。
点击进入聊天环节。
抽取一个话题。
完成一次完整体验。
只要这条链路能跑通，这个产品就已经具备了可以演示的基础。
后面的视觉优化、动效、更多卡片、更多话题、用户系统、分享功能，都可以在这个基础上继续增加。
这对 AI 辅助开发尤其重要。
如果一开始就让 AI 同时做页面、数据库、登录、分享、动画、部署，它很容易把任务做散。更好的方式是，把目标拆成一段一段可以验证的任务。
先让首页能显示卡片。
再让卡片从 Supabase 读取。
再让图片从 Storage 加载。
再让详情页根据卡片 ID 展示数据。
再让话题抽取流程跑通。
再考虑视觉和体验打磨。
每完成一步，都要实际运行和验证。
这也是我对 vibe coding 的理解。
它不是让 AI 一次性替你完成所有事情，而是让你用更快的速度完成一个个可验证的小步骤。你仍然需要判断方向、拆任务、看结果、提反馈，只是中间大量具体实现可以交给 AI 加速。
当核心流程跑通之后，下一步就是让它真正能被访问到。
我把它拆成了三块，域名、部署、关联。
第一块是域名。
我在腾讯云上买了域名。说实话，流程比我想象中简单，搜索想要的域名，选一个还能注册的，付款，实名认证，基本就搞定了。实名认证需要一点时间，不是即时生效的，所以最好提前一天处理。我的建议是，别在部署当天才买域名，否则很容易因为审核卡在那儿干等。
第二块是 Vercel 部署。
代码我先推到了 GitHub。Vercel 可以直接关联 GitHub 仓库，选择项目之后，它自动识别出是 Next.js，构建命令和输出目录都不用额外配置。
需要填的是环境变量，NEXT_PUBLIC_SUPABASE_URL、SUPABASE_ANON_KEY、SUPABASE_SERVICE_ROLE_KEY 这些，都要在 Vercel 的 Environment Variables 里配好。Supabase 的 key 在项目的 Settings - API 里能找到，注意 service role key 不要泄露到前端。
第三块是把域名关联到 Vercel。
在 Vercel 的项目设置里，有一个 Domains 选项，输入你买好的域名，它会告诉你需要配置哪些 DNS 记录。
然后回到腾讯云的 DNS 解析控制台，添加对应的记录，通常是 A 记录和 CNAME 记录。等 DNS 生效之后，Vercel 会自动申请 SSL 证书，大概几分钟到十几分钟，域名就能正常访问了。
这里有个小坑。
DNS 解析生效时间不是固定的，有时候几分钟，有时候几个小时。很多时候只是还没生效，不是配置错了。
另外，HTTPS 证书 Vercel 会自动处理，不需要自己去腾讯云买证书。这个对前端开发者来说非常友好，省去了很多麻烦。
跑通这一步之后，产品才算真正意义上的上线。
你打开一个网址，能看到页面，能抽调酒卡，能看调酒步骤，能抽话题。这一步的成就感，比单纯本地跑起来要强很多。
08 TRAE 是如何工作的
很多人第一次用 TRAE 或者类似的 AI 编程工具，会有一个误解。
以为 vibe coding 就是丢一句 prompt，然后 AI 一次性把所有东西生成出来。
其实完全不是。
真正的 vibe coding，更像是一个连续的循环。
你提出需求。
AI 生成一版。
你运行，看效果。
发现不对，给出反馈。
AI 再改。
你再看，再反馈。
循环往复，直到结果没问题。
你想想看，它不是一个线性的「输入 → 输出」过程，而是一个「输入 → 输出 → 验证 → 修正」的螺旋。这个模式跟 Agent 里的 ReAct 范式很像，行动、观察、思考、再行动，核心都是迭代。
我在做 Shake Drink Talk 的过程中，几乎每一步都是这样过来的。
首页第一版出来，我觉得卡片太大，阴影太脏，AI 调了三轮才到我能接受的状态。
电脑端和手机端布局完全乱套，手机端容易出现元素遮挡。
部署第一构建失败了两次，看日志、改配置、再试，最后才跑通。
每次都不是一次性做对。
但这恰恰是 vibe coding 的效率所在。你不用在脑子里把所有细节想完再动手，而是可以更快地把一个粗糙版本做出来，然后基于真实反馈继续推进。
当然，这个模式对使用者有一个要求。
你得知道自己要什么。
如果你只会说「再改改」「还是不好看」，AI 是很难给出好结果的。但如果你能说「这张卡片的圆角太大，改成 12px」「这个按钮和首页按钮高度不一致」「这个话题抽到过一次后不要再出现」，AI 就能非常高效地执行。
所以 vibe coding 不是让你放弃思考，而是把你的思考从「怎么写代码」转移到「我要什么」和「哪里不对」。
代码实现的部分，AI 帮你加速。
判断和反馈的部分，仍然在你手里。
09 哪些地方我没有让 AI 做
做到后面，我越来越清楚一件事。
AI 能做的事很多，但说实话，有些事不能交出去，这就跟 Agent 中需要有 Human in the Loop 是一个道理。
最终 UI 我选。
不是 AI 生成的每一版都不好，而是审美判断必须有人拍板。哪一版更接近我想要的产品气质，哪个颜色更适合情侣沟通的温和感，这些只能由人决定。AI 可以给十版方案，但最后一锤定音的，必须是我。
产品方向我定。
调酒是入口，沟通才是核心，这个判断是我做的。AI 不会知道我想解决的是一个「情侣之间不知道怎么认真聊天」的场景，它只能从我的输入里推断。方向错了，后面所有执行都会跟着错。
数据库结构我确认。
AI 可以帮我写 SQL，可以建议字段，但我得自己判断哪些字段是 MVP 必需的，哪些是后续扩展才需要。如果一开始就把表设计得太重，后面改起来很痛苦。
内容审核我筛。
AI 整理出来的聊天话题，有些太冒犯，有些太无聊，有些不适合情侣场景。这些需要人逐条判断。特别是涉及情感沟通的内容，稍有不慎就会让用户觉得尴尬或者不舒服。
图片我挑。
豆包能生成一百张图，但哪张有产品感，哪张氛围对，哪张和整体 UI 搭，还是得人来选。AI 负责批量生产，人负责挑出那几张能用的。
部署我验证。
域名有没有解析成功，SSL 证书有没有生效，构建日志有没有报错，这些最后都要自己点一遍、看一遍、确认一遍。AI 可以告诉你步骤，但线上环境有没有真的跑通，只有你自己能验证。
那 AI 做了什么？
它负责生成、整理、修改、加速。
它把我从大量重复劳动里解放出来，让我可以把精力放在那些真正需要人做决定的地方。
我觉得这才是比较真实的分工。
不是 AI 全包，也不是人全包，而是各自做擅长的事。
10 总结
说真的，真正值得学习的不是我的具体选题，而是这套路径。
如果你想复刻，不一定非要复刻 Shake Drink Talk。塔罗卡、菜谱卡、旅行灵感卡、健身动作卡、亲子聊天卡，底层结构都很像。一组卡片内容、一组详情数据、一组图片资产、一套抽取流程，再加上 Next.js + Supabase + Storage + API 封装，就是一个可以跑通的 MVP。
路径也很固定。
先把想法告诉 TRAE，让 Superpower 帮你整理成需求文档，确认 MVP 的最小链路。
根据页面流程设计数据表，用 Supabase 存结构化数据和图片，用 Next.js API 封装数据访问。
给 AI 明确的 UI 参考和反馈。
把非结构化素材交给 AI 整理成可导入数据。
先跑通核心流程，再逐步打磨。
这套流程对小白相对友好，因为它不要求你一开始就掌握所有技术细节。你只需要知道每一步要解决什么问题，然后借助 AI 把具体实现推进下去。
这次参加 TRAE AI 大赛，对我最大的帮助也在这里。
它给了我一个明确的外部场景，让我不只是停留在看教程、收藏案例、想做产品，而是真的把一个小想法推进到了上线状态。
如果你最近也有一个小产品想法，我挺建议借类似比赛去试一次。
TRAE 这次比赛还送一个月月卡，刚好适合拿来体验 vibe coding。不要一开始就追求一个完整商业产品，先做一个能打开、能交互、有数据、有图片、能部署的小应用，就已经足够有价值。
做完以后，你会对 AI 辅助开发有一个更具体的理解。
它不是替你思考产品，也不是自动生成结果。
它更像是把你和完整产品之间的距离缩短了一截。
人负责方向、判断、审美和取舍。
AI 负责拆解、生成、整理和加速。
当这两部分配合起来，一个原本只停留在脑子里的想法，就有机会变成一个真正能访问的小产品。
我这次就是从一句很粗糙的 prompt 开始的。
后来它真的上线了。
最后感谢各位大佬的阅读~