停止‘Vibe Coding’。开始编排：我如何构建一个Agentic新闻编辑部（而非Wrapper）

Source: Dev.to

By Rizwanul Islam (Afraim) – 智能未来架构师 | Founder @ Gaari & The Trail

他们称之为 “Vibe Coding”——一种认为只要通过提示工程就能打造独角兽，而不需要了解数据库模式的想法。这是一个诱人的谎言。虽然 Vibe Coding 适合构建玩具，但用于构建系统则是灾难性的。我不做玩具，我构建足以承载数千用户重量的可靠架构。

当我为 The Trail（高性能新闻聚合平台）和 Gaari（孟加拉国的高端车辆租赁平台）进行架构设计时，我没有使用 AI 为我编写代码。我使用 AI 来 execute 我设计的代码。

“Vibe Coding” 陷阱

“Vibe Coding” 依赖概率。你让 LLM “构建一个新闻应用”，它会幻觉出一个看起来很漂亮但在负载下会崩溃的 React 组件。它消除了语法的摩擦，但也消除了理解的摩擦。

当你构建像 Gaari 这样的系统时，它处理：

• 110+ 个 API 端点
• 复杂的多服务预订流程
• 实时支付网关（Stripe / Bkash）

你不能靠“随意感”来解决数据库中的竞争条件。你需要 不可动摇的可靠性。

转变

停止把 AI 当作会写代码的“神奇八球”。
开始把 AI 当作需要严格架构约束的 初级开发者。

案例研究：将“The Trail”构建为群体

大多数 “AI 新闻应用” 只是 OpenAI API 的包装器：用户提问 → 机器人回答。这种方式脆弱且容易出现幻觉。

对于 The Trail，我不想要聊天机器人。我想要一个数字新闻编辑部。于是我采用了 Agentic Swarm 架构。系统不再只有一个提示，而是被编排为多个专职代理：

• Planner（规划者） – 扫描网络热点话题并定义范围。
• Researcher（研究员） – 从已验证的来源获取数据（不允许出现幻觉）。
• Writer（写手） – 仅依据 Researcher 提供的数据撰写内容。
• Critic（批评者）（关键） – 根据质量评估标准（SEO、可读性、事实核查）审查草稿。如果得分 < 8/10，则拒绝草稿并强制重写。

代码 vs. 编排

// Writer agent produces a draft
let draft = await writerAgent.write(plan, facts);

// The Orchestration Loop
if (review.score < 8) {
  console.log(`Quality fail (${review.score}). Rewriting...`);
  // trigger rewrite logic
}
return await publisherAgent.publish(draft);

技术栈：Next.js + Supabase（可靠性层）

要支持这种代理式工作流，你需要既能跟上 AI 速度又像银行一样安全的基础设施。对于 Gaari 和 The Trail，我统一使用 Next.js + Supabase 技术栈。

为什么选择 Supabase？

Gaari 的架构处理敏感的用户数据（预订、支付）。即使 AI 代理失控或前端出现 bug，数据库也会物理拒绝未授权的查询。这就是 坚不可摧的可靠性。

为什么选择 Next.js 14？

Next.js 提供服务器端渲染、API 路由以及 edge‑runtime 能力，完美契合实时 AI 编排和快速迭代的需求。

“创始人模式” 思维方式

关于“Founder Mode”有一场热议——即领导者必须了解细节的理念。作为这些系统的架构师，我不把数据库模式外包。我也不把 API 当作“黑箱”。我了解 The Trail 架构中 30 多张表的每一张。

要成为 2026 年的 100× Engineer，你必须转变：

• 从： 编写语法（AI 能做到）。
• 到： 设计系统（AI 做不到）。

结论：打造引擎，而不是仅仅涂装汽车

我在 Gaari 和 The Trail 的工作证明，构建企业级软件并不需要 50 人的团队。你需要的是 system mindset。停止随意感受，开始进行编排。

如果你正在构建需要扩展的系统，停止寻找 “code snippets”，而是开始关注 architecture patterns。

Discussion

您是在使用 AI 编写代码，还是在为 AI 设计执行系统？