用 Agent Vibe Coding靠谱吗？7天制作2个网站，Flowith、Manus的实践、踩坑与思考

原创 BayJ 2025-06-17 21:31 广东

本文是此次AI协同实验的复盘，分享我对当前Agent Coding工具能力边界、Agent交互、协作模式变化的新思考。如果你对Vibe Coding 或是Flowith、Manus这样的Agent产品感兴趣，那这篇文章值得一看。

5月底临时需要在团队内做一场设计师 x AI Coding的主题分享，因时间紧急（完全利用工作外时间），我决定放弃传统PPT的形式，从零开始利用AI工具链构建分享网站。

本文是这次AI协同实验的复盘，同时分享我对当前Agent Coding工具能力边界、Agent交互、协作模式变化的新思考。

本文飞书链接：https://jvnkot1yjhx.feishu.cn/wiki/UsoKw1Hu3i4CKKk3kEDcl1penZd?fromScene=spaceOverview

主力工具：V0（制作分享网站）、Flowith Neo（制作AI Coding知识库）、Manus（前期惊艳，最终任务执行失败）、Gemini（内容策划）。

先来看看最终成果：

设计师 x AI Coding的主题分享网站：https://kzmkbx8qajeeywvv0thi.lite.vusercontent.net/

面向设计师的AI Coding知识库：https://flo.host/mJIyFLi/

一.Agent 实践复盘7天，2个网站，1场AI协同实验这次实验我主要使用了大热的Flowith Neo和Manus这两个通用Agent，感受到了Agent对Coding效率的极度提升，让我有更多时间聚焦内容本身，而非局限于分享形式（例如过去的PPT美化）上。不过在Agent对垂直领域优化做的还不够成熟的情况下，过程中也走了些弯路。

先说说Agent的特点Agent接入了LLM、生图、生视频等大模型，能理解复杂、长期目标，并且能自主规划、调用多种工具来达成目标的，很适合这种极短时间内需要交付的非精确任务。

对比我在上个项目中使用的Cursor 这样的IDE产品，Agent给我带来最大的便捷是可以自动完成数据存储、网站部署上线等一系列事情，网站内容本身成为创作核心，人类参与制作、执行的时间大幅降低。

在我的整体使用过程中，当下的通用Agent更适合0-1阶段。1-100的阶段还需垂直Coding工具接管。和垂直Coding工具对比，Agent的优劣势会更加具体：

网站Coding全过程Agent的 “惊艳开局”与“脆弱的1-N”这里我就要展开讲讲我和Agent的协同过程了，好方便大家理解前面的结论是怎么得来的。

我将同一段Prompt输入给了Flowith、Manus，并通过输入简单的设计要求、参考图、参考网址等方式简单调教了几版风格：

起初我对Manus生成的效果（左上图1）非常满意，它在理解图片、链接参考上的功能支持比Flowith更佳，生成的网页设计风格、动效都高Flowith一筹。在"0到1"阶段，Agent快速将模糊想法具象化的能力已经让我非常惊讶了。

然而，就当我试图从1开始进行深度迭代时，Manus 的脆弱性便开始暴露。

对边界失败场景应对不足：

在我尝试持续修改时，Manus很快提示上下文达到上限。并反复弹出付费页面，显示会员拥有更高上下文长度，

然而即便在我付费20多刀后，限制依然存在。这种在关键付费节点上的履约失败，让我对其可靠性彻底失去信任。

核心交付物质量不足。

抱着“不能白付费”的心态，我尝试让Manus导出源码，结果交付的代码缺失了一半的样式。

至于缺失的代码，我确实没有打字重新描述的动力。对于设计师来说，使用详细Prompt定义设计内容还不如自己设计来的快，通过文字详细定义设计规范总有些不太对，这违背了设计师视觉感受优先而非文字优先的直觉。

我敢打赌90%的设计师都不愿写这样的Prompt

垂类 Coding 工具来救火就在我以为AI协同实验即将失败时，我将Manus产出的残缺代码和需求交给了垂类 Coding 工具V0。结果让我非常惊喜：V0不仅迅速复刻并补全了所有样式和动画，还提供了结构清晰、可供二次开发的完整代码。

相比Manus的不确定性，V0给我的“安全感”非常强：它在垂类产品中审美在线、版本可随时回溯、网站无需部署可直接预览，项目支持无限修改。 终于...我的分享材料有着落了。

知识库生成，Agent的舒适区区别于分享网站的坎坷经历，【AI Coding知识库】的制作相对顺利。这次，我使用Flowith完成任务，并找到了当下Agent的真正优势所在：处理以复杂内容调研和逻辑为核心，而非以视觉调优、持续迭代的任务。

访问地址 (PC 体验更佳)：https://flo.host/mJIyFLi/

展示了从初版到终版的演进，略去部分对话调整

Flowith的核心优势体现在：

强大的信息整合能力：

得益于Flowith Neo无限制的长文本分析整合，出色地完成“调研-总结报告-报告转化为结构化网页”的任务，完整度远超预期。（单这一点，垂类Coding工具是做不了的

较高的

指令

遵循度：

在后续持续要求内容和结构调整时，能准确执行指令，体验流畅。

较高的执行效率与性价比：

对于复杂的信息处理任务，运行速度快，积分消耗相对合理。

但它同样暴露了Agent在“迭代”上的核心短板：

具体表现为：Flowith会过早判定任务完成而终止对话；同时它无法提供源代码。这两个限制，导致我无法对生成的初版网页进行持续的精细化修改。

以V0为代表的垂类工具，允许用户直接对代码进行编辑，并支持下载代码进入Cursor等专业环境再次编辑，能够满足AI代理快速完成0到1，人来高效掌控1到N的开放体验。

而以Flowith和Manus为代表的Agent，目前则更像一个“封闭系统”，虽然“0到1”可能更自动化，但其后续迭代的“天花板”却很低。这正是当前我对Agent模式最不满意的地方。

小结：Agent Coding 的正确打开方式综合我构建两个网站的经验，当前Agent Coding的核心价值在于极速完成从0到1的构建，尤其适合以下两类场景：

MVP

与概念验证：

Agent能将一个模糊的产品或设计构想实现，缩短到几小时甚至几十分钟内，变成一个功能可用、可交互的MVP。这极大地降低了创新和试错的成本。过去需要一个团队数周才能完成的工作，现在由一人一AI即可实现。

内容驱动型网站的生成。

对于知识库、Landing Page、活动页这类

以信息展示为核心、结构相对标准化

的网站，使用Agent可以发挥极大价值。创作者可以跳过调研、资料整理、信息设计阶段，

直接完成了初步想法 - 拿到结果的快速跨越。

当然，由于通用Agent对垂直领域的打磨不足，以及‘持续编辑能力’这个核心症结尚未解决，它在以下场景中表现得力不从心：

需要精细化视觉调优的生产项目。

正如我的经历，试图用文字指令去对齐高度定制化的视觉细节，效率低下且违背设计师直觉。在这方面，V0这类垂类工具优势明显。

需要长期迭代和维护的核心产品。

Agent“一次性交付”和“封闭生态”（如无法提供源码）的特性，使其几乎无法被纳入需要多人协作、持续更新的严肃项目工作流中。

对稳定性和可靠性要求极高的任务。

Manus的履约失败就是一个警钟，现阶段我们还无法将一个有明确deadline的关键任务，毫无保留地完全托付给Agent。

二.重新思考Agent Coding还有哪些改进空间？开始思考之前，我尝试思考了两个问题：

从现有用户体验角度出发，当下AI Coding有哪些痛点是值得被改善的？

相比V0、Lovable、Bolt等垂直Coding工具直接竞争，Agent Coding工具如何才能发挥更大优势？

如设计领域的Agent Lovart，我想未来可能会出现Coding领域的Agent产品来解决通用Agent当下无暇顾及的问题。基于这个假设我想到了几点迭代方向：

注入设计品味，弥补创造力短板在前面的实践中，我们能感受到不同产品间存在明显的‘审美差异’。例如，V0、Manus支持人为输入参考图、参考网站，甚至默认输出的效果都还不错；而Flowith如果不经过的Prompt调教，其产出物更像是“功能实现”，而非“设计作品”。

Flowith最初输出的网页效果

大模型本身并不会设计，它本质上是在模仿其训练语料中的代码与视觉风格。 它的“品味”，源自Github海量的开源项目和网络上无数的网页示例。

除了等待大模型自身的进化，Coding工具也可以主动为AI注入审美：

通过系统级提示进行预期管理：

Agent可以通过系统级的指令约束大模型生成，通过预设AI的角色和行为约束输出物下限。

通过绑定组件库进行审美兜底

：如V0集成了Tailwind CSS 和 Shadcn UI ，AI的任务不是自由地创造一个按钮，而是被强制要求去调用一个本身就设计得很好的按钮组件。这等于借助一套成熟的设计系统来兜底，巧妙地避免了模型自由发挥导致的审美崩坏。

通过“多模态理解”实现精准还原

符合用户直觉的体验是：用户上传一张喜欢的网站截图、链接、Figma设计稿 - Agent 分析其其设计语言（色彩、字体、布局、圆角等） - 自动生成结构化的设计参数（Design Tokens） - 调用模型去精准还原或模仿其风格。这种方式能将用户从繁琐的文字描述中解放出来，让AI真正成为视觉意图的延伸。