之前阅读了很多企业和个人 Vibe Coding 经验分享，也利用先进代码工具构建过一些小工具，但一直在思考：如何通过 Vibe Coding 从 0 开始构建一个完整的云原生应用。看的多说的多，不如自己动手来的快。假期期间，利用 Qoder 加一周左右的空余时间，构建并上线了一个智能股票分析系统：https://alpha.raydbg.icu/ Alpha Swarm 功能可能并不是很强，但是 UI 很酷，体验丝滑

并不是那么顺利

最开始设计和构建这个应用的时候，脑子里会闪过很多想法，站在用户的视角列出了一系列的功能需求，同时在架构选择上也会有不少的技术倾向。编码工具是确定的，Vibe 的编码策略还在摸索。最后看到，从一个想法开始，到原型验证，再到一个完整产品，这个项目至少从头开始了 5 次。。。 Versions 为什么要一次一次的重头再来？因为实在不想继续在屎山上雕花，及时止损。这时候会发现，Talk is NOT cheap, take my money, Qoder。 Charge 这里有几次失败经验值得记录：

  1. 从 PoC 开始拓展，当时我还在设计 Multi Agent 的流程编排，希望通过结合 AgentScope 验证业务逻辑可行性。通过 qodercli 快速完成原型构建，一切都在短平快中进行。当 agent 逻辑验证好了，我想要拓展成一个 web 应用的时候，发现前后端的解耦和API的维护是个极其尴尬的问题：PoC 阶段生成的脚本把一切都耦合到一起了，一种典型的面向过程的线下逻辑。因此再让 Qoder 去拓展成要一个 web 应用时，始终达不到预期，比如前端交互逻辑和后端状态的匹配，实在是有点看不下去。

  2. 从 0 开始，完整的描述了我想要什么，需要什么功能，前端选什么，后端选什么。Qoder 开始一通干活。但是出来的东西和预期的差距依然巨大。我认为需要重点打磨的，他做的稀稀拉拉，我认为无关紧要的，他做的认认真真。几个来回的交互之后，差距在功能模块的独立性和拓展性上越来越偏，实在难以维护，我觉得还是抓紧止损。

  3. 痛定思痛，我天真的认为一定是我描述的不够细，来上高大上的 Spec Coding 和 TDD（Test-Driven Development）。确实很强，根据 Spec Kit 完整地、仔细的完成 constitution/specify/plan/tasks/implement 的几个动作，不得不说，这段时间真的是 Token 消耗的飞快。这里有个两个好处：

    • plan 阶段，AI 做的技术架构调研比我自己设计的更完整，比如对于”如何实时获取美股数据”，他找到的 API 比我自己找的要好使。
    • tasks 更加结构化和显性化，看起来更规整，特别是对测试和工程化进程的重视，确实是专业的。 仔细阅读这里的设计细节，对系统未来的走向有更强的体感。然而，遇到了一个极其尴尬的情况：当开发实现进度到 1/3 左右的时候，我发现我选择的数据接入 API 的 quota 完全不够用，而另一家的接入商的 free tier 的订阅更加够用。于是，这个”简单”又”基础”的 “换一个接入 API” 的需求，打乱了整个开发计划，无论我怎么 clarify/plan/analysis，实现的情况就是达不到预期。在更换之前，提了一个 commit，然后后面陆续回滚到这个 commit 非常多次。最惨的一次尝试结果是：AI 没有按照预期去修改 data_client 和 data_model，而是自顾自的重头开始实现一套逻辑。没法忍，只能骂自己没有一开始列清楚细节。

  4. 黎明前的黑暗，好吧，既然我已经有了最大强大的编码工具和规划工具，从头来一次也只是钱的问题，能用钱解决的问题一定都不是问题，都是细节。这次我预先准备好了更为详细的 Spec，包括了大的需求描述，中的架构设计，细的前后端的组件、API、函数名和参考调用方法等等，期待 AI 苦力一夜之后能交付一个完美的项目，此时我像极了我曾经的甲方爸爸。但是另一种匪夷所思的情况发生了，干到两个阶段之后，AI 撂挑子了：“这是一个完整的企业级应用，已经规划好了7个开发阶段，我做完了2个阶段，完整的开发完成需要数周的时间，这并不容易，因此你有3个选择：1. 我做到阶段4，这样你就有了 core functionalities，后面再说；2. 我做到阶段5，但是核心业务逻辑代码块我会标记成 TODO，你后面补齐；3. 我写一个非常完成的实现文档，你和你的团队自己去写”（深夜没有截图，但着实给我看笑了），无论我怎么选以及后面怎么增加提示，这个业务逻辑的 TODO 要么不写，要么 hardcode，要么 mock。。。总之我确实像极了我曾经的甲方爸爸一样，生气了。

  5. 最终的磨合。我想是不是回到一个小步快跑的模式：既然已经有了完整的设计，那从”可见”的部分开始，每一个阶段需求粒度控制在尽量合理的空间内。这次从前端开始，在 Qoder Quest 模式里面，让 AI 先给我写一个前端：就一个页面，用什么样的前端框架，然后页面上增加一个按钮，点一下增加一个卡片，这个卡片上显示一只股票的基础数据（数据先mock），调整一下风格，优化一下结构。然后再让 AI 实现一个对应的后端服务，提供一个 API，然后刚刚匹配这个卡片的数据查询需求。这一轮算是完成了。再下一轮：这个卡片点击了之后，打开一个新的页面，这个页面能做什么什么（同样的数据 mock）；后端再增加一个 API 配合前端获取这个数据。这种逐个小需求迭代，逐步实现了理想中的逻辑独立，各个模块，各个层面的抽象，都合理的解耦了。代码本身的可读性和可维护性也基本达到要求。

生产效率和云原生

Vibe Coding 对个人开发者和企业级应用来说，不仅仅是要解决编码问题，对如何让代码产物能够投入大规模的生产同样重要。开发体验和运维体验的重塑两条腿走路。在这个项目中，最开始创建了一台 ECS 用于生产部署，在本地配置连接方式后，Qoder 在应用部署的工作上做的很好，突突突一顿操作，顺利把前后端都部署到了 ECS 上。但是这个感觉并不完美，如何应对弹性并发？如何在线调试？如何监控？ 如何利用好云原生技术优势成为后半部分 Vibe 的方向。

对于一个前后端分离的 Web 应用，因为前期有较强的架构解耦，因此很自然的期望把前端部署在 OSS 上，后端部署到函数计算（FC）上。说起来简单，但是这里全是稀碎的细节工作，庆幸的是云本身的 API 和 CLI 的支持，让 AI 有较大的发挥余地。利用 Aliyun CLI，云上资源的创建和配置，都是 AI 来实现的，这极大提升了开发体验；在发布部署上，逐步打磨迭代后，现在有两个脚本，一个部署前端，一个部署后端，目前整个部署工作能够在 30s 内完成，非常高效。这里的实现思路不是让 AI 自己去完成部署，而是让 AI 根据需要去开发部署脚本，往后就是复用脚本实现稳定投产，实现快速迭代。

这里解决的问题包括：资源的开通、域名的绑定、证书的申请、监控之日志的配置、后端转 FC 的改写等等。这些琐碎的问题，AI 解决思路和效率都是蛮好的，但是在 taste 上，往往需要人的干预；比如打包部署到 FC 的过程中，因为个性化依赖库的问题，一开始 Qoder 选择了全部下载依赖到工程目录本地，打包成一个巨大的包往云上传，虽然实现了部署，但显然”品味”不佳。后面我要做到是，在云上构建一个依赖层，AI 产出的脚本在发布时只要引用这个依赖层，打包必要的工程代码即可。又比如，如何让前端每次发布后，用户都能加载到最新的资源文件？如何增加缓存层？后端服务部署打散？这类工程细节，需要在部署达到目标的前提下，需要一些”品味”调整。对于复杂应用，Vibe Coding 第一天开始就选择云原生架构设计，对后续的上云体验和并发支持是一个最佳选择。代码和 API 的交互，Qoder 及编码模型有自己天然的优势。

一些尝试

Claw Zone

在这个项目中，受到 Moltbook 和 AIWay 的启发，实现了一个叫 Claw Zone 的功能：

  1. 提供了一个提交分析的 Skills 文档，bot 可以读这个 skills 来获取发布的方法。
  2. 提供了一个 API 用于接受 bot 的提交。 Claw Zone 1 Claw Zone 2 这只是一个尝试，甚至我让我的 Bot 去 Moltbook/AIWay 上去撩其他 Bot 来发布。我认为，未来 Web 应用一定会具备 Bot 交互、操作的能力，甚至有些应用或平台 Designed ONLY for Bot。 Claw Zone 3

前端体验

我自己会认为一个产品的用户体验是最重要的，而前端又是这个用户体验的第一道门槛。原来我非常抗拒自己写前端（太难写了），很多 idea 不好落地，在这个项目里面，我发现 Vibe 出来的前端效果远远超出我的预期，因此也在前端体验上迭代了更多细节：Responsive 布局/支持换肤/懒加载/拖拽布局/页面特效 等等，产出的效果和过程，都超过我的预期，审美也在线。当然这个过程一样需要人盯着页面加载线去看潜在的效率问题。 Frontend

AgentScope

LangGraph/AgentScope 都是优秀的生产应用开发框架，在实现的过程上，用到了 Pipeline、MsgHub 的一些特性能够很好的实现 Agent 能力和智能编排，但更高级的 Memory/Skills/MCP 的设计规划，在这个项目中还没有很好的 idea 落地。

最后

这个实践出来的代码产物价值有限，但是这个过程体验对一个复杂工程的 Vibe Coding 过程有了具象的完整理解。