夜雨聆风果汁哥最近做了一个小产品：
个人开发者AI产品清单。
不管你有 AI 工具、小程序、副业项目，还是有技术、有想法、想找合作机会，都可以在上面上架展示。
大家可以互相对接资源，互相体验产品，互相反馈建议，也可以在群里抱团成长。
优质项目后面也会在果汁哥群内重点推荐。
直达链接：
https://tan-xin.com
如果你正在做 AI 产品、工具、网站、小程序、自动化项目，
或者只是刚有一个想法，也可以先放上来。
这件事本身，也是我最近用 AI 做项目时，一个很典型的 Vibe Coding 实战案例。
下面这篇文章，就从这个项目说起。
01 果汁哥自己踩了一遍坑，才发现 Vibe Coding 不是“喊 AI 写代码”
这段时间，果汁哥自己也在折腾一个小项目。
就是上面这个：
个人开发者AI产品清单。
一开始想法特别简单。
群里有很多朋友在做 AI 工具、小程序、副业产品，也有人会发自己的项目介绍。
但微信群有个问题：
信息流太快。
今天有人发了一个好工具，明天就被聊天记录冲没了。
有人想找合作，结果没人知道他会什么。
有人做了产品，想找用户体验，也不知道该怎么集中展示。
所以我就想，能不能做一个简单的产品库？
把群友做的项目集中展示出来。
每个人可以提交自己的产品。
别人可以浏览、搜索、查看详情。
优质项目还能在群里推荐。
听起来很简单，对吧？
我一开始也是这么想的。
然后我打开 AI 编程工具，直接来了句：
帮我做一个群友产品清单网站。
几分钟之后，页面确实出来了。
有首页，有产品卡片，有详情页，看起来还挺像那么回事。
我当时也有点上头。
继续说：
加个后台。
后台也出来了。
再说：
加个提交功能。
提交页面也出来了。
再说：
帮我部署一下。
部署方案也给了。
那一刻，真的有一种感觉：
完了，开发项目这么简单吗？
一个人、一张嘴、一个 AI，好像就能开干。
但很快问题就来了。
页面是有了，但产品提交之后到底存到哪里，不清楚。
后台是有了，但谁能进后台，权限没想明白。
产品状态是有了，但待审核、已通过、已驳回之间怎么流转，一开始没设计清楚。
前台展示是有了，但未审核的产品会不会被展示出来，也要重新确认。
搜索框是有了，但搜索的是产品名称，还是简介，还是标签，也没提前讲。
部署能跑，但环境变量、数据库迁移、启动命令，又是一堆坑。
最麻烦的是，AI 每次都说“已完成”。
但我自己一看，很多东西只是“看起来完成”。
这时候我才意识到：
Vibe Coding 最爽的地方，是 AI 写得快。Vibe Coding 最危险的地方，也是 AI 写得太快。
你没想明白，它已经写完了。
这事儿让我特别有感触。
一个项目做出来，从来不是只有写代码。
前面有需求，后面有验收，中间还有架构、方案、测试、部署、权限、数据、异常处理。
如果这些东西没想明白，AI 写得越快，项目可能乱得越快。
所以今天这篇文章，不讲玄学，也不讲概念。
就结合我自己做“果汁哥群友产品清单”这个小项目踩过的坑，聊聊普通人到底怎么做好 Vibe Coding。
02 很多项目不是死在代码上，是死在第一句话上
我现在复盘这个项目，发现第一个坑就出在第一句话。
我一开始说的是：
帮我做一个群友产品清单网站。
这句话听起来没问题。
但对 AI 来说，信息量太少了。
群友产品清单到底是什么？
是展示网站？
是类似 Product Hunt 的产品社区？
要不要用户登录？
要不要后台审核？
要不要产品详情页？
要不要分类？
要不要搜索？
……
你不说，AI 就会猜。
AI 一猜，项目就开始跑偏。
它可能给你做一个很炫的首页，但没有真正的提交审核流程。
也可能给你做一个复杂后台，但你第一版根本用不上。
它可能为了显得“完整”，顺手加一堆登录、积分、会员、排行榜、评论系统。
你看着很热闹，但真正要用的时候，全是坑。
所以我越来越觉得，AI 编程时代，普通人最应该学会的第一件事，不是写代码，而是把需求说清楚。
以前不会写代码，是门槛。
以后不会提需求，才是门槛。
03 好需求不是一句“我要什么”，而是把边界讲清楚
我见过很多人提需求，都是一句话：
我要一个后台。
我要一个首页。
我要一个搜索。
我要一个积分系统。
这些话不是不能说，但太粗了。
粗需求最大的问题，不是 AI 不会做，而是它会做过头。
比如你说：
加一个搜索功能。
AI 可能会想：
是不是要全文搜索？
是不是要搜索历史？
是不是要做排序权重？
但你其实只是想第一版能搜产品名称和标签。
这就麻烦了。
所以一个好需求，至少要说清楚六件事。
给谁用。
1.在什么场景用。
2.解决什么问题。
3.第一版做什么。
4.第一版不做什么。
5.做到什么程度算完成。
6.比如我这个群友产品清单，差的需求是：
做一个群友产品展示平台。
这句话太虚。
好一点的需求应该是：
这个平台面向果汁哥 AI 群群友。群友可以提交自己的 AI 产品，包括产品名称、简介、链接、截图、分类、标签和联系方式。管理员可以在后台审核产品，审核通过后展示到前台。普通用户可以浏览产品列表，按分类筛选，搜索产品并查看详情。第一版只做展示和审核，不做支付、不做评论、不做私信、不做复杂推荐。验收标准是：用户能提交产品，管理员能审核，审核通过的产品能在前台展示，未审核产品不能展示，搜索和分类可用，项目能部署上线。
你看，这样一写，AI 就能继续往下拆了。
它知道要几张页面。
知道要哪些数据表。
知道要哪些字段。
知道前台展示什么。
知道后台审核什么。
知道什么东西现在不能做。
也知道做成什么样算完成。
这才是 AI 能执行的需求。
04 第一版千万别贪，先把一个闭环跑通
做项目最怕什么？
不是怕功能少。
是怕一开始就大而全。
尤其现在有 AI 之后，人很容易膨胀。
以前你想加功能，还得考虑程序员有没有时间。
现在你想加功能，AI 好像随时都能写。
于是你本来只是想做一个群友产品清单。
写着写着，突然想加积分。
又想加会员。
又想加排行榜。
又想加评论。
又想加付费广告。
又想加企业认证。
又想加 AI 自动生成产品介绍。
最后搞成一个四不像。
第一版真正重要的，不是看起来多完整，而是能不能跑通一个最小闭环。
还是这个群友产品清单。
第一版其实只需要做几件事：
用户能提交产品。
管理员能审核产品。
审核通过的产品能展示。
用户能搜索和查看详情。
项目能部署上线。
这就够了。
只要这个闭环跑通，项目就活了。
至于支付、评论、排行榜、积分、会员、广告位，这些都可以后面再说。
第一版做得太重，后面反而不好改。
我经常跟朋友说：
AI 负责生成，人负责克制。
AI 太勤快了。
你说什么它都想做。
05 不要直接让 AI 写代码，先让它画蓝图
很多人一上来就让 AI 写代码。
这就像你盖房子，还没画图纸，就让施工队进场。
当然会乱。
正确做法是，先让 AI 出蓝图。
你可以这样说：
先不要写代码。请基于我的项目目标，输出 MVP 方案，包括项目定位、目标用户、核心场景、第一版功能清单、第一版明确不做的功能、页面结构、数据模型、接口设计、权限规则、开发步骤、风险点和验收标准。要求控制复杂度，优先保证一周内可上线、可演示、可迭代。
这一步非常重要。
因为你可以在方案阶段就发现问题。
比如 AI 把你的产品库理解成了电商平台，你马上能纠正。
比如它一上来设计支付系统，你马上能砍掉。
比如它漏掉了审核后台，你马上能补上。
方案阶段纠偏，成本最低。
代码阶段纠偏，成本最高。
很多项目为什么越改越乱？
就是因为一开始没蓝图。
AI 先写了一堆代码，后面你发现方向不对，再让它改。
它越改越绕。
你越看越晕。
最后你只能说：算了，重来。
所以，Vibe Coding 不是一上来就 vibe。
先别上头。
先让 AI 把图纸画出来。
图纸没问题，再施工。
06 聊天记录不是项目文档，项目一定要沉淀下来
还有一个坑，很多人都会踩。
他们和 AI 聊了几十轮，项目好像一点点做起来了。
但所有东西都在聊天记录里。
产品定位在聊天记录里。
架构规则在聊天记录里。
开发计划在聊天记录里。
注意事项也在聊天记录里。
结果聊着聊着，AI 忘了。
换个新会话，AI 更不知道了。
你再解释一遍，口径又变了。
这就是为什么项目不能只靠聊天。
你要把关键东西沉淀成文档。
至少要有五个文件：
1.README.md，写项目是什么，怎么启动，怎么部署。
2.PRODUCT.md，写产品定位、用户角色、核心场景、版本规划。
3.ARCHITECTURE.md，写技术栈、目录结构、数据流、架构分层。
4.ROADMAP.md，写这一版做什么，下一版做什么，哪些以后再做。
5.CLAUDE.md，写给 AI 的项目规则。
这里面最关键的是 CLAUDE.md。
它就像给 AI 的项目家规。
你可以写：
当前只做 MVP，不做支付、不做评论、不做复杂推荐、不做多租户。每次只完成一个小任务。修改前必须先阅读 README、ARCHITECTURE 和数据库 schema。不允许随意更换技术栈。不允许大规模重构已有代码。不允许顺手开发本轮任务之外的功能。涉及数据库变更时，必须说明字段含义和迁移方式。管理员功能必须有权限校验。前台只展示审核通过的数据。每次完成后必须输出修改文件、验证方式、影响范围和下一步建议。
有了这些规则，AI 就不再像一个临时工。
它更像一个知道项目背景的开发成员。
这就是上下文工程。
说白了，就是别每次都让 AI 从零理解你。
你要把项目的“常识”写下来。
07 大任务要拆小，一次只让 AI 做一件事
AI 做小任务很强。
AI 做大任务容易乱。
这句话很重要。
你不要一口气说：
帮我把产品提交、后台审核、前台展示、搜索、详情页、部署都做了。
这不是效率高。
这是给项目埋雷。
你应该拆开。
第一轮，只设计数据模型。
第二轮，只做产品提交页面。
第三轮，只做提交接口。
第四轮，只做后台审核列表。
第五轮，只做审核通过和驳回。
第六轮，只做前台产品列表。
第七轮，只做产品详情页。
第八轮，只做搜索和分类。
第九轮，只做部署检查。
每一轮只做一件事。
比如你可以这样说：
本轮只做产品提交功能，不做后台审核，不做前台展示，不做搜索。请先说明涉及哪些文件、数据结构、接口变化和验收标准，确认后再修改代码。
很多人用 AI 做项目，越做越乱，根本原因就是任务太大。
一个大任务里包含十几个小任务，AI 写着写着就顾此失彼。
08 每次动代码前，先让 AI 说计划
我现在用 AI 改项目，有一个习惯：
不让它直接动手。
先让它说计划。
比如：
写代码前，请先输出你对本次需求的理解、预计修改哪些文件、是否涉及数据库变更、是否涉及接口变更、是否影响已有功能、实现步骤、风险点和验收方式。先不要修改代码，等我确认。
这一步很有用。
你不懂代码也没关系。
你至少能看出它是不是离谱。
很多时候，AI 的问题不是不会干，而是太能干。
你给它一点空间，它能发挥出一大片。
所以每次动代码前，先让它说计划。
你先看计划。
计划对，再让它写。
计划不对，马上纠正。
这就是小白控制项目最实用的方法。
你不需要懂每一行代码。
但你要懂这个项目该往哪走，不该往哪走。
9 身边最常见的几个提法，建议直接改掉
我把几个高频场景放在这里，大家可以直接拿去用。
你不要说：
帮我做一个社群系统。
你要说：
我要做一个社群系统 MVP。第一版只实现用户登录、内容发布、内容列表、详情页和后台审核。不要做积分、会员、支付、私信和复杂推荐。请先输出产品方案、数据模型、页面结构、接口清单、开发步骤和验收标准，不要直接写代码。
你不要说：
页面太丑了，帮我高级一点。
你要说：
请只优化首页视觉，不改变业务逻辑、接口和数据库。风格参考 Linear / Vercel，要求简洁、现代、卡片式布局、层级清晰。只允许调整布局、间距、字体、卡片、按钮和响应式样式，不新增复杂动画，不重构无关代码。
你不要说：
加一个搜索功能。
你要说：
请增加产品搜索功能，搜索范围包括产品名称、简介和标签。搜索框放在产品列表上方。输入关键词后展示匹配结果，无结果时显示“暂无匹配产品”。第一版不要接入第三方搜索服务，使用现有数据库查询或前端过滤即可。完成后提供验收步骤。
你不要说：
做一个后台管理。
你要说：
请增加管理员后台 MVP，用于审核用户提交的产品。后台包含产品列表、产品详情、审核通过、驳回功能。产品默认状态为 pending，审核通过后为 approved，驳回后为 rejected。前台只展示 approved 产品。普通用户不能访问后台页面和后台接口。
你不要说：
这个页面报错了，帮我修一下。
你要说：
当前问题是访问 /admin/products 页面时报错。请先分析可能原因，不要直接大规模修改代码。优先检查路由、权限校验、数据库字段、API 返回结构和前端调用字段是否一致。修复时采用最小改动，并说明根因、修改文件和验证方式。
10 普通人可以直接保存的三段提示词
第一段，项目启动时用：
我想开发一个新项目，请你先不要写代码。项目想法是：【这里写项目想法】。请你先作为产品经理、架构师和技术负责人，输出项目启动方案，包括项目一句话定位、目标用户、核心场景、MVP 第一版功能、第一版明确不做的功能、页面结构、数据模型、接口设计、权限设计、技术栈建议、目录结构建议、开发任务拆解、每个任务的验收标准、主要风险点和一周内上线路径。要求控制复杂度，不要过度设计，优先保证第一版可上线、可演示、可迭代。不要直接写代码，先输出方案，等我确认后再开发。
第二段，单任务开发时用：
本轮只完成一个任务：【具体任务】。请先不要修改代码。请先输出你对本次任务的理解、需要阅读哪些文件、预计修改哪些文件、是否涉及数据库变更、是否涉及接口变更、是否影响已有功能、实现步骤、验收标准和风险点。要求只做本轮任务，不做其他功能，尽量最小改动，不重构无关代码，不改变既有技术栈，输出方案后等待确认。
第三段，验收时用：
请对本次修改进行验收总结：本次完成了什么，修改了哪些文件，新增或变更了哪些数据结构，新增或变更了哪些接口，如何本地启动并验证，需要我手动检查哪些页面，是否影响已有功能，已知风险或未完成事项，下一步建议。如果有 lint、typecheck、build 或测试命令，请运行并说明结果。如果无法运行，请说明原因。
这三段话，基本可以覆盖一个小项目的启动、开发和验收。
别小看这些提示词。
它们的作用不是让 AI 显得更听话。
它们是把项目从“聊天模式”拉回“交付模式”。