从广告到工程：构建 DIALØGUE 的技术经验总结

*这篇是我 DIALØGUE 介绍文的技术深挖 companion。若你还没看过 DIALØGUE 是什么、以及我为什么做它，建议先从那篇开始！*

这段旅程：从广告从业者到全栈工程师

先把房间里的大象说了——对，我来自广告行业。以前是 media plan、creative brief，不是 data structures、algorithms。但有趣的是：理解系统如何运作，不管是营销漏斗还是分布式架构，本质上都需要同一种分析思维。区别在于：在工程里你搞砸时，电脑会立刻告诉你。你不用等 campaign report 才发现。haha

构建 DIALØGUE 的过程……很硬核。它不只是“写代码”（虽然代码确实写了很多），而是要搭一套复杂系统：要编排多个 AI 服务、处理异步工作流、还要在用户做出意料之外行为时别崩。下面是这段旅程真正教会我的东西——好的、崩溃的、以及“为什么没人早点告诉我？”的那些时刻。

架构决策：为什么复杂度是敌人

新手常被忽略的一件事：复杂度不是你的朋友。我是在痛里学到的。真的很痛。你可以想象我淹没在 CloudWatch logs 里，试图搞清楚为什么我“优雅设计”的系统……就是不工作。T.T

初始架构（过度复杂）

我一开始用 LangGraph 做编排。为什么？因为图结构看起来很优雅！它很灵活！它看起来很可扩展！

现实是：它非常慢。即使本地跑也慢。即使上它的 cloud deployment 也慢。那些漂亮抽象最后都变成了……开销。大量、大量开销。

最终架构（务实且简单）

经过一轮灵魂拷问（和调试）后，真正能跑的是：

```
Frontend (Next.js) → API Gateway → Cloud Run Services → Cloud Workflows → Cloud Storage
                ↓
            Supabase (Auth + Real-time + PostgreSQL + Edge Functions)
```

注：我们在 2025 年 7 月从 AWS Lambda/Step Functions 迁移到 GCP Cloud Run/Workflows，成本下降 92%，性能提升 10 倍。

最大顿悟：当我改成直接 Supabase 查询，而不是把所有访问都再包一层 API 时，性能直接提升 10 倍（450ms → 45ms）。那些“看起来更规范”的 API layering？在这个场景里只是减速器。这种 database-first 架构后来也成为我们 GCP 迁移的基础。

AI 模型选择：别只看 hype

模型格局的现实

来聊聊 AI 模型。我基本都试过。不是“试玩一下午”的那种试，而是实打实放进真实构建流程里跑。几个月测试后（也烧掉了比我愿意承认更多的 API credits），真正可用的是：

我当前的主力栈：

- Claude（via Claude code）& Gemini 2.5 Pro（via Gemini CLI）：我的核心开发双人组。能力强到已经基本替代我工作流里的其他选项。

- Claude Sonnet 4 API：驱动 DIALØGUE 的脚本生成，temperature 设为 0 以保证 JSON 可靠性

我过去用过的栈：

DeepSeek：以前我常用它调难 bug，尤其深夜排障时。但 Claude 4 和 Gemini 2.5 Pro 出来后？这些边缘问题它们也能处理，甚至更好。模型能力进化让“专用调试模型”在我工作流里变得冗余。

真正有效的方式：

有趣点在这里：每个模型单独都已经很强。Claude 在架构思考和复杂推理上很出色。Gemini 2.5 Pro？在实现落地和跨超大代码库保持上下文方面非常夸张。Gemini 2.0 到 2.5 的跃升很明显——我真的“能感觉到”差距。响应更快、1M token 上下文窗口（是的，真的），而且它真的理解我在建什么。

但真正魔法发生在：让它们互相审稿。我会让 Claude 先设计方案，再让 Gemini 审查并提出改进；或者让 Gemini 先产出实现，再让 Claude 做边界情况和架构风险分析。那种来回 critique 的过程，往往能得到单模型各自都达不到的解法。

没跑通的（即使外界很热）：

OpenAI o1/o3：大家都在聊，但在我的真实开发场景里，太慢、太贵，实际收益也没高到匹配成本。
GitHub Copilot Workspace：理念很好，但 token 限制太容易撞天花板，做稍微大点的事就受限。

真实洞察：没人会告诉你的一个点是——不同模型“失败方式”不一样。早期 Gemini 会在某些错误上进入奇怪循环，卡住看不到问题；Claude 往往能很快指出来。但反过来，Claude 有时会把简单实现想太复杂，而 Gemini 几秒就搞定。关键不是找“唯一最强模型”，而是知道什么时候切换。

全栈开发：同一人戴多顶帽子

终端策略

这里有个非常实用、真的救过我 sanity 的习惯：不同上下文开不同终端窗口。听起来很简单？但非常有效。

```bash
# Terminal 1: Frontend Developer Me
cd podcast_generator_frontend_v2
npm run dev
# This is where I think about React components and user experience

# Terminal 2: Backend Developer Me  
cd gcp_services
./deploy/deploy-service.sh [service-name]
# This is where Cloud Run services live (much happier than Lambda!)

# Terminal 3: Database Me
supabase start --workdir supabase
# Local Supabase for testing, production for real work
```

我知道听起来有点搞笑，但“身体上切换终端”真的会让大脑跟着切上下文。frontend me 和 backend me 根本是两个人，他们需要自己的空间。

跨栈沟通

单人做全栈很奇妙。你基本是在和自己开会。所以我开始给“另一个自己”留 notes：

```
// Note from Frontend Me to Backend Me
/**
 * BACKEND TODO:
 * - Need endpoint GET /api/podcasts/:id/segments
 * - Should return: { segments: Array<{id, title, status, content}> }
 * - Must handle: 404 (not found), 403 (unauthorized)
 * - Real-time updates via Supabase subscription would be ideal
 * - Future me will thank you for error handling!
 */
```

```
## Backend Developer Summary for Frontend Integration
Current State:
- Endpoints implemented: POST /podcasts, GET /podcasts/:id
- Authentication: Bearer token via Supabase JWT
- Real-time: Supabase channel "podcast-updates"

Next Frontend Tasks:
1. Implement podcast creation form
2. Subscribe to real-time updates
3. Handle error states (401, 403, 404, 500)
```

这些小 note 在我一周后回看代码时就是救命绳。否则我根本不知道过去的我在想什么。

关键技术收获

1. 系统思维可跨领域迁移

广告背景让我习惯系统化思考——用户路径、转化漏斗、归因模型。这些心智模型可以直接迁移到：

分布式系统设计
用户体验流程
性能优化
错误处理策略

2. Production-First 心态

# What I learned to prioritize

if works_in_production and meets_user_needs:

ship_it()

else:

fix_only_blockers()

# Perfect is the enemy of done

3. 全栈能力是真实可达的

构建 DIALØGUE 需要：

Frontend: React 19、Next.js 15、TypeScript、实时订阅、WebSocket 管理（我修过 memory leak！）
Backend: Python 3.12、Cloud Run（14 个微服务）、Cloud Workflows、PostgreSQL（via Supabase）
Infrastructure: GCP（从 AWS 迁移）、API Gateway、Cloud Storage、Vercel（前端托管）
AI/ML: Claude 4.0、Perplexity API、OpenAI TTS、temperature 优化（JSON 场景用 0）
DevOps: Docker containers、Cloud Build、监控、JWT 安全（P-256 迁移）
Database: PostgreSQL + RLS、Edge Functions、用于竞态条件防护的原子操作

4. 经典训练的重要性

正式的软件工程训练（系统设计、数据结构、算法）非常关键。它不仅是“让 AI 写代码”，更是你要知道该问什么、以及该如何架构。

最后想法

这一路下来，我对自己的职业身份理解完全变了。以前我是“管理技术团队的人”。现在？我可以真正和他们一起构建。而且说实话，这感觉非常好。 :D 这种演化在我开始做原生 iOS 应用但并不懂 Swift 时继续被验证——结果发现广告能力（审美、创意方向、知道“好”是什么感觉）有时比编码能力更关键。

从广告到工程，不只是学语法和框架，而是重塑大脑：用系统方式思考、用方法论调试、并接受“你有时会为了一个丢失分号花 3 小时”（好吧 TypeScript 会抓这类错误，但你懂我的意思）。

你知道最有趣的是什么吗？广告里那套分析思维——理解用户路径、优化转化漏斗——几乎可无缝迁移到工程。区别只是，在代码里出错时电脑会立刻给你反馈，不用等 campaign 报告。直接、残酷、即时。

这个“产品”已经在线： podcast.chandlernguyen.com。它能用。还不完美，但它是我做出来的。每次修 bug、每个新功能、每个“aha!”瞬间，都在构成这段持续演进的旅程。

你有没有经历过这种职业大转向——从一个领域跳到完全不同的领域？你最意外的感受是什么？欢迎告诉我！

致敬，

Chandler

P.S：既然说到“踩坑式学习”——想看一个微小 AI 参数改动如何让我每月多花 $54 吗？看这篇 One AI Parameter Change Cost Me $54/Month。它是一个很好的警示：当你把生产代码交给 AI 助手却没明确生产约束时会发生什么。剧透："make it work" 和 "make it production-ready" 是两种完全不同请求。

P.P.S: 我还在一边踩坑一边学工程。现在继续做 AI 应用，也继续努力不把生产环境搞挂。后面还有新故事，记得回来看看。