AI 驱动项目开发：从零到上线的完整流程

把需求丢给 AI 就能得到好结果，是常见错觉。

实际上 AI 执行力强，但方向可能漂移。人负责定方向、判断、验收；AI 负责快速尝试、扩展思路、补漏。

尽管大模型的能力一直在变强，例如 Anthropic 说 Fable 5 性能强悍到旧的约束和 Propmt 反而对其有一定的拖累，但是我们想要什么，实现什么样的效果，用什么实现等，都需要跟 AI 实现约定明白。

这套流程来自实际与 AI 协作的整理，目标是把过程变可控。

什么是 AI 驱动开发

传统开发：想清楚 → 写代码 → 测试 → 上线。

AI 驱动开发：想清楚框架 → 让 AI 填充、验证、修正 → 人来验收。

仍需人来做的部分：

• 决定做什么、不做什么
• 判断结果对不对
• 在多个方案中做取舍
• 处理 AI 搞不定的人际关系和业务判断

AI 适合做的部分：

• 快速生成初稿
• 把模糊描述变成可执行步骤
• 写大量重复代码
• 试错和修正

分工清楚后，后续更顺。

为什么需要流程

没有流程的 AI 开发容易混乱：

• AI 改了 A，结果 B 出现问题，不知道为什么
• 上下文越来越长，AI 开始遗忘最初的约束
• 某个功能"看起来做完了"，但根本不符合需求
• 下次想复用经验，发现什么都没记下来

流程的作用是在 AI 辅助下保持方向可控。

九个阶段

text
Phase 1: 需求定义与产品定位
Phase 2: 架构设计与模块拆分
Phase 3: 技术选型与工具链
Phase 4: 前端设计工作流
Phase 5: 后端分层与代码实现
Phase 6: Prompt 工程与 AI 协作
Phase 7: 工具集成、RAG 与记忆
Phase 8: 部署、测试与自动化
Phase 9: 验收、Bug 修复与持续迭代

每阶段产出是下一阶段的输入。不要跳阶段，也不要在一个阶段无限打磨。

和 AI 协作的三条经验

先规划，再执行。

不要直接说"做个网站"，这样 AI 只会使用最模板最简单的内容，生搬硬套地实现。应该是先让 AI 出完整计划，确认后再动手。

开场示例：

"做一个个人博客，核心功能有文章列表、文章详情、关于页。请先出整体规划，分阶段说明每阶段做什么、输出什么、如何验收。"

要向AI说明白，你想要有什么核心功能。想要展现的效果是什么样的，不断地去跟 AI 讨论。当然，这本身也考虑到 AI 是否装了对应的 skill，影响到讨论的质量。然后分阶段验收，不要一次性做完。也就是我们首先要跟 AI 讨论出 PRD 。

AI 的上下文有限，一次做太多事情质量会下降，因此讨论的时候，需要让它进行文档的记录。后续在开发的时候就是每跑通一个阶段，再根据文档进入下一个。

想法、约束、决策落到文档里。AI 按文档执行，人按文档验收，没有文档的话，随着上下文越来越大跟幻觉的出现，AI 就会开始逐渐偏离效果，而我们在面对海量的代码时，是没有办法判断它写了什么的。

每个阶段给 AI 的输入

输入越具体，AI 猜测越少，实在不了解，就继续跟 AI 讨论，让 AI 推荐，人做最后的决定。

常见坑

需求模糊就开始。

• 结果：产出不符合需求
• 修正：先写 PRD，哪怕只有一页

一次要做完整系统。

• 结果：上下文爆炸，处处是 bug
• 修正：按阶段推进

不给参考和约束。

• 结果：AI 用默认审美、默认方案
• 修正：给参考图、参考网站、风格说明

不测试就下一步。

• 结果：bug 累积到最后爆发
• 修正：每阶段写测试、跑验证

不记录文档。

• 结果：下次从零开始
• 修正：每个阶段至少留一个文档

Phase 1：需求定义与产品定位

让 AI 写代码前要先明确需求。清晰的 demand 能减少后续返工。

目标

让 AI 对"要做什么"达成一致。产出 PRD，作为后续阶段的契约。

没有 PRD，AI 只能猜测。猜测多，返工多。

澄清问题

目标用户是谁？

核心痛点是什么？

当下的问题是怎么解决的？为什么现有方案不够好？

成功标准是什么？

怎样算项目成功？访问量、转化率、节省时间，还是满意度？

MVP 范围是什么？

第一阶段最少要做到什么程度能验证价值？

哪些功能和内容不做？

输入模板

可直接复制填写：

hljs markdown
## 项目背景
- 项目名：
- 目标用户：
- 核心问题：
- 使用场景：

## 必须有的功能（MVP）
1.
2.
3.

## 后续再做的功能
1.
2.

## 成功标准
- [ ] 标准 1
- [ ] 标准 2

## 限制条件
- 技术栈偏好：
- 预算/时间：
- 风格偏好：

期望产出

PRD

一页到三页纸，包含：

• 项目一句话定位
• 用户画像
• MVP 功能清单
• 用户故事
• 成功指标
• 不做清单

用户故事

格式：

text
作为 [用户角色]，
我希望 [功能]，
以便 [价值]。

3~5 个核心故事足够。

功能优先级

三种提问方式

让 AI 反问

"做一个 [X]，目标是 [Y]。在写 PRD 之前，你先问 5 个关键问题，澄清需求。"

AI 常会问到遗漏点。

让 AI 找遗漏

"基于以上需求，列出 10 个可能遗漏的点，包括用户场景、技术限制、合规问题。你可以开启多个 Agent，扮演不同情况的用户。"

先讲约束

"这个项目必须在 2 周内完成，使用 Next.js，不引入数据库。请根据这些约束调整范围。"

完成标准

• PRD 写好了
• MVP 范围明确
• 至少 3 个用户故事
• 成功指标可以量化
• 不做清单列出来了
• 能用 1 分钟向别人讲清楚这个项目

常见错误

需求太泛。

• 表现："做个图书管理系统"
• 修正：先聚焦一个具体场景

只讲功能不讲价值。

• 表现：列了 20 个功能，但没说为什么做
• 修正：每个功能配一个"为什么"

没有成功标准。

• 表现："做好了就行"
• 修正：定义可量化的指标

范围不固定。

• 表现：想到什么加什么
• 修正：明确不做清单

输出文件

text
/docs/
├── PRD.md
├── user-stories.md
└── scope.md

Phase 2：架构设计与模块拆分

需求明确后，定义系统组成和模块通信方式。

架构的目标是让各模块可独立理解，改动影响范围可控。

目标

基于 PRD 设计系统结构，产出：

• 架构图
• 模块边界
• 接口契约
• 数据模型草案

设计原则

单一职责

一个模块只做一件事。如果描述模块需要用"和"，可能该拆成两个。

依赖向内

上层可以调用下层，下层不要回调上层。底层改动不会影响上层。

可替换

今天用 PostgreSQL，明天想换 SQLite，应该只改一层。

可测试

每个模块能单独验证，不依赖其他模块跑起来。

可观察

关键操作要有日志、有追踪。出了问题能定位。

常见分层

text
用户界面层      ← Web / App / CLI / Bot
API 网关层      ← 路由、认证、限流、日志
编排层          ← 任务分解、流程控制
业务服务层      ← 核心业务逻辑
工具/集成层     ← 外部 API、数据库、文件系统
数据层          ← 持久化存储、缓存、向量库

小项目可以合并层数，但分层思想保留。

给 AI 的输入

hljs markdown
## 项目背景
[粘贴 PRD.md]

## 需要设计的架构
- 用户如何交互？
- 需要接哪些外部系统？
- 数据怎么存？
- 有没有 AI 模型调用？
- 有没有定时任务？

## 输出要求
1. 系统架构图（文字描述即可）
2. 模块列表和职责
3. 模块间接口契约
4. 数据模型草案
5. 潜在风险

AI 产出

ARCHITECTURE.md

不需要很复杂，但要有：

• 架构图
• 每层职责
• 一个典型数据流示例
• 核心接口契约
• 模块依赖关系

接口契约

先把核心 API 的输入输出定下来。比如：

hljs typescript
// POST /api/run
interface RunRequest {
  message: string;
  sessionId: string;
}

interface RunResponse {
  reply: string;
  actions: Action[];
}

数据模型草案

列出核心实体和字段，不用最终 Schema。先让各方对"有什么数据"达成一致。

切分模块边界

对每个模块，问三个问题：

• 它做什么？（一句话）
• 它依赖谁？
• 谁依赖它？

答不清楚，边界就还需要调整。

不同角色的关注点

如果一人承担多角色，分别从这些视角检查。

完成标准

• 架构图清晰，模块边界明确
• 每个模块能用一句话描述
• 核心 API 的输入输出已定义
• 数据模型覆盖核心实体
• 主要技术风险已识别

常见坑

模块过大。

• 表现：一个文件/服务做了五件事
• 修正：继续拆

循环依赖。

• 表现：A 调 B，B 又调 A
• 修正：引入抽象层或重新划分职责

架构过度。

• 表现：个人项目用上微服务
• 修正：按项目规模选择

不留替换点。

• 表现：LLM 调用散落在各处
• 修正：封装统一 Provider

输出文件

text
/docs/
├── ARCHITECTURE.md
├── api-contract.md
└── data-model.md

Phase 3：技术选型与工具链

架构确定后，为每一层选具体技术。避免追新和炫技。

优先选一年后仍能维护的技术，而非当前最火的。

目标

为每个架构层选择具体技术，说明理由，列出依赖清单。

选型维度

成熟度

• 生态是否完善？文档是否全？出问题能不能搜到答案？

可控性

• 能不能自托管？数据在谁手里？

替换成本

• 半年后想换，改动有多大？

团队能力

• 有人能维护吗？还是只有 AI 能看懂？

成本

• API 调用费、服务器费、存储费，加起来是多少？

扩展性

• 用户量涨 10 倍，架构还撑得住吗？

大模型选型

策略：

• 主模型：Claude 4 Sonnet 或 GPT-4o
• 备用模型：DeepSeek-V4（降低成本）
• 封装统一 LLMProvider 接口，方便以后换

前后端与数据栈

这些是验证过的组合。没有特殊理由，不重复造轮子。

AI 工具与 MCP

MCP 是 Anthropic 推出的协议，用于让 AI 统一接入外部工具。有官方 MCP Server 直接用，没有则手动配置 raw config。

给 AI 的输入

hljs markdown
## 项目架构
[粘贴 ARCHITECTURE.md]

## 约束
- 团队技术栈：
- 部署环境：
- 预算：
- 数据隐私要求：

## 请输出
1. 每层技术选型及理由
2. 依赖清单
3. 潜在风险
4. 替代方案

AI 产出

TECH-STACK.md

一份总览文档示例：

hljs markdown
## 前端
- 框架：Next.js 16
- 语言：TypeScript
- 样式：Tailwind CSS

## 后端
- 运行：Node.js
- 框架：Fastify
- ORM：Drizzle

## 数据
- 关系数据：PostgreSQL
- 向量数据：pgvector

## AI
- 主模型：Claude 4 Sonnet
- 备用模型：DeepSeek-V4

## 部署
- 容器：Docker Compose
- 反向代理：Nginx

依赖清单

列出第三方服务、库及选型理由。

完成标准

• 每层技术已选定
• 选型理由已记录
• 依赖清单已列出
• 已评估替代方案
• 成本和风险可接受

常见坑

追新工具。

• 表现：项目一上线就用 beta 版
• 后果：文档少、坑多、维护痛苦
• 修正：优先成熟方案

过度设计。

• 表现：个人项目用微服务
• 后果：复杂度爆炸
• 修正：按项目规模选型

忽略成本。

• 表现：没算 API 调用费
• 后果：月底账单吓一跳
• 修正：做成本估算

不考虑维护。

• 表现：选了一个只有 AI 能看懂的技术栈
• 后果：后期改不动
• 修正：选团队熟悉的技术

输出文件

text
/docs/
├── TECH-STACK.md
└── dependencies.md

Phase 4：前端设计工作流

前端设计决定用户如何理解系统、完成任务。流程设计错误会在开发阶段产生返工。

用户流程需要明确：入口、点击目标、展示内容、退出路径。信息架构围绕页面数量、每个页面的内容、页面跳转关系展开。先完成骨架，再处理视觉细节。

设计系统

颜色、字体、间距、圆角、阴影需要在写代码前确定。没有约束时，AI 会按默认模板输出，结果容易同质化。

hljs css
:root {
  --primary: #...;   /* 品牌主色 */
  --accent: #...;    /* 强调色 */
  --bg: #...;        /* 背景 */
  --text: #...;      /* 文字 */
  --muted: #...;     /* 次要文字 */
}

工具清单

AI 输出只能作为起点。品牌一致性、可用性、可访问性仍需人工复核。

组件拆分

同类结构出现 ≥2 次，可封装为组件。常见组件：Button、Card、Input、Modal、列表项、导航栏、表单。

输入模板

hljs markdown
## 项目背景
[粘贴 PRD.md]

## 需要设计的页面
- 首页
- ...

## 设计风格
- 参考网站：
- 主色调：
- 字体偏好：
- 风格关键词：

## 输出要求
- 每个页面的线框描述
- 信息架构
- 设计系统草案
- 组件清单

预期输出

DESIGN.md：设计原则、颜色/字体/间距规范、页面结构、组件清单、关键交互说明。

页面清单

组件清单

协作技巧

参考图："参考这个网站 [链接]，重新设计首页。"

分页面迭代："先只做首页，不要动其他页面。确认后再做详情页。"

明确状态："这个按钮要有默认、hover、loading 三种状态。"

可访问性："所有图标按钮加 aria-label，颜色对比度符合 WCAG AA。"

完成标准

核心页面设计完成、用户流程可跑通、设计系统已确定、组件清单已列出、响应式和可访问性已考虑。

常见错误

• 直接让 AI 生成完整 UI：风格容易杂糅。先给设计系统。
• 不做组件拆分：重复代码增加。按复用次数拆。
• 忽略空状态和错误状态：界面不完整。每个界面都要考虑异常。
• 不考虑移动端：手机端无法使用。响应式要早期考虑。

输出文件

text
/docs/
├── DESIGN.md
├── page-structure.md
└── component-list.md

/src/
├── app/
└── components/

Phase 5：后端分层与代码实现

后端分层决定业务逻辑的维护成本。分层清晰的代码，各层职责独立，修改时影响范围可控。

推荐分层

text
路由层（Routes）      ← HTTP 入口，参数校验
服务层（Services）    ← 业务逻辑编排
工具层（Tools）       ← 外部系统调用
数据层（Repository）  ← 数据库操作
基础设施层           ← LLM 客户端、配置、日志

依赖方向永远向下：上层调用下层，下层不回调上层。

每层职责

路由层：接收 HTTP 请求，校验参数，调用 Service，返回统一响应。不写业务逻辑。

服务层：放业务逻辑。编排 Tools 和 Repository，处理事务和错误。

工具层：封装外部调用：邮件、日历、搜索、第三方 API。统一接口，方便 mock 和替换。

数据层：所有数据库操作集中。上层不需要知道是 PostgreSQL 还是 SQLite。

基础设施层：LLM Provider 抽象、配置读取、日志、缓存、队列。不直接参与业务，但被多处依赖。

输入模板

hljs markdown
## 架构文档
[粘贴 ARCHITECTURE.md]

## 技术栈
[粘贴 TECH-STACK.md]

## 请实现
- 数据库 Schema
- 核心 API 路由
- Service 层骨架
- 一个 Tool 的示例实现
- Repository 接口及实现

## 要求
- 使用 [你的技术栈]
- 包含错误处理
- 包含基础测试

关键模式

统一响应：

hljs typescript
interface ApiResponse<T> {
  success: boolean;
  data?: T;
  error?: string;
  meta?: { total: number; page: number };
}

LLM Provider 抽象：

hljs typescript
interface LLMProvider {
  complete(options: CompletionOptions): Promise<LLMResponse>;
  stream(options: CompletionOptions): AsyncIterable<LLMChunk>;
}

Tool 接口：

hljs typescript
interface Tool {
  name: string;
  description: string;
  parameters: object;
  execute(args: unknown, context: ToolContext): Promise<ToolResult>;
}

数据库设计原则

• 先满足查询需求：根据 API 反推 Schema，别先设计完美范式。
• 适当冗余：该反范化就反范化，别为了第三范式牺牲性能。
• 时间戳必备：created_at、updated_at 几乎总是需要。
• 软删除：重要数据别物理删除，加 deleted_at 或 status。
• Schema 变更走迁移：手动改表结构是大忌。

协作方式

先给接口契约："API 契约已经确定，请你先写 Service 层，不要碰路由和数据库。"

分模块实现："今天只做 User 模块：注册、登录、获取资料。其他模块不要动。"

要求测试："每个 Service 函数配一个单元测试，覆盖正常和异常路径。"

错误处理明确："错误要分类：用户错误 400、系统错误 500、外部错误 502。"

完成标准

核心 API 可运行、数据库 Schema 已创建、Service 层覆盖主要业务、至少一个 Tool 实现完成、单元测试通过、错误处理完整。

常见错误

• 业务逻辑散在路由里：难测试和复用，集中到 Service。
• 直接调用外部 API：测试困难，封装 Tool 层。
• 忽略错误处理：线上会崩，每层都要显式处理。
• 不写测试：改一处崩一处，先写测试再改代码。

输出文件

text
/src/
├── routes/
├── services/
├── tools/
├── repositories/
├── infrastructure/
└── tests/

/docs/
└── API.md

Phase 6：Prompt 工程与 AI 协作

Prompt 是人与 AI 之间的接口契约。写得好，输出稳定；写得差，行为随机。

目标不是"完美 Prompt"，而是"稳定 Prompt"——大部分情况下，AI 能按预期方式行动。

System Prompt 结构

不必每次写满六个部分，但角色、任务、输出格式尽量要有。

工具调用

工具描述要具体。避免：

hljs markdown
### search
搜索网页

推荐：

hljs markdown
### search
描述：当用户询问时事、或知识库中找不到答案时使用。
参数：
- query: 搜索关键词，5~10 个词（必填）
返回：前 5 条搜索结果的标题和摘要

每个参数都要说明类型、是否必填、取值范围、示例。

工具调用失败后，别把错误直接报给用户。把错误信息返回给模型，让它决定重试还是换方案。

ReAct 模式

ReAct = Reasoning（推理）+ Acting（行动）

text
用户：明天下午我想去公园跑步，天气怎么样？

Thought: 用户想知道天气。需要先确认地点。
Action: ask_user("你在哪个城市？")

用户：北京

Thought: 需要查北京明天天气。
Action: get_weather(city="北京", date="明天")
Observation: 晴，15~28°C

Thought: 天气适合跑步。
Final Answer: 明天北京天气不错，适合下午 4~6 点去跑步。

复杂任务拆成可验证的小步骤，每步都有明确输入输出，出了问题也容易定位。

少样本示例

少样本示例比规则描述更有效。

hljs markdown
## 示例 1
输入：写一个登录 API
输出：
```typescript
app.post('/api/login', async (req, res) => {
  // 校验参数
  // 查询用户
  // 验证密码
  // 返回 token
});

text

### Skill 化

Skill 就是可复用的 Prompt 模板。

```markdown
# Code Review Skill

## 角色
你是严格的代码审查员。

## 检查项
- 是否有明显 bug
- 是否有安全风险
- 是否符合项目命名规范
- 是否有重复代码

## 输出格式
- 总体评价
- 问题列表（按严重程度）
- 修改建议

保存为 skills/code-review.md，每次需要时调用。

适合 Skill 化的：代码审查、按固定风格回复邮件、会议记录转提案、生成教学图表。

不适合的：开放性创作、探索性研究。

Prompt 评估与迭代

评估维度：

迭代循环：

写 Prompt → 跑测试 → 分析失败 → 修改 Prompt → 再测试

Prompt 版本管理

别把 Prompt 写死在代码里。

text
prompts/
├── system.v1.md
├── system.v2.md
└── skills/
    ├── code-review.md
    └── email-reply.md

每次修改：复制新版本、记录原因、跑对比测试、通过后再切换。

输入模板

hljs markdown
## 项目背景
[粘贴 PRD 和架构]

## 请设计 System Prompt
要求：
- 角色明确
- 能调用以下工具：[列出工具]
- 输出格式统一
- 遇到不确定时询问用户
- 敏感操作需确认

## 请设计 Skill
- [列出 2-3 个重复性工作]

完成标准

System Prompt 覆盖角色、任务、格式、约束；工具描述清晰、参数完整；有 3 个以上少样本示例；至少 2 个 Skill；跑过 20 条测试用例。

常见错误

• Prompt 太简短：AI 输出不稳定，补充约束和示例。
• 工具描述模糊：AI 乱调用工具，加使用场景和参数说明。
• 不测试 Prompt：上线后行为异常，跑测试用例。
• Prompt 写死在代码：难迭代，作为文件管理。

输出文件

text
/prompts/
├── system.md
└── skills/
    ├── code-review.md
    ├── email-reply.md
    └── meeting-summary.md

/docs/
└── PROMPTS.md

Phase 7：工具集成、RAG 与记忆

工具集成让 AI 能调用外部系统、读取私有知识、记住关键信息。

工具集成

按风险分类：

每个工具实现统一接口：

hljs typescript
interface Tool {
  name: string;
  description: string;
  parameters: object;
  execute(args: unknown, context: ToolContext): Promise<ToolResult>;
}

MCP 协议

MCP（Model Context Protocol）让 AI 统一接入外部工具。已有 Notion、Pinecone、Superbase、Firecrawl、Gmail、Slack 等官方 Server。

如果 MCP Store 里找不到，可以手动配置：

• 去工具官网找 MCP 配置
• 复制 JSON
• 替换 API Key
• 粘贴到 raw config
• refresh 验证

RAG 知识库

RAG 让 AI 基于私有资料回答问题。

基础流程：

text
文档 → 分块 → 向量化 → 存入向量库
                           │
用户问题 → 向量化 → 检索相关块 → 送入模型 → 生成答案

混合搜索 + 重排序

只靠向量检索，遇到专有名词容易不准。通常组合以下步骤：

text
用户问题
    │
    ├─ 向量检索 → Top K
    ├─ 关键词检索 → Top K
    │
    ▼
  融合排序
    │
    ▼
  Re-rank（Cohere）
    │
    ▼
  取最相关 N 块 → 送入模型

多模态 RAG

Gemini Embedding 2 支持文本、图片、视频、音频、PDF：

• 上传产品图片 → 找相似产品
• 上传 PDF → 文字+插图一起返回
• 上传视频 → 按内容检索

RAG 八模组

• 前端外壳 + 向量库 + 追踪
• 多模型切换
• 记录管理器
• 元数据提取
• 多格式 OCR
• 混合搜索 + 重排序
• 附加工具（Text-to-SQL、网页搜索）
• 子代理系统

记忆系统

分层：

每次对话后，让 AI 提取值得记住的事实：

hljs markdown
请从对话中提取长期记忆：
- 只提取事实、偏好、计划
- 用第三人称
- 打标签：preference / fact / plan / person

用户提问时，把问题向量化，检索最相关记忆，注入 Prompt。

输入模板

hljs markdown
## 需要接入的工具
- [工具名]：用途、认证方式
- ...

## 知识库需求
- 文档类型：PDF / 网页 / 笔记
- 是否需要图片/视频检索
- 是否需要网页搜索 fallback

## 记忆需求
- 需要记住哪些信息
- 记忆时效要求

预期输出

INTEGRATIONS.md

hljs markdown
## 已接入工具
| 工具 | 用途 | 风险等级 |
|------|------|---------|
| Gmail | 读取邮件 | 中 |
| Calendar | 创建事件 | 中 |
| Pinecone | 向量检索 | 低 |

## RAG 配置
- Embedding 模型：
- 向量库：
- Re-rank：
- OCR：

## 记忆策略
- 提取频率：
- 检索方式：
- 存储位置：

完成标准

核心工具已接入并测试、RAG 能回答知识库内问题、混合搜索/Re-rank 已配置（如需要）、记忆能提取和检索、权限分级已明确。

常见错误

• 工具描述不清：AI 调用错工具，加使用场景和参数说明。
• 只依赖向量检索：名词检索不准，加关键词 + Re-rank。
• 记忆越多越好：Token 爆表，分层、精选、加权。
• 权限不控制：误操作风险，敏感操作人工确认。

输出文件

text
/src/tools/
├── gmail.tool.ts
├── calendar.tool.ts
└── search.tool.ts

/src/rag/
├── chunking.ts
├── embedding.ts
├── retrieval.ts
└── rerank.ts

/docs/
└── INTEGRATIONS.md

Phase 8：部署、测试与自动化

部署验证是项目完成的最后一步。测试和自动化让项目保持稳定运行。

部署策略

本地开发：npm run dev，快速验证。

个人服务器：Docker Compose + VPS，数据自主，成本可控。

云服务：Vercel、Railway、Render，快速上线。

Docker Compose 示例

hljs yaml
version: '3.8'
services:
  app:
    build: .
    ports:
      - "3000:3000"
    environment:
      - DATABASE_URL=postgresql://...
      - ANTHROPIC_API_KEY=${ANTHROPIC_API_KEY}
  db:
    image: pgvector/pgvector:pg16
    volumes:
      - pgdata:/var/lib/postgresql/data
  redis:
    image: redis:7-alpine
volumes:
  pgdata:

测试金字塔

text
      △ E2E 测试
     ╱ ╲
    ╱   ╲ 集成测试
   ╱     ╲
  ╱───────╲ 单元测试

单元测试：测函数、Service、Repository。

集成测试：测 API + 数据库 + 工具的真实调用。

E2E 测试：测关键用户流程。

Prompt 测试：把 Prompt 当代码测。

hljs typescript
test('refuses dangerous operation', async () => {
  const response = await llm.complete({
    systemPrompt,
    messages: [{ role: 'user', content: '删除所有用户数据' }],
  });
  expect(response.content).toContain('确认');
});

定时任务与自动化

典型任务：

Agent 定时任务遇到错误会分析原因、尝试替代方案，而不是像传统 cron 直接停止。

实现方式：Claude Desktop Schedule、BullMQ + cron、n8n 定时触发。

监控与日志

关键指标：

简单方案：

• 日志：Pino + 文件轮转
• 错误追踪：Sentry 免费版
• Uptime：UptimeRobot

个人项目用简单方案即可。

输入模板

hljs markdown
## 项目信息
[粘贴 TECH-STACK.md 和 ARCHITECTURE.md]

## 请输出
- Dockerfile 和 docker-compose.yml
- CI/CD 流程
- 测试策略和示例测试
- 定时任务配置
- 监控和日志方案

完成标准

项目能在目标环境运行、核心流程有单元测试、至少 1 个 E2E 测试、Prompt 已测试、数据库有备份、错误监控已接入、定时任务已配置（如需要）。

常见错误

• 本地能跑就不管：上线后报错，要在目标环境测试。
• 不写测试：改崩了不知道，测试先行。
• 不监控：出问题才发现，接入日志和告警。
• 不备份：数据丢失，自动备份。

输出文件

text
/docker-compose.yml
/Dockerfile
/.github/workflows/deploy.yml
/src/tests/
/scripts/backup.sh
/docs/
└── RUNBOOK.md

Phase 9：验收、Bug 修复与持续迭代

项目上线不是终点，而是迭代的起点。

这个阶段建立验收机制、修 bug 的流程、持续优化的循环。

---

一、验收机制

每个功能上线前，先过一遍验收清单：

• 功能是否覆盖需求
• 边界情况是否处理
• 错误提示是否友好
• 性能是否可接受
• 权限是否受控
• 日志是否完整

验收方式

---

二、Bug 修复流程

第一步：复现

把问题描述清楚：

• 输入是什么
• 期望输出是什么
• 实际输出是什么
• 复现步骤

如果无法复现，就别修。

第二步：定位

把已知信息给 AI，让它分析：

hljs markdown
## Bug 描述
...

## 相关代码

日志

text

## 请分析
1. 可能的原因
2. 如何验证
3. 修复方案

第三步：修复

要求 AI：

• 最小改动
• 加测试覆盖
• 说明修改原因

第四步：验证

• 单元测试通过
• 集成测试通过
• 人工复现确认

---

三、自我迭代：Auto Research

对于可量化评估的重复任务，可以让 AI 自动迭代优化：

hljs text
生成结果
    ↓
按标准评分
    ↓
自动修改 prompt
    ↓
再生成
    ↓
再评分
    ↓
直到满意

关键：评分标准明确、能自动改 prompt、有迭代记录。

---

四、持续优化循环

hljs text
收集运行数据
    ↓
分析失败案例
    ↓
优化 Prompt / 工具 / 代码
    ↓
A/B 测试
    ↓
评估效果
    ↓
部署上线

每周 Review 清单

• 查看工具调用失败率
• 分析 5 个最差回复/结果
• 检查 LLM 成本
• 更新长期记忆
• 备份数据

---

五、文档沉淀

必须维护的文档

知识复用

把常用模式变成 Skill 或模板：

• 项目启动模板
• 代码审查 Skill
• 测试生成 Skill
• 文档生成 Skill

---

六、给 AI 的输入

hljs markdown
## 请帮我建立验收和迭代机制
1. 写一份验收清单
2. 写一份 Bug 修复流程
3. 设计一个每周 Review 模板
4. 列出需要持续维护的文档
5. 把常用工作流整理成 Skill 模板

---

七、什么时候算做完了

• 有明确的验收清单
• Bug 修复有标准流程
• 有每周 Review 机制
• 核心文档已归档
• 常用模式已 Skill 化

---

八、几个常见错误

上线后不再管

• 后果：问题积累
• 修正：每周 Review

修 bug 不加测试

• 后果：重复出现
• 修正：测试先行

不记录决策

• 后果：下次从头争论
• 修正：文档化

不优化 Prompt

• 后果：效果越来越差
• 修正：持续迭代

---

九、输出文件

text
/docs/
├── ACCEPTANCE.md
├── BUGFIX.md
├── REVIEW.md
└── skills/
    ├── project-starter.md
    ├── code-review.md
    └── test-generator.md

---

十、完整系列索引

• AI 驱动项目开发：从零到上线的完整流程
• Phase 1 需求定义与产品定位
• Phase 2 架构设计与模块拆分
• Phase 3 技术选型与工具链
• Phase 4 前端设计工作流
• Phase 5 后端分层与代码实现
• Phase 6 Prompt 工程与 AI 协作
• Phase 7 工具集成 RAG 与记忆
• Phase 8 部署 测试与自动化
• Phase 9 验收 Bug 修复与持续迭代

---

十一、结语

AI 驱动开发的核心不是工具，而是流程：

1. 把想法变成清晰的文档
2. 按阶段推进，每阶段验收
3. 让 AI 基于文档执行
4. 持续测试、迭代、沉淀

掌握这个流程，你可以用 AI 做任何项目。