Vibe Coding 最近被讨论得很多。

有人把它理解成“用自然语言写代码”，也有人认为它只是 AI 辅助编程的另一种说法。实际使用下来，Vibe Coding 更像是一种新的产品开发方式：

开发者不再从空白文件开始逐行实现，而是先描述目标、约束和预期结果，再通过多轮对话，让模型参与需求拆解、技术选型、代码生成、测试和修改。

通义千问、通义灵码等工具，已经可以覆盖其中不少环节。

但真正做过完整产品后会发现，代码生成只是整个流程的一部分。

一个产品从想法变成有人使用的工具，至少还要经历需求判断、技术验证、体验设计、部署维护、内容表达和用户反馈等多个阶段。

本文不讨论“AI 会不会替代程序员”，而是尝试整理一套更实用的 Vibe Coding 开发框架：哪些工作适合交给大模型，哪些问题仍然需要开发者自己判断，以及产品上线后最容易遗漏什么。

一、Vibe Coding 最适合解决什么问题？

并不是所有项目都适合一开始就用 Vibe Coding 推进。

它更适合以下几类任务：

判断一个想法是否适合 Vibe Coding，可以先问三个问题：

1. 核心功能能否用一句话说明？
2. 用户能否在几分钟内完成一次完整体验？
3. 第一版失败以后，修改成本是否可控？

如果三个答案基本都是“可以”，通常就适合先做一个最小可用版本。

二、不要先让模型写代码，先把问题定义清楚

很多 Vibe Coding 项目失败，并不是模型代码能力不足，而是需求从一开始就没有定义清楚。

例如下面这句话：

帮我做一个 AI 写作工具。

从开发角度看，这几乎不构成可执行需求。

AI 写作可能包括公众号文章、短视频脚本、产品文案、论文润色、邮件回复和社交媒体内容，每一种场景的输入、输出和评价标准都不同。

更有效的描述方式是：

为跨境电商运营人员开发一个商品标题优化工具。用户输入原始标题、商品类别和目标市场，系统输出 5 个英文标题，并提示每个标题的长度、关键词和可能存在的表达问题。

两者的区别不只是描述长度，而是第二种写法已经包含了：

• 目标用户；
• 输入内容；
• 核心任务；
• 输出结构；
• 基础判断标准。

可以把下面这份模板直接交给通义千问，用于整理早期需求。

需求拆解模板

我准备开发一个产品，请不要立即写代码。

产品的初步想法是：
【填写一句话想法】

请先帮我完成以下分析：

1. 这个产品主要解决什么具体问题？
2. 最适合的目标用户是谁？
3. 用户目前通常如何解决这个问题？
4. 第一版只保留哪些核心功能？
5. 哪些功能暂时不应该加入？
6. 用户从进入产品到获得结果的完整流程是什么？
7. 第一版是否适合个人开发者在较短时间内完成？
8. 可能存在的技术、成本和合规风险是什么？

最后请输出：
- 一句话产品定义
- 核心用户
- MVP功能列表
- 暂缓功能列表
- 用户流程
- 风险清单

这一步的价值，往往比直接生成几百行代码更大。

三、把开发任务拆成模型能够验证的小步骤

大模型一次生成完整项目，看起来效率很高，但后续通常会遇到两个问题：

一是开发者难以判断每一部分为什么这样实现；
二是出现问题后，不容易定位错误究竟来自哪里。

更稳妥的方式，是把项目拆成几个可以独立验证的模块。

例如，一个文件格式转换工具可以拆成：

每完成一个模块，就运行一次、检查一次，再进入下一步。

这种方式看起来没有“一句话生成整个应用”那么有冲击力，但更接近真实开发。

一个更稳定的代码生成指令结构

你是一名有生产环境经验的全栈开发者。

当前只实现以下模块：
【填写模块名称】

项目现状：
【描述已有代码和技术栈】

本模块需要完成：
1.
2.
3.

约束条件：
- 不修改无关文件
- 不引入不必要的依赖
- 必须处理异常情况
- 对关键代码增加注释
- 输出修改文件列表
- 提供本地验证步骤

请先说明实现方案，等待确认后再生成代码。

这里最重要的一句话是：

请先说明实现方案，等待确认后再生成代码。

它可以避免模型在错误方向上一次性修改太多内容。

四、AI 生成的代码，至少要经过四类检查

“代码能运行”并不等于“代码可以上线”。

对于通过通义千问、通义灵码或其他 AI Coding 工具生成的项目，至少应当完成以下检查。

1. 功能检查

验证正常流程能否完成，也要主动测试异常情况。

例如：

• 用户没有填写必填项；
• 文件格式不支持；
• 请求超时；
• 模型接口返回空内容；
• 数据库连接失败；
• 用户重复点击提交按钮。

AI 生成代码通常更容易覆盖理想流程，而忽略异常流程。

2. 安全检查

尤其需要关注：

• API Key 是否写入前端代码；
• 是否直接信任用户输入；
• 上传文件是否限制类型和大小；
• 数据库查询是否存在注入风险；
• 用户是否可以访问他人的数据；
• 日志中是否记录敏感信息；
• 管理接口是否缺少权限校验。

对于面向公众开放的产品，这部分不能只依赖模型自检。

3. 成本检查

很多大模型应用在测试阶段成本不明显，上线后才发现每一次调用都可能产生费用。

需要提前明确：

一个简单方法，是在上线前估算：

100 个用户每天各使用 5 次，运行 30 天，大致会产生多少模型、存储和服务器费用？

如果这个问题没有答案，产品还不适合正式推广。

4. 可维护性检查

Vibe Coding 很容易形成一种情况：

功能确实做出来了，但只有模型知道代码是怎么组织的。

上线前至少需要确认：

• 文件结构是否清楚；
• 配置项是否集中管理；
• 核心功能是否有说明；
• 是否可以在另一台电脑重新部署；
• 数据库结构是否有记录；
• 出现故障时，能否快速定位日志；
• 不依赖原始对话，也能继续维护项目。

开发者最终需要拥有代码，而不是只拥有一段与模型的聊天记录。

五、大模型不仅可以写代码，也适合做测试和审查

在开发流程中，大模型还有一个容易被忽略的用途：扮演不同角色进行检查。

同一段需求，可以让通义千问分别从以下视角提出问题：

• 普通用户；
• 产品经理；
• 前端工程师；
• 后端工程师；
• 测试工程师；
• 安全审查人员；
• 运营人员。

例如可以使用下面的提示词：

请扮演一名软件测试工程师。

以下是产品功能说明：
【填写功能说明】

请输出：
1. 正常流程测试用例
2. 异常流程测试用例
3. 边界条件测试用例
4. 容易被忽视的用户操作
5. 可能造成数据错误的情况
6. 上线前必须完成的检查项

请使用表格输出，并标注优先级。

这种方式不能代替专业测试，但能够明显降低遗漏基础问题的概率。

六、产品上线后，真正困难的往往不是部署

借助云服务，部署一个网页应用已经比过去方便很多。

但上线并不等于完成。

很多独立开发项目会停在这里：

• 产品已经可以访问；
• 开发者在社区发布了一篇文章；
• 获得了一些浏览和评论；
• 几天后热度下降；
• 后续继续更新，但很少再有新用户发现。

这背后其实涉及一个产品分发问题。

开发者社区、代码托管平台、独立官网和导航平台，承担的任务并不一样。

很多开发者会认真准备开发文章，却没有为产品准备一个长期可检索的介绍页面。

当社区文章逐渐下沉以后，用户很难快速了解：

• 产品现在是否还在维护；
• 最新版本增加了什么；
• 是否已经更换访问地址；
• 当前是否免费；
• 适合哪些使用场景；
• 有没有类似产品可以比较。

从这个角度看，产品上线后的信息维护，也是开发工作的一部分。

七、一个产品页面至少应该提供哪些信息？

无论产品最终提交到导航站，还是放在自己的官网，建议至少提供以下内容。

基础信息

• 产品名称；
• 一句话介绍；
• 目标用户；
• 主要功能；
• 访问或下载方式；
• 当前版本状态；
• 是否需要注册；
• 是否提供免费体验。

使用信息

• 用户需要输入什么；
• 产品会输出什么；
• 完成一次操作需要多久；
• 是否支持中文；
• 是否需要安装；
• 数据是否会上传到服务器。

开发信息

• 是否为开源项目；
• 使用了哪些主要技术；
• 是否接入大模型；
• 是否仍在持续维护；
• 问题反馈入口在哪里。

对于早期产品来说，把这些问题说清楚，通常比写“颠覆行业”“重新定义效率”更容易获得用户信任。

八、我们为什么在 MarkAll 中增加开发者产品收录？

下面这一部分需要先说明立场：MarkAll 是我们自己参与开发的平台。

在整理 AI 工具和效率产品的过程中，我们发现，很多个人开发项目并不是没有价值，而是缺少持续被发现的入口。

一篇开发文章可能很完整，但文章的核心通常是技术过程；代码仓库适合开发者阅读，但普通用户未必能够快速理解；独立官网能够承接使用，却不一定有自然流量。

因此，MarkAll 尝试做的是比较基础的一件事：

把已经可以体验的产品，按照功能和使用场景重新整理，让用户在真正出现需求时能够找到，并保存到自己的个人工具库中。

目前主要关注的产品包括：

• AI 应用；
• 开发者工具；
• 网页工具；
• 浏览器插件；
• 开源项目；
• 内容与设计工具；
• 自动化工具；
• 垂直行业应用；
• 已具备主要功能的 MVP。

它不要求产品必须使用某一种模型开发，也不以公司规模、融资情况或用户数量作为基础判断标准。

对于使用通义千问、通义灵码或其他 AI Coding 工具完成的项目，更值得说明的不是“这个产品由 AI 开发”，而是：

• AI 具体参与了哪些环节；
• 哪些问题仍然由开发者解决；
• 产品是否真实可用；
• 是否保持维护；
• 对用户而言解决了什么问题。

目前 MarkAll 的基础浏览、收藏和产品提交处于免费开放状态，页面暂时也没有设置广告位。

这里不承诺提交产品后一定获得流量。平台能够做的，是提供一个结构化的产品页面、分类入口和用户收藏场景，让产品在首次发布之后，仍然有机会被重新发现。

九、适合开发者参考的一套发布流程

一个相对完整的 Vibe Coding 产品发布流程，可以分成以下几步。

第一步：在开发者社区分享过程

文章重点不必放在宣传产品，而是分享：

• 为什么选择这个问题；
• 如何用通义千问梳理需求；
• 通义灵码在编码中承担了哪些工作；
• 哪些代码需要人工修改；
• 开发过程中遇到哪些问题；
• 如何进行测试和成本控制；
• 产品从想法到上线用了多久。

第二步：准备清晰的产品页面

让第一次访问的用户能够在较短时间内理解：

• 产品解决什么问题；
• 是否适合自己；
• 如何开始使用；
• 当前处于什么阶段。

第三步：选择长期展示入口

可以将项目提交到工具导航、产品社区或收藏平台，避免产品完全依赖单篇文章获取访问。

第四步：持续记录更新

每次增加重要功能时，建议同步更新：

• 产品介绍；
• 使用截图；
• 功能列表；
• 价格或免费额度；
• 访问入口；
• 已知限制。

第五步：收集真实反馈

早期最有价值的问题不是“你觉得产品怎么样”，而是：

• 你原本想用它完成什么任务？
• 第一次使用时在哪一步停下？
• 哪个功能最难理解？
• 你最后是否完成了任务？
• 你通常还会使用什么替代方案？

这类问题更容易产生可以用于产品迭代的信息。

十、Vibe Coding 的核心不是“少写代码”

Vibe Coding 的价值，并不只是让开发者少敲一些代码。

它更重要的意义，是降低验证想法的成本。

过去，一个不确定是否成立的需求，可能要花费数周才能做出原型。现在，通过大模型辅助，开发者可以更快获得一个可操作的版本，然后交给真实用户验证。

但开发速度越快，越需要保持克制。

模型可以帮助生成方案，却不能替代需求判断；
模型可以帮助完成代码，却不能承担上线责任；
模型可以帮助整理反馈，却不能决定产品方向；
工具可以降低开发门槛，却不会自动带来用户。

真正有价值的 Vibe Coding 项目，通常不是功能最多的项目，而是能够把一个明确问题解决完整的项目。

从这个角度看，一套更健康的流程应该是：

先定义问题，再生成代码；先完成验证，再增加功能；先让少量用户真正用起来，再考虑扩大传播。

至于产品最终能否被长期使用，除了开发质量，也取决于它能不能在用户需要的时候，被重新找到。

FAQ

1. Vibe Coding 是否适合完全不会编程的人？

适合做原型和简单工具，但仍然需要理解基本的开发概念。

至少需要知道前端、后端、数据库、接口、部署和权限分别解决什么问题。否则在出现报错、安全或数据问题时，很难判断模型给出的方案是否可靠。

2. 使用通义千问可以直接生成完整产品吗？

可以帮助生成大量代码和方案，但不建议一次完成整个项目。

更稳妥的方式是先拆解需求，再按模块开发，每完成一个部分就进行验证。

3. AI 生成代码是否可以直接上线？

不建议。

上线前至少需要完成异常流程、安全、成本和可维护性检查。涉及用户数据、支付、权限和关键业务时，应进行更严格的人工审查。

4. 什么样的项目适合先做 MVP？

目标用户明确、使用流程较短、核心功能单一，并且能够低成本修改的项目，更适合先做 MVP。

5. 产品一定需要独立官网吗？

不一定。

开源项目可以使用代码仓库和文档页面，浏览器插件可以使用应用商店页面。但无论使用什么入口，都应该让用户快速理解产品用途和体验方式。

6. 如何判断一个产品是否值得继续开发？

可以重点观察：

• 用户是否能完成核心任务；
• 是否有人重复使用；
• 用户是否主动收藏或推荐；
• 用户反馈是否集中在同一类需求；
• 用户是否愿意提供更具体的使用场景。

访问量本身并不能完整反映产品价值。

7. MarkAll 接受什么类型的产品？

目前主要包括 AI 应用、网页工具、开发者工具、浏览器插件、开源项目、效率工具和垂直行业应用。

产品需要具备可以访问、下载或者部署的版本。

8. 提交 MarkAll 是否收费？

目前基础提交和普通收录免费开放。

平台可能会对提交内容进行基础检查和编辑，但不会承诺收录后一定获得流量或用户。

9. 产品必须使用通义千问或通义灵码开发吗？

不需要。

开发工具不是产品收录的判断条件。相比使用了什么工具，更重要的是产品是否真实可用、功能描述是否准确，以及是否仍在维护。

10. 在开发者社区发布文章时，怎样降低营销感？

建议把篇幅重点放在：

• 需求判断；
• 技术实现；
• 开发过程；
• 失败和修改；
• 成本与限制；
• 可复用的方法。