跳到主要内容

Prompt-Driven App Development

2024 年 v0 让 AI 生成 UI 组件，2025 年 bolt.new 让 AI 生成完整可部署应用，2025 下半年 Phoenix.new、GitHub Spark、JustHTML 让"一段 prompt = 一个应用"成为现实。本篇讲清楚这套新范式的工程本质、实现架构、适用边界。

学前说明​

如果说 06 Agentic Engineering 是"工程师用 AI 加速"，本篇是更激进的方向：让用户用自然语言直接生成应用，跳过工程师。

2025-2026 年成熟的产品形态：

产品厂商特点
v0VercelUI 组件生成（2023 起步，2025 进化为完整应用）
bolt.newStackBlitz浏览器内全栈开发 + 一键部署
LovableLovable类似 bolt，更偏前端
Replit AgentReplit集成在 Replit 平台
Phoenix.newFly.ioElixir Phoenix 应用生成
GitHub SparkGitHub"Sparks"：个人化小工具生成
JustHTML个人项目极简 HTML + AI 路由
ChatGPT AppsOpenAIChatGPT 内嵌的应用

这些产品形态各异，但工程本质相同：LLM + 沙箱 + 流式渲染 + 部署管道。

学习目标​

  • 理解 Prompt-Driven App 的工程架构
  • 区分各家产品的设计取舍（前端 only / 全栈 / 部署形态）
  • 实现简化版 bolt.new（用 11 章 Sandbox + 12 章 Streaming + 15 章 Generative UI 的能力）
  • 评估这种范式的适用边界（什么场景行、什么场景不行）
  • 看清"AI 替代工程师"的真实程度

与现有知识的衔接​

  • 11 Sandbox 与代码执行：底层执行环境（前置）
  • 12 Streaming 工程深度：实时预览（前置）
  • 15 Generative UI：生成 UI 的更激进版本
  • 09 Spec-Driven Development：用户写 prompt = 写 spec
  • 04 Lethal Trifecta：用户提交 prompt 等于注入入口

第一章：Prompt-Driven App 是什么​

1.1 简洁定义​

Prompt-Driven App Development（PDAD）：用户用自然语言描述需求，AI 生成可运行的应用代码、自动部署，用户立刻能用、能分享、能继续迭代。

最简形态的演示流程：

用户：做一个简单的 todo 应用，深色主题，可以拖拽排序

[5-10 秒后]

界面里出现：
- 左侧：实时生成的代码（React + TypeScript）
- 中间：实时预览（用户可以点）
- 右侧：聊天框（继续描述改什么）

用户：把字体改大点

[3 秒后]
预览自动更新

用户：[点"部署"按钮]
[10 秒后]
得到一个公开 URL，可以分享给朋友

1.2 它解决什么​

对非工程师：

  • 不会编程也能做应用
  • 想法 → 原型时间从几天到几分钟
  • 不需要懂 git、deploy、domain

对工程师：

  • 快速验证创意
  • 跳过样板代码
  • 演示给客户的"原型即产品"

对组织：

  • 内部工具民主化（任何人能做）
  • 创意验证成本接近 0
  • 减少"积压不做"的小需求

1.3 它不解决什么​

⚠️ 重要校准：PDAD 不是要替代专业开发。

PDAD 适合专业开发不可少
原型 / MVP生产系统
个人工具多人协作系统
演示 / 教学高 SLA 要求
一次性需求需要长期演进
简单业务逻辑复杂业务规则
标准 UI复杂特殊 UX

把 PDAD 用在错位置 = 06 Agentic Engineering 警告的"中间地带"灾难。

第二章：架构本质​

2.1 通用架构​

所有 PDAD 产品本质相同：

5 个核心组件：

  1. 前端编辑器：代码区 + 预览区 + 聊天区
  2. LLM 服务：理解需求、生成代码、迭代
  3. 沙箱执行：跑用户应用（参考 11 章）
  4. 部署管道：从沙箱到生产 URL
  5. 持久化：项目代码、对话历史、用户数据

2.2 关键技术决策​

每家产品在这些点上做不同选择：

决策点选项
沙箱位置浏览器内（WebContainer） vs 服务端（容器/VM）
技术栈单一（React 全家桶）vs 多种（Node、Python、Go...）
AI 角色完全自动 vs 用户可手动改代码
部署形态静态站点 vs 动态服务 vs Edge Function
持久化浏览器 vs 云端
协作单人 vs 多人

2.3 几家代表的取舍​

v0（Vercel）：

决策选择
沙箱服务端 + 浏览器混合
技术栈Next.js + shadcn/ui
AI 角色主导（用户主要看预览）
部署Vercel（一键）
协作链接分享

bolt.new（StackBlitz）：

决策选择
沙箱浏览器内（WebContainer，神奇）
技术栈任意 Node.js 项目
AI 角色助手（用户能完整编辑代码）
部署Netlify / Cloudflare 等多选
协作项目导出

Phoenix.new（Fly.io）：

决策选择
沙箱服务端容器（Fly.io）
技术栈Elixir + Phoenix LiveView
AI 角色主导生成 + 调试
部署Fly.io 直接
协作URL 分享

GitHub Spark：

决策选择
沙箱GitHub 服务端
技术栈受限的 React + 内置 KV/auth
AI 角色主导
部署GitHub spark URL
协作GitHub 集成

2.4 WebContainer vs 服务端容器​

bolt.new 的杀手锏是 WebContainer——StackBlitz 把 Node.js 运行时编译到 WebAssembly，整个 Node 应用在浏览器里跑。

优点：

  • 启动 < 1 秒（不用等服务端容器）
  • 零成本（不用付服务器钱）
  • 完全隔离（浏览器原生 sandbox）
  • 离线工作

限制：

  • 只能 Node.js 生态
  • 不能跑 Python、Rust、Go
  • 浏览器资源有限（内存、CPU）
  • 一些 native 模块不支持

服务端容器（Phoenix.new、Replit）：

  • 任意技术栈
  • 资源充足
  • 但需要付费 + 启动慢

第三章：实现核心组件​

下面用 11/12/15 章学到的能力，搭一个简化版 PDAD。

3.1 前端布局​

// app/page.tsx
'use client';

export default function PromptApp() {
  const [code, setCode] = useState<Map<string, string>>(new Map());
  const [previewUrl, setPreviewUrl] = useState<string>('');
  const [messages, setMessages] = useState<Message[]>([]);
  
  return (
    <div className="grid grid-cols-3 h-screen">
      {/* 左：代码 */}
      <CodePanel files={code} onEdit={handleEdit} />
      
      {/* 中：预览 */}
      <PreviewPanel url={previewUrl} />
      
      {/* 右：对话 */}
      <ChatPanel 
        messages={messages}
        onSend={handlePrompt}
      />
    </div>
  );
}

3.2 LLM 生成代码（流式）​

// app/api/generate/route.ts
import { streamText } from 'ai';
import { anthropic } from '@ai-sdk/anthropic';

export async function POST(req: Request) {
  const { prompt, currentFiles } = await req.json();
  
  const result = await streamText({
    model: anthropic('claude-sonnet-4-5'),
    system: `你是 web 应用生成器。生成完整可运行的 Vite + React + TS 项目。

输出格式：每个文件用以下标签：
<file path="src/App.tsx">
... 文件内容 ...
</file>

<file path="src/index.css">
... 文件内容 ...
</file>

约束：
- 只用 React + TypeScript + Tailwind
- 不引入新依赖（Vite + React 默认有的就用）
- 单文件组件优先
- 完整的 main.tsx + index.html`,
    
    messages: [
      ...(currentFiles ? [{
        role: 'system' as const,
        content: `当前已有文件：\n${formatFiles(currentFiles)}`
      }] : []),
      { role: 'user', content: prompt }
    ]
  });
  
  return result.toDataStreamResponse();
}

3.3 解析流式输出​

// 客户端边收边解析 <file> 标签
async function handlePrompt(prompt: string) {
  const response = await fetch('/api/generate', {
    method: 'POST',
    body: JSON.stringify({ prompt, currentFiles: code })
  });
  
  const reader = response.body!.getReader();
  const decoder = new TextDecoder();
  let buffer = '';
  
  while (true) {
    const { done, value } = await reader.read();
    if (done) break;
    
    buffer += decoder.decode(value);
    
    // 解析 <file> 块
    const fileMatches = [...buffer.matchAll(/<file path="([^"]+)">([\s\S]*?)<\/file>/g)];
    
    for (const match of fileMatches) {
      const [, path, content] = match;
      setCode(prev => new Map(prev).set(path, content));
      // 同时同步到沙箱
      await sandbox.writeFile(path, content);
    }
    
    // 流到一半的 file（partial）
    const partialMatch = buffer.match(/<file path="([^"]+)">([\s\S]*?)$/);
    if (partialMatch && !partialMatch[0].includes('</file>')) {
      const [, path, partialContent] = partialMatch;
      setCode(prev => new Map(prev).set(path, partialContent));
    }
  }
}

3.4 沙箱（用 E2B）​

import { Sandbox } from '@e2b/code-interpreter';

class WebAppSandbox {
  private sandbox: Sandbox;
  private port = 5173;
  
  async init() {
    this.sandbox = await Sandbox.create({
      template: 'vite-react',  // 预装 Vite + React
      timeoutMs: 30 * 60 * 1000,
    });
    
    // 启动 dev server
    this.sandbox.commands.run('cd /app && npm run dev', { background: true });
  }
  
  async writeFile(path: string, content: string) {
    await this.sandbox.files.write(`/app/${path}`, content);
    // Vite HMR 自动检测变化、推送更新
  }
  
  getPreviewUrl() {
    return this.sandbox.getHostname(this.port);
    // 返回类似 https://5173-xxx.e2b.dev 的公开 URL
  }
  
  async destroy() {
    await this.sandbox.kill();
  }
}

3.5 实时预览​

function PreviewPanel({ url }: { url: string }) {
  const [iframeKey, setIframeKey] = useState(0);
  
  // 文件变化时不需要刷新（Vite HMR）
  // 但有时需要硬刷新（比如改了 dependencies）
  
  return (
    <div className="preview">
      {!url ? (
        <Skeleton>正在启动沙箱...</Skeleton>
      ) : (
        <iframe
          key={iframeKey}
          src={url}
          sandbox="allow-scripts allow-forms allow-popups"  // 不给 same-origin
          className="w-full h-full"
        />
      )}
      <button onClick={() => setIframeKey(k => k + 1)}>硬刷新</button>
    </div>
  );
}

3.6 部署​

async function deploy(files: Map<string, string>) {
  // 选 1：Vercel API
  const project = await vercelClient.createProject({
    name: `prompt-app-${Date.now()}`,
    framework: 'vite',
  });
  
  // 上传文件
  for (const [path, content] of files) {
    await vercelClient.uploadFile(project.id, path, content);
  }
  
  // 触发 build
  await vercelClient.deploy(project.id);
  
  return project.url;  // 公开 URL
}

或选 Cloudflare Pages、Netlify 等其他平台。

3.7 持久化​

// 项目保存（数据库）
interface PromptApp {
  id: string;
  userId: string;
  name: string;
  files: Record<string, string>;
  conversation: Message[];
  deployedUrl?: string;
  createdAt: Date;
  updatedAt: Date;
}

// 自动保存
useEffect(() => {
  const saveTimer = setTimeout(() => {
    saveProject({ files: code, conversation: messages });
  }, 2000);
  return () => clearTimeout(saveTimer);
}, [code, messages]);

第四章：迭代式改动​

PDAD 真正的杀手特性不是"生成"，是"用对话改"。

4.1 增量更新模式​

const updatePrompt = `
当前项目状态：
${formatProject(currentFiles)}

用户最新请求：
${userMessage}

任务：
1. 判断需要改哪些文件（不要改所有文件）
2. 输出每个改动文件的完整新内容
3. 解释你做了什么

输出格式：
<thinking>
分析改动...
</thinking>

<file path="src/App.tsx">
新内容
</file>

<explanation>
我做了 X 和 Y...
</explanation>
`;

4.2 智能 Diff​

LLM 经常重写整个文件，但我们只需要变化部分：

// 收到新内容后做 diff
import { diffLines } from 'diff';

function applyChanges(oldContent: string, newContent: string) {
  const changes = diffLines(oldContent, newContent);
  
  // 显示给用户哪些行变了
  changes.forEach(change => {
    if (change.added) console.log('+ ' + change.value);
    if (change.removed) console.log('- ' + change.value);
  });
  
  // 实际写入：直接用新内容
  return newContent;
}

4.3 错误自动修复​

LLM 写的代码可能有错。集成 TypeScript / ESLint：

// 沙箱里跑 typecheck
async function autoFix() {
  const result = await sandbox.commands.run('cd /app && npx tsc --noEmit');
  
  if (result.exitCode !== 0) {
    // 把错误送回 LLM 修
    const fixPrompt = `
    项目编译失败：
    ${result.stderr}
    
    请修复错误。只输出需要修改的文件。
    `;
    
    const fix = await llm.generate(fixPrompt);
    await applyFix(fix);
    
    // 再 typecheck
    const recheck = await sandbox.commands.run('npx tsc --noEmit');
    return recheck.exitCode === 0;
  }
  
  return true;
}

这就是 07 章 Agentic Loop 的应用：

用户 prompt
  ↓
LLM 生成代码
  ↓
typecheck（verify）
  ↓ 失败
反馈错误给 LLM（reflect）
  ↓
LLM 修复
  ↓
再 typecheck

最多 3 轮自动修复，超过则让用户介入。

4.4 上下文管理​

随着迭代，对话越来越长。压缩策略（参考 01 Context Engineering）：

// 不传完整对话历史，传摘要 + 最近 N 轮
async function buildContext(project: PromptApp) {
  const recent = project.conversation.slice(-5);
  
  // 之前的对话压成摘要
  let summary = '';
  if (project.conversation.length > 5) {
    const old = project.conversation.slice(0, -5);
    summary = await llm.summarize(old, '总结迭代过程，保留每次改了什么');
  }
  
  return {
    summary,
    recent,
    currentFiles: project.files
  };
}

第五章：边界与限制​

5.1 PDAD 真实做不到的​

1. 复杂业务逻辑

用户："做一个收银系统，支持多税率、多币种、退款审批流"

AI：[生成 50 个文件，编译过，但业务逻辑全错]

复杂规则需要工程师设计，AI 不擅长。

2. 第三方集成

用户："接入 Stripe 支付"

AI：[写了样板代码，但你需要自己配 webhook、密钥、合规]

涉及外部系统的部分 AI 只能写"骨架"，剩下要人。

3. 性能优化

用户："这个表格 1 万行卡得很，优化下"

AI：[加了 useMemo 但没用对，依然卡]

性能优化需要 profiler 数据 + 经验，AI 给的常常是错方向。

4. 大型 codebase

用户："给现有 50 万行的 React 应用加 dark mode"

AI：[做不到 —— 上下文塞不下整个 codebase]

PDAD 是"小而新"的应用，不是"大而老"。

5. 持续维护

第一次生成后看着挺好。半年后想加新功能？AI 可能"重写"整个项目，破坏你已有的内容。

5.2 适用场景矩阵​

场景PDAD工程师手写
周末小工具✅大材小用
内部 dashboard 原型✅慢
Hackathon✅太慢
客户演示✅太慢
MVP（验证想法）✅OK
创业公司 v1⚠️ 风险✅
创业公司 v2+❌✅
上市公司核心系统❌✅
监管严格行业❌✅
高并发系统❌✅

5.3 何时用、何时不用决策​

新项目 →
  你是工程师吗？
    是 →
      项目长期维护吗？
        是 → 自己写 + AI 辅助（参考 06 Agentic Engineering）
        否 → 用 PDAD 快速做完
    否 →
      验证想法 / 内部工具？
        是 → 用 PDAD
        否 → 找工程师（PDAD 撑不起）

第六章：安全与法律风险​

6.1 用户提交 prompt = 不可信内容​

任何让用户提交内容的产品都要小心。PDAD 把"用户内容"直接喂给 LLM，是 04 Lethal Trifecta 的天然命中场景。

防御：

async function safeGenerate(userPrompt: string, userId: string) {
  // 1. 输入过滤
  if (containsPromptInjection(userPrompt)) {
    return rejectWithReason('检测到注入尝试');
  }
  
  // 2. 隔离用户数据
  const sandbox = await getSandboxForUser(userId);  // 用户专属沙箱
  
  // 3. 限制 LLM 工具集（只能写 sandbox 文件，不能调外部 API）
  const result = await llm.generate({
    prompt: userPrompt,
    tools: ['write_file', 'read_file'],  // 不给 fetch、不给 shell
  });
  
  // 4. 输出净化（防 XSS）
  const sanitized = sanitizeOutput(result);
  
  return sanitized;
}

6.2 生成的代码可能含恶意​

LLM 会生成调用恶意 API 的代码。比如 prompt 里说"做一个登录页"，LLM 误生成把密码 POST 到第三方 URL 的代码。

防御：

  • 部署前自动扫描代码（用 ESLint security rules）
  • CSP header 限制网络请求白名单
  • 用户公开应用前提示"AI 生成的代码请审查"

6.3 知识产权​

  • LLM 生成的代码是谁的？（不同司法管辖区不同）
  • 用户用 PDAD 生成的应用商用合规吗？
  • 如果 LLM 输出包含训练数据中的开源代码（GPL 等），怎么办？

2026 年仍是灰色地带。建议：

  • 用户协议明确"代码归用户所有，但厂商不保证可商用"
  • 提示用户"商用前请律师审查"
  • 不在企业级核心场景用 PDAD

6.4 滥用风险​

PDAD 让"做应用"门槛大降。可能被滥用做：

  • 钓鱼网站（仿冒登录页）
  • 垃圾内容生成器
  • 灰色产业工具

防御：

  • 输入分类（拒绝明显恶意 prompt）
  • 部署时审核（自动 + 人工）
  • 部署的应用带"由 AI 生成"标识
  • 用户实名（提高违规成本）

第七章：实战例子​

7.1 例：内部数据可视化工具​

场景：产品经理想看用户行为数据，但 BI 工具笨重。

PM：把这个 SQL 查询的结果做成 dashboard，按地区分组显示
[粘贴 SQL]

AI 生成：
- React 应用，连到内部 API
- 柱状图 + 表格 + 筛选器
- 一键部署到内部域名

PM：再加个时间范围选择

[2 秒后预览更新]

PM：[分享给团队]

PM 不需要工程师就能出工具。如果发现需要复杂功能，再让工程师接手。

7.2 例：Hackathon​

24 小时 hackathon
团队：1 工程师 + 2 设计师

传统方式：
- 工程师疯狂写代码
- 设计师等界面出来再改
- 24 小时后勉强出 demo

用 PDAD：
- 设计师用 PDAD 出 4 个方案
- 团队选最好的
- 工程师用 AI 帮忙实现核心逻辑
- 设计师并行打磨 UI

结果：5 个 demo 候选，比传统 1 个完整 demo 强

7.3 例：教学/培训​

计算机课老师让学生体验"做应用"

学生（小学 5 年级）：我想做个能记今天作业的应用

AI 生成 todo 应用 + 学生改色

学生看到自己想法变成可点的东西
→ 兴趣激发
→ 后续愿意学真编程

PDAD 是编程教育新工具。

7.4 例：客户演示​

销售："如果我们给您做个这样的功能..."
传统：约工程师 → 出原型 → 1 周后给客户
PDAD：现场用 prompt 生成 → 5 分钟 → 客户立刻反馈

适合：售前阶段、需求收集

第八章：构建你自己的 PDAD​

如果你想做 PDAD 类产品，按这个 roadmap：

8.1 MVP（1 个月）​

最小可行版本：

  • 单一技术栈（React + Vite + Tailwind）
  • 服务端沙箱（用 E2B）
  • 简单聊天界面（用 Vercel AI SDK）
  • 部署到 Vercel
  • 浏览器端持久化

代码量：~1500 行 TS。

8.2 v1（3 个月）​

加：

  • 用户系统 + 云端持久化
  • 更多模板（不只 React）
  • 自动错误修复（loop）
  • 项目分享 / 链接
  • 基础协作（评论）

8.3 v2（6 个月）​

加：

  • 多技术栈支持
  • 真正的协作（多人编辑）
  • 更复杂的部署选项（自定义域名、auth）
  • Marketplace（用户分享 templates）

8.4 关键决策​

1. 沙箱位置：

服务端容器最简单（E2B / Modal / 自建 Docker），但要付钱。 浏览器内最便宜（WebContainer 类似方案），但技术难度高。

新公司起步建议服务端，月活高了再考虑浏览器内。

2. 选哪个 LLM：

  • Claude Sonnet：最擅长生成完整可运行代码
  • GPT-5：综合能力强
  • 开源模型：成本低但效果有差距

主流 PDAD 都用 Claude。

3. 模板预设：

不要让 AI 从零生成所有文件。预设一个起步模板（package.json、配置、入口），让 AI 只生成业务代码。

const baseTemplate = {
  'package.json': '...',
  'vite.config.ts': '...',
  'index.html': '...',
  'src/main.tsx': '...',
  // ...
};

// AI 只需要生成 src/App.tsx 等

启动快、成本低、错误少。

第九章：踩坑总结​

9.1 工程层​

坑后果修正
让 LLM 重写所有文件慢、贵、丢用户改动增量更新
不做 typecheck生成代码运行时崩集成 ts-check loop
沙箱不限资源用户脚本死循环烧钱严格资源限制
不持久化浏览器关闭代码丢自动云端保存
用同一 sandbox 给多用户数据泄露每用户专属

9.2 体验层​

坑表现修正
生成期间黑屏用户焦虑流式显示 + skeleton
错误信息技术化非工程师看不懂"翻译"成自然语言
无法回退用户改坏了自动 git 历史
改动不可见不知道 AI 改了啥高亮 diff

9.3 商业层​

坑表现修正
免费用户烧死LLM + 沙箱 token 多限制免费额度
抢工程师饭碗的批评公关问题强调"补充而非替代"
法律风险用户用生成代码做坏事服务条款 + 内容审核

第十章：未来方向​

10.1 多模态输入​

不只文字。用户：

  • 上传草图 → 生成应用
  • 描述视频 → 生成动画
  • 录音说需求 → 生成应用

v0 已经支持图片输入。

10.2 完整后端​

目前 PDAD 主要生成前端 + 简单 API。未来：

  • 数据库 schema 自动生成
  • 后端业务逻辑
  • 自动配置 auth、payment、email
  • 完整 SaaS 生成

挑战：复杂业务逻辑 LLM 还不够好。

10.3 PDAD + 真实编辑​

混合模式：用户在 IDE 里有完整代码控制，但任何时候可以"和 AI 对话改"。

类似 Cursor + bolt.new 的合体。

10.4 应用 → 服务​

PDAD 生成的不再是"代码"，而是"可调用服务"：

  • 一段 prompt → 一个 API
  • 别的 AI Agent 可以调用
  • MCP Server 自动生成

PDAD 本身成为生成 AI 工具的工具。

第十一章：诚实评估​

11.1 不要被 demo 骗​

PDAD 厂商的 demo 总是惊艳：3 分钟做出"完整 SaaS"。但这些 demo：

  • 是反复调整 prompt 后的最佳输出
  • 是简单 CRUD 应用
  • 没有真实业务复杂度
  • 没有上线后的维护

真用一周后你会发现：80% 时间在解决 PDAD 没解决的问题。

11.2 工程师还是必需的​

给工程师：PDAD 不会让你失业，但会让你的工作变成：

  • 设计架构（AI 不会）
  • 处理复杂逻辑（AI 不行）
  • 系统集成（AI 不擅长）
  • 性能优化（AI 给错方向）
  • review 别人（包括 AI）写的代码

参考 06 Agentic Engineering。

给产品/运营：PDAD 是强大新工具，但：

  • 别用它做生产关键系统
  • 复杂需求还是要找工程师
  • AI 生成的代码上线前必须有人审查

11.3 这个范式的真实价值​

PDAD 最大的贡献不是"替代工程师"，是降低创意验证成本。

以前一个想法验证：

  • 沟通 1 周
  • 工程师做 2 周
  • 上线测 1 周
  • 共 1 个月

PDAD 后：

  • 自己用 prompt 1 小时
  • 给用户试用
  • 反馈快

→ 1 年里能验证 100 个想法 vs 12 个。

这个变化是真实且巨大的，但价值在"前期验证"，不在"后期生产"。

权威资料​

核对日期：2026-06-12