10-MVP 循环：自动化从创意到部署的全流程

Title: Vibe Coding：软件开发的静默革命 Excerpt: 软件开发领域正在发生一场静默的革命，这与新的 JavaScript 框架无关，而是关于“谁”——或者说“什么”——在承担繁重的工作。这就是 Vibe Coding，一种利用 AI Agent 从想法直接到 MVP 的新范式。 Content: 软件开发领域正在发生一场静默的革命，这与某种新的 JavaScript 框架毫无关系。它的核心在于谁——或者说什么——在承担那些繁重的工作（heavy lifting）。

想象这样一个场景：你在候机。你突然有了一个想法。当你落地时，你不仅仅是在手机里记了几行笔记；你已经拥有了一个完整部署的 MVP（最小可行产品），包含了数据库、身份验证和前端界面，并且已经在一个可访问的 URL 上跑起来了。你没有写一行语法代码。你只是在管理这个流程。

这并非科幻小说。这就是人们开始称之为 "Vibe Coding" 的新范式，它正在从根本上改变创业公司的经济学。

大多数创始人仍然被困在旧的循环中：想法 -> 招聘/编码 -> 调试 -> 部署。这个循环太慢了。新的循环是这样的：上下文 (Context) -> AI Agent -> 验证 (Verification)。

过去几周，我一直在打磨一套技术栈，旨在自动化开发过程中那些乱七八糟的中间环节。它让我能够并行推进十个潜在的 MVP。以下是具体的配置、工作流，以及关于它在何处会“掉链子”的大实话。

"Vibe" 技术栈

要实现这一点，你需要的是能够互相“对话”的工具。我们追求的不是最复杂的企业级解决方案，而是速度和集成度。这是我的工具箱：

1. 框架: create-t3-turbo (一个基于 Turborepo 构建的 Monorepo 设置，在一个地方同时处理前端和后端。包含 Next.js, tRPC, Tailwind 和 Prisma。非常适合 MVP)。
2. 大脑: Claude Code (充当首席工程师角色的 CLI 工具)。
3. 项目管理: Linear (单一事实来源 / Source of Truth)。
4. 追踪: GitHub Issues (与 Linear 同步)。
5. 基础设施: Vercel (托管) + Neon (Serverless Postgres)。

Vercel 和 Neon 都有非常慷慨的免费额度，这意味着你的试错成本实际上为零。

设置阶段

在你写下一行代码之前，你需要先把这台机器“接好线”。以下是确切的设置过程：

1. 初始化项目

首先创建一个新的 create-t3-turbo 项目。这会给你一个生产就绪的 monorepo 结构，所有配置都已就绪：

npx create-turbo@latest -e https://github.com/t3-oss/create-t3-turbo

这条命令会生成一个完整的技术栈：Next.js 用于前端，tRPC 用于类型安全的 API，Prisma 用于数据库管理，Tailwind CSS 用于样式设计——所有这些都组织在一个 Turborepo monorepo 结构中。

2. 安装 Claude Code

接下来，安装 Claude Code，这是你的 AI 开发助手。请遵循 code.claude.com 上的安装指南。安装完成后，你可以在项目目录中启动它：

claude

3. 设置 GitHub Actions 集成

在 Claude Code CLI 内部，运行以下命令安装 GitHub Actions 集成：

/install-github-app

此命令会设置 GitHub Actions 机器人，使 Claude 能够创建 Pull Request、运行 CI/CD 工作流并与你的代码库交互。这种集成允许 Claude 通过自动化工作流执行代码更改，而不仅仅是提出建议。有关详细的设置说明，请参阅 GitHub Actions 官方文档。

4. 将 Linear 连接到 GitHub

当你将 Linear 连接到 GitHub 进行双向 Issue 同步时，奇迹就发生了。操作如下：

1. 前往 Linear 的 GitHub 集成页面
2. 点击 "Add Integration" 并授权 Linear 访问你的 GitHub 账户
3. 选择你想要同步的仓库
4. 配置同步设置：
   • 双向同步 (Bidirectional sync): 在 GitHub 创建的 Issue 会自动出现在 Linear 中，反之亦然
   • 状态映射 (Status mapping): 将 Linear 的工作流状态 (Todo, In Progress, Done) 映射到 GitHub 的 Issue 状态
   • 优先级同步 (Priority sync): 保持两个平台的优先级同步
   • 自动链接 (Auto-linking): 使用 Issue ID 自动将分支和 PR 链接到 Linear Issue

配置完成后，当你在 GitHub 中创建一个 Issue，它就会出现在 Linear 中。当你在 Linear 中更新优先级或状态时，更改也会反映在 GitHub 中。这创造了一个统一的工作流，你可以从任一平台管理任务。

5. 部署基础设施

最后，部署到 Vercel 并连接 Neon 数据库：

• 将你的 GitHub 仓库连接到 Vercel
• 配置一个 Neon serverless Postgres 数据库（有免费层级）
• 将数据库连接字符串添加到你的 Vercel 环境变量中

一旦部署完成，你就拥有了一个持续集成管道，可以从你的想法直通一个实时的 URL。每一次合并到 main 分支都会自动部署到生产环境。

自动化工作流

这就是传统产品经理 (PM) 角色开始消退的地方。

1. 上下文会话 (The Context Session)

如果你有一个想法，不要打开 IDE。打开一个聊天窗口。与 ChatGPT 或 Claude 对话，倾倒你最初的、粗糙的想法。让 AI 来挑战你。在这个会话结束时，要求它生成一份 Markdown 格式的 PRD（产品需求文档）。

你得到的结果通常比大多数中级 PM 写出的都要好。它细节丰富、结构清晰且专业。

洞察: 我相信专职的“产品经理”角色将是第一个被 AI 颠覆的。我们正在通过一个“产品设计师”或“全栈创造者”的世界，人类负责愿景，而 AI 负责规格说明。

2. 移交 (The Handoff)

将那份 Markdown PRD 喂给你本地的 Claude Code。这是关键的一步，AI 将需求转化为可执行的工作项。

在 Claude Code CLI 中，指示它解析 PRD 并生成 GitHub Issues。Claude Code 在底层使用 GitHub CLI (gh) 与你的仓库进行交互。过程如下：

1. 解析: Claude 分析 PRD 并将其分解为独立的、可执行的任务
2. 创建 Issue: 对于每个任务，Claude 运行类似以下的命令：

   gh issue create --title "Implement user authentication" \
     --body "Details from PRD..." \
     --label "feature" \
     --assignee "@me"
   

3. 分配元数据: Claude 会根据 PRD 中描述的复杂性，自动分配标签（feature, bug, enhancement）、优先级，甚至估算时间
4. 依赖映射: 如果设置了 GitHub Actions 集成，Claude 还可以创建 Issue 依赖关系和里程碑

使用 gh CLI 的美妙之处在于它是可编程的——Claude 可以在几秒钟内批量创建几十个 Issue，每个都带有格式完美的 Markdown 描述、验收标准和技术说明。

突然之间，你的 Linear 看板就亮了起来。多亏了你之前配置的 Linear-GitHub 同步，你会看到 10 到 20 个工单自动填充进来——标题准确，描述详细，优先级和状态一应俱全。以前 PM 需要数小时手动创建的整个积压工作 (backlog)，现在不到一分钟就生成了。

3. 执行 (The Execution)

现在，你扮演的是工程经理 (EM) 的角色。你在 Issue 中 @claude 开始处理工单。Claude 编写代码，在 GitHub Actions 中运行，创建 Pull Request，并等待审查。

你点击合并。

Vercel 的 CI/CD 启动。几分钟后，更改上线。

这一切的美妙之处在于，它可以在你的手机上完成。你可以在出租车上或咖啡馆里审查 PR 并管理看板。你不再是那个敲击通用 React 样板代码的人；你是在指挥一支高速运转的施工队。

"最后一公里" 问题

如果你读到这里就停下来，你可能会认为 AI 已经解决了一切。其实不然。

虽然 "Vibe Coding" 很强大，但我们需要诚实地面对它的局限性。AI 在处理“脏活”和“枯燥活”方面表现惊人。它可以比任何人类都快地搭建数据库模式、构建登录表单和设置 API 路由。

但它在把握产品的“灵魂”方面很挣扎。

这就好比盖房子。AI 是你的框架施工队。他们可以以创纪录的速度浇筑混凝土、立起龙骨、挂好干墙。但他们是糟糕的室内设计师。他们不知道那个角落的灯光开关手感不对，或者厨房的动线会让人们撞到一起。

在软件中，这就是“最后一公里”。那些让用户感到愉悦的交互、微妙的 UI 动画、业务逻辑中的边缘情况——这些是你，作为人类构建者，必须介入的地方。

如果你 100% 依赖 AI 来完成产品，你最终得到的软件在技术上是可行的，但在情感上是空洞的。它将缺乏那种将伟大的产品与平庸之作区分开来的“匠心”。

实用建议

如果你今天想尝试这个，这是我的建议：

• 从 PRD 开始: 永远不要要求 AI “直接写代码”。代码的质量取决于 PRD 的质量。把你的精力花在打磨需求文本上，而不是代码语法上。
• 信任但要验证: AI 编码 Agent 可能会产生幻觉，引入不存在的依赖项或编写不安全的逻辑。阅读 diff（差异对比）。把 AI 当作一个有天赋但资历尚浅的初级开发者。
• 拥抱数量: 利用这种速度来测试更多的想法。如果你能在一个周末而不是一个月内构建一个 MVP，你找到产品市场契合度 (PMF) 的几率就会呈指数级增长。

构建产品的门槛已经消失了。剩下的只有你的品味和你的坚持。