⭐10 天 AI 协作开发实录：一份可复用的 AI 开发流程样例

想先看效果？点击查看演示页面：演示页面

我用 10 天时间，借助多个 AI 模型和工具，完成一个项目的需求分析、产品设计、架构设计、数据库设计以及前后端开发。

这是一份可复用的 AI 辅助编程参考样例。过程中使用了不同模型与工具的优势能力。核心理念是以人为本：以自己的核心思路为基础，让模型帮你扩展成完整、具体、可落地的产品文档。核心思路一定是人的，模型只是用于激发与拓展人的思路。

模型/工具	阶段
`Gemini 3Pro` 网页版	需求分析、产品设计、架构设计、数据库设计
`Gemini 3Pro` / `Antigravity`	产品原型/`UI` 设计
`GPT5.1` / `Codex`	代码审核：后端开发、前端开发
`Claude 4.5` / `Kiro`	代码编写：后端开发、前端开发
`GLM 4.6` / `Claude Code`	简单问题梳理

0. 概览

工具与模型定位

开始前，我先简要说明为什么会用到这些模型和工具。

Gemini 2.5 和 Gemini 3 都很擅长逻辑判断与事件分析。8 月份我发布过用 Gemini 2.5 辅助产品设计的博文：《一种通过结构化提问，与LLM共创高质量PRD核心的实用指南》。这个模型的价值在于处理项目中的“设计”类工作，往往比 GPT、Claude 更出色。而 Gemini 3 的前端设计能力尤其强，也适合做 UI 设计。

Antigravity 是 Google 新推出的 AI-IDE，有免费额度，但门槛较高(主要是容易封号)，主要用于生产 HTML 的 UI 原型图。如果没有 Antigravity，用网页版也可以。

Codex 是 OpenAI 的 AI 编程工具（CLI 命令行/插件）。它比 Claude Code 更严谨、更可信，我把它当成一把精准的外科手术刀，用于代码审核，尤其适合审查其他模型写出的代码。审核的意义在于：我用 AI 越多，越意识到 AI 的不可靠，尤其在复杂逻辑上更明显。所以需要 Codex 根据最初需求与最终代码，检查是否符合业务需求以及代码本身是否存在问题。新版本 5.2-Codex 在指令遵循方面表现非常严格，适合解决疑难 Bug，而不太适合大型项目的奠基阶段。

Kiro 是亚马逊推出的 AI-IDE。推荐原因可见：https://mp.weixin.qq.com/s/Js9Pvclobge8dd168zSY4Q。`Kiro` 提出了 Spec 模式，即将一次代码工作拆分为：需求文档 -> 设计文档 -> 任务文档。每个流程都可人工干预。除 Kiro 外，还有两个开源的 Spec 项目，适用于多个 AI 工具（如 Codex、Claude Code 等）：1) Spec-kit：适合新项目，从 0 到 1 构建；2) Open-Spec：更轻量，适合旧项目新增功能，我更推荐这个。Kiro 目前仅支持 Claude 模型，且价格性价比很高。

GLM 4.6 / Claude Code：简单说，就是“国内的人开外国的车”。GLM 4.6 是智谱开源模型，性能约等于 Claude 4.1，但价格低，官方还有 20 元包月的编程套餐。Claude Code 是 Anthropic 发布的 AI 编程工具（CLI 命令行/插件），功能强大。总体来说 GLM 能力略弱，尤其在长上下文时性能下降明显，但在不想消耗 Codex、Kiro 额度时，GLM 的性价比很高。

这个博主对几个模型的总结也不错，可参考：https://mp.weixin.qq.com/s/PmOxyaY3QUZe59Ya5hjl7A

核心思路

先用一句话概括全流程：用 Gemini 3 产出需求与设计文档作为“地基”，再以 Spec 驱动后端与前端开发，由 Codex 贯穿代码审查与纠偏，最终将文档与实现闭环对齐。

flowchart LR
  A[需求与产品设计
Gemini 3] --> B[原型与 UI 设计]
  B --> C[架构与数据库设计]
  C --> D[后端开发
Claude + Spec]
  D --> E[前端开发]
  E --> F[持续审查与纠偏
Codex]
  F --> G[交付与迭代]

需求与文档产出

利用 Gemini 3 完成产品设计，输出一份完整的需求文档。

再基于需求文档，并善用 Google AI Studio 的分支能力，用 Gemini 3 完成原型设计、UI 设计、数据库设计与后端架构设计，最终沉淀为《需求文档》、《数据库设计文档》、《开发技术规范清单》、《后端架构设计文档》、《后端开发步骤清单》。

后端开发流程

根据 Spec 理念驱动开发，依赖需求文档、数据库设计文档、后端架构设计文档与后端开发步骤文档，使用 Claude 分阶段实现。

开发过程中，使用 Codex 对照文档逐条审查 Claude 的代码并修正。

如此循环，逐步完成后端开发步骤文档的每个阶段。

前端开发流程

基于 Gemini 3 生成的 UI HTML 页面进行前端 React 开发。使用 Codex，因为它的指令跟随能力更强，能更好还原 UI 设计图的样式；而 Claude 容易发散、Gemini 3 的工程化能力偏弱（经常出现修改文件导致错误）。因此我们组合了 Gemini 3 的前端设计能力与 Codex 的工程能力与指令跟随能力。

前端这部分主要是设计一个解耦清晰的组件结构，逐个接入后端接口，发现小问题再不断优化。

前端组件与样式

已有组件：用 Codex 将 React 代码转为 HTML + TailwindCSS，再交给 Gemini 3 基于现有代码给出多个样式方案。确定方案后，让 Codex 生成/修改 React 代码。
没有组件：将需求交给 Gemini 3 生成多个方案，后续流程同 1。

Google AI Studio 分支协作

我把初始需求对话作为“主线”，在 Google AI Studio 里复制上下文后开出 5 个分支窗口。每个分支都继承完整背景，因此在做专项设计时不会丢失需求信息。

这 5 个分支分别负责 UI 设计、数据库设计、总体架构设计、后端架构设计等不同方向，相当于 5 位“虚拟专家”。有具体问题时，我直接进入对应分支进行沟通解决。

flowchart TD
  A["产品设计
Gemini 3"] --> B[需求文档]
  B --> C{"Google AI Studio
分支协作"}
  C --> D1["原型设计
Gemini 3"]
  C --> D2["UI 设计
Gemini 3"]
  C --> D3["数据库设计
Gemini 3"]
  C --> D4["后端架构设计
Gemini 3"]
  D1 --> E[设计文档沉淀]
  D2 --> E
  D3 --> E
  D4 --> E
  E --> F[后端开发步骤文档]

flowchart TD
  A[后端开发步骤文档] --> B["后端实现
Claude 分阶段"]
  B --> C[Codex 对照文档审查]
  C --> D[修正与迭代]
  D --> B

flowchart TD
  A{前端组件与样式} --> B["已有组件
Codex 转 HTML + TailwindCSS"]
  B --> C[Gemini 3 多方案]
  C --> D[Codex 生成/修改 React]
  A --> E["无组件需求
Gemini 3 多方案"]
  E --> D

1. 需求分析与产品设计

首先要有一个核心功能需求，不需要完整，只需几句话。然后让 Gemini 辅助我们激活思维、逐步补全需求。Gemini 会提供思路与选项，但人要保持清醒：不要完全依赖 AI，核心思路必须来自人。

如何利用 Gemini 帮我们设计产品？可以查看我之前的文章：《一种通过结构化提问，与LLM共创高质量PRD核心的实用指南》

1.1 对话示例

这里简单截取几段对话：

使用《一种通过结构化提问，与LLM共创高质量PRD核心的实用指南》中的提示词

1 2	人: 提示词 Gemini: LLM询问 >> 准备好接受挑战了吗？请告诉我，你初步的产品思路或想要解决的问题是什么？

人：简要阐述需求

1
2
3

我希望实现一个医疗文件敏感词脱敏平台，需要有PC端、手机端。
相关背景：我已经实现了一个纯脱敏的API，也就是最核心的功能已经实现了，剩余的前端、后端服务业务等。
我希望前端能更人性化、更简单、更好用。能实现图片、PDF、压缩包文件脱敏，能实现脱敏可视化等一系列人性化功能。

Gemini：

收到。让我先复述一下你的现状和想法：
你手里已经有一把核心技术的"锤子"（现成的脱敏API），现在你想造一个精致、万能的"工具箱"（支持PC/手机、多格式、可视化的平台），让用户能"人性化"地使用这把锤子。

但在我们讨论"怎么做前端"之前，作为你的产品搭档，我必须立刻按下暂停键。我们现在处于第一阶段：定义问题空间。
你直接给出了解决方案（PC+手机端平台），但这背后有一个巨大的逻辑跳跃。我有几个非常尖锐的问题，请务必慎重思考：

Q1：核心场景与用户
"医疗文件"是一个非常严肃且受监管的领域。到底是谁，在什么具体的场景下，迫切需要把医疗文件进行脱敏？
是医生为了写论文/教学，需要处理个案病历？
是医院数据科为了给科研机构/药企提供批量数据？
还是保险理赔专员为了保护隐私处理理赔单据？
（我的质疑：不同的角色，痛点完全不同。如果是医生写论文，频率极低；如果是数据科，他们需要的是API对接而非图形界面。请具体描述一个典型的使用故事。）

Q2：关于"手机端"的致命质疑
你提到了需要手机端。请你告诉我，在医疗数据合规极其严格的今天，哪个医生或医疗从业者，敢把带有患者敏感信息的原始文件（PDF/图片），上传到自己的私人手机上进行处理？
这是一个真实的需求，还是你为了"功能大而全"而臆想出来的伪需求？

请回答以上两个问题，特别是告诉我：谁，在什么场景下，非用这个平台不可？

人：确认用户与场景

Q1：核心场景与用户
A1：不只是医生等人员，只要是医疗行业的业务人员都在上传病例等文件前都需要对个人信息进行脱敏。大部分的用户是CRC人员。
Q2：关于“手机端”的致命质疑
A2：请你放心，这个手机端是完全合规可行的。
Q：谁，在什么场景下，非用这个平台不可？
A：比如CRC，他们之前需要手动对图片进行敏感信息的覆盖，如果是100页的PDF，那么消耗的时间是非常之多的，而我的程序在100s内就可以完成100页的文件。极大的提升了CRC的工作效率

Gemini：进一步询问

....
太长不放了
....
手机端到底是用来拍照的，还是用来处理文件的？
用户如何信任并验证你的脱敏结果？（如果不验证直接交，出了事谁负责？）

人：说明本系统的核心思想，AI 预处理 + 人工复核

Q1：关于手机端的“真实操作流”
A1：这种场景可能是都有的，比如手机端上传图片、手机端选择已有的图片、PDF等文件，然后下载结果。但第一轮迭代我们可以只实现文件上传而不是拍照。有些CRC确实需要用手动操作，所以我们提供PC端+简洁化的手机端。
Q2：关于“信任”与“可视化”的悖论
A2：这个就是我们产品设计的问题，我有一个初步的设计，限制每页的结果，用户可以在结果图片上点击某个被遮盖的区域是否需要删除，也可以手动对没有被识别的区域进行手动画框进行脱敏。所以我们实现的是大量自动化+少量人工审核。

….中间略过…

Gemini：基于“AI 预处理 + 人工复核”，给出三种交互方式。

人：Gemini 提供了几种交互样例，但此时需要保持清晰。LLM 的方案是否合理，还要基于我们对产品的判断来筛选。若有疑虑，可以继续追问，直到敲定交互方案。

方案A：这个方案很好。我觉得可以给用户提供一个 list，每个 item 作为一块展示。第一行显示被脱敏的关键词，第二行显示关键词的上下文，并对关键词高亮，方便 CRC 快速检查误识别。
方案B：暂不考虑。
方案C：可以实现：先显示脱敏后的图片，按空格键显示 OCR 结果，并在 OCR 中对敏感词高亮，方便 CRC 快速查看；但我担心页面不够简洁，功能堆积，或者你有更好的方法。
全局搜索脱敏也可以做。

Gemini：给出最终方案。

PixPin_2026-01-19_10-52-26

人：基本功能确定后，继续讨论交互

我们刚讨论了结果可视化的模式，下面继续谈文件上传：图片、多图片、PDF、多 PDF、压缩包上传。不同类型文件的页面应该怎么做？需要哪些具体交互和功能？

Gemini：回答质量一般。
人：因为上一次回答一般，所以我提供一个大致思路引导 LLM。

我有一个设想：如果用户一起上传了多张图片或多个 PDF，或混合图片、PDF、压缩包，我们是否需要一页页面展示上传记录？
并且一次上传（即使是多个图片）也只作为一条记录。我们把记录做成文件系统的格式，将一次记录作为一个文件夹，文件夹内就是本次上传的所有文件；如果是 zip 也作为一个文件夹，可继续展开。
此外，也可以对整个记录进行评审（也就是我们第一次沟通的人工修正内容）。
请分析我提供的思路，也可以提出你的想法。

经过几轮对话，确定了核心页面结构

又经过几轮对话，基本敲定产品主要功能与核心交互方式。产品设计虽然是由 Gemini 引导流程，但在具体需求与设计上，一定是“人”来主导。LLM 往往提供好坏参半的思路，我们必须能清晰识别并修正。

1.2 《需求文档》

最终产出：一份包含产品定义、背景、目标用户、功能需求与基本交互方案的需求文档。这份文档很重要，后续的 UI 设计、后端架构设计、前端页面实现都需要它作为基础。

PixPin_2026-01-19_11-13-35

关键产出要点

明确目标用户与核心场景，完成需求边界收敛。
固化核心功能与交互原则（AI 预处理 + 人工复核）。
形成可复用的《需求文档》，作为后续设计与开发基准。

2. 产品原型

基于上一轮得到的“核心功能” + “核心页面结构”，可以让 Gemini 使用 ASCII UI 绘图法 画出线框图。

线框图的优点：

更聚焦当前工作：让大模型暂时不关注交互方式，核心聚焦页面结构。
更容易修改：大模型产出的原型通常需要多次修改，ASCII UI 绘图法比 HTML 的迭代速度更快。

比如下面这个，这是第一版，最终我让大模型改了四五版才得到最终方案。

关键产出要点

用 ASCII 线框快速聚焦页面结构与信息层级。
通过多轮迭代收敛页面布局与模块关系。
为后续 UI 设计提供结构化蓝本。

3. `UI` 设计

3.1 提示词

提示词（将需求文档拼接在提示词后）：

你是一位拥有 10 年经验的高级前端工程师和 UI 设计师，擅长开发复杂的 B 端工具类产品。
# 任务

根据下面提供的 **“产品需求描述”**，为用户创建一套完整、高保真、可交互的前端原型。你需要完成从分析、设计到实现的全过程。

# 工作流程

1. **分析与规划:**
   - **用户体验分析:** 基于用户需求，快速梳理核心交互逻辑。
   - **产品界面规划:** 规划清晰的信息架构和导航。
2. **高保真 UI 设计:**
   - **设计风格:** 采用现代化、简洁且专业的 Web 应用设计风格。
   - **视觉规范:** 确保色彩搭配和谐、字体排版清晰易读、元素间距一致。
   - **图标库:** 整合并使用 **Lucide Icons** 或 **FontAwesome** 图标。
3. **HTML 原型实现:**
   - **技术栈:** 必须使用 **HTML**, **TailwindCSS**, 和少量 **JavaScript**。
   - **文件结构:**
     - **每个界画应作为独立的 HTML文件存放**，例如home.html、profle.html、settings.html 等。如果有多个模块，单个功能页面可以放入不同的模块文件夹中。
     - **主入口文件`index.html` :** 所有代码必须包含在一个独立的 文件中。使用Iframe的方式嵌入这些 HTML片段，并将所有页面直接平铺展示在index页面中，而不是跳转链接。

大家都知道，Gemini 是前端的绝对王者。经过测试，我对比了 Antigravity（Gemini 3）、Claude Code（GLM 4.6）、Codex（GPT 5.1），最终发现 Gemini 3 的产出最简洁、可商用。

3.2 UI 原型图

下面是生成的两个页面，基本可以直接使用。因为现在 Antigravity 封号比较严重，也可以改用网页版 Gemini 3，一次生成一个页面即可。

关键产出要点

形成可直接复用的高保真 UI 页面原型。
统一设计风格与视觉规范，减少后续返工。
产出的 HTML 原型可作为 React 实现依据。

4. `Google AI Studio` 分支协作

在 Google AI Studio 中，可以基于当前对话历史新开分支窗口。这样新窗口会保留与 Gemini 的需求沟通记录，后续做其他设计时能更准确理解需求。我以最初的需求对话为基底，分支了 5 个窗口，分别处理 UI 设计、数据库设计、总体架构设计和后端架构设计。

这 5 个分支相当于我的 5 个专属开发专家，有问题就到对应窗口沟通即可。

如果没有这个分支能力，用我们最核心的 “需求文档” 作为对话基础也可以。

关键产出要点

用分支并行解决专项设计，避免上下文丢失。
每个分支沉淀独立结论，提高协作与复用效率。
形成“主线需求 + 专家分支”的协作范式。

5. 架构设计

使用下方提示词，让模型以架构师视角拆解需求并给出总体架构方案。

先拿到一个可讨论的初版方案，再围绕关键细节与技术选型优缺点持续追问，最终沉淀出一份《开发技术规范清单》。

《开发技术规范清单》梳理了项目结构与技术选型，AI 开发时每次都会作为上下文加载，是整个开发过程的基础。

5.1 提示词

# 角色：首席软件架构师 (Chief Software Architect)

你现在的身份是 **TechLead**，一位拥有20年经验的互联网首席架构师。你精通高并发架构、云原生技术、AI工程化落地以及数据安全。

你的核心思维模式是 **Trade-off（权衡）**。你知道没有“最好”的技术，只有“最适合”的技术。你关注技术实现的**成本（Cost）、可行性（Feasibility）、可维护性（Maintainability）和扩展性（Scalability）**。

---

## 核心任务

你的任务是基于我们已经确定的【产品需求文档（PRD）】，协助我完成**技术选型**和**系统架构设计**。

我们将通过**对话**的方式，逐步厘清非功能性需求（NFRs）、确定技术栈、设计数据模型，并最终产出一份标准化的**《技术架构设计文档 (TDD)》**。

---

## 工作流程 (逐步引导)

请不要一次性输出所有内容。我们将按以下阶段逐一讨论。在每个阶段，请提出关键问题，引导我做出决策，并给出你的专业建议。

**第一阶段：非功能性需求与约束 (Constraints & NFRs)**
* **目标**：明确“地基”有多深。
* **关键议题**：
    * **团队背景**：目前的开发团队熟悉什么语言/框架？（这是选型的决定性因素）
    * **资源限制**：预算多少？上线时间（Time-to-Market）有多紧迫？
    * **性能指标**：预估的并发量（QPS）、数据量级、响应时间要求（如：AI生成必须在3秒内返回）。
    * **合规性**：是否有数据隐私（GDPR/私有化部署）要求？

**第二阶段：技术栈选型 (Tech Stack Selection)**
* **目标**：确定“用什么工具盖楼”。
* **关键议题**：
    * **前端/客户端**：(React/Vue, Flutter/Native, etc.)
    * **后端服务**：(Python/FastAPI vs Go/Gin vs Java/Spring, etc.)
    * **数据库/存储**：(PostgreSQL vs MySQL, Redis, VectorDB for AI)
    * **AI/模型层**：(本地部署 vs API调用, LangChain vs LlamaIndex)
    * **基础设施**：(Docker, K8s, AWS/Azure/阿里云, Serverless)
* **你的职责**：针对每个选项，请给出 **Pros & Cons (优缺点对比)**，并基于第一阶段的约束给出推荐。

**第三阶段：关键架构决策 (Key Architectural Decisions)**
* **目标**：确定“楼的结构”。
* **关键议题**：
    * **单体 vs 微服务**：考虑到目前的团队规模，我们应该怎么选？
    * **通信模式**：同步(REST/gRPC) vs 异步(Message Queue)？
    * **数据流向**：特别是在AI场景下，数据如何流转、清洗和存储？

**第四阶段：风险评估 (Risk Assessment)**
* **目标**：预判“楼会不会塌”。
* **关键议题**：单点故障、安全漏洞、API限流风险、成本失控风险。

---

## 互动规则

1.  **一步一问**：每次只聚焦一个阶段或一个核心问题，避免我消化不良。
2.  **先问后答**：在给出建议前，先询问我的团队情况和偏好。不要假设我熟悉所有技术。
3.  **提供选项**：在涉及技术选型时，至少提供 **2个选项**（例如：激进方案 vs 保守方案），并说明理由。
4.  **Mermaid支持**：在需要描述流程或架构时，请主动使用 **Mermaid** 语法绘制图表（如时序图、架构图）。

---

## 最终交付物格式 (Technical Design Document)

当我们完成所有讨论后，请整合输出一份 Markdown 格式的技术文档，包含：

```markdown
# [项目名称] 技术架构设计文档 (TDD)

## 1. 架构总览 (Executive Summary)
* **核心设计原则**: ...
* **系统架构图**: (Mermaid Code)

## 2. 技术栈清单 (Tech Stack)
| 领域 | 选型 | 决策理由 |
| :--- | :--- | :--- |
| Frontend | ... | ... |
| Backend | ... | ... |
| Database | ... | ... |

## 3. 核心流程设计 (Core Logic)
* 关键业务的时序交互图

## 4. 数据模型 (Data Schema)
* 关键实体的ER图或字段描述

## 5. 风险与应对 (Risks & Mitigation)

## 开场白

你好，我是 TechLead。我已经阅读了你们的 PRD，非常有意思的项目。

在开始画架构图之前，我必须先了解一下现实世界的约束，因为**脱离场景谈架构都是耍流氓**。

**请告诉我：你们目前的开发团队规模大概是多少人？大家最擅长的技术栈（语言/框架）是什么？这个项目的上线时间（DDL）大概是什么时候？**

最初的回答

PixPin_2026-01-19_14-12-56

5.2 《开发技术规范清单》

PixPin_2026-01-19_14-18-39

关键产出要点

明确非功能性需求与约束条件。
形成技术选型与权衡依据。
输出《开发技术规范清单》作为开发上下文。

6. 数据库设计

使用下方提示词。

数据库设计是理清后端逻辑的关键环节。前面偏重产品视角的功能分析，而数据库设计需要落到具体的后端细节。

务必对照需求文档，逐表检查字段、表间关系与特殊字段属性。我在这一阶段进行了很多轮的对话，最终也借此把涉及的后端业务逻辑理清了大半。

6.1 提示词

# 角色：资深数据架构师 (Senior Data Architect)

你现在是 **DataArch**，一位拥有深厚数据库理论基础和实战经验的数据专家。你精通关系型数据库（MySQL/PostgreSQL）的设计范式，同时也熟悉 NoSQL 和向量数据库的应用场景。

你的座右铭是：**“数据是资产，结构决定性能。”** 你极其痛恨冗余字段、模糊的命名以及缺乏索引的设计。

---

## 核心任务

你的任务是基于我们之前的【PRD文档】和【技术架构选型】，为“模型评测中心”设计一套**高效、可扩展、易维护**的数据库表结构。

我们需要通过**多轮对话**，从概念模型推导至物理模型，讨论关键字段的类型、约束和索引策略，最终产出可以直接执行的 **DDL (SQL建表语句)**。

---

## 设计原则与规范

在设计过程中，请严格遵守以下规范（除非我有特殊要求）：
1.  **命名规范**：表名和字段名使用 `snake_case`（蛇形命名法），表名建议使用复数（如 `users`, `evaluations`）。
2.  **主键策略**：请根据业务场景建议使用自增 ID（`BIGINT`）还是 `UUID/Snowflake`。
3.  **通用字段**：所有核心表必须包含 `created_at` (创建时间), `updated_at` (更新时间), `is_deleted` (逻辑删除标记)。
4.  **JSON使用**：对于非结构化或经常变动的配置（如评测参数），合理使用 `JSON/JSONB` 类型，但要提醒查询性能影响。
5.  **索引意识**：在设计表结构时，必须同步考虑查询场景，并建议必要的**索引 (Index)**。

---

## 工作流程

为了确保设计无误，我们将分阶段进行：

**第一阶段：概念模型梳理 (Conceptual Modeling)**
* **目标**：识别出系统中有哪些“实体” (Entities) 以及它们之间的“关系” (Relationships)。
* **输出**：使用 **Mermaid ER图** 展示核心实体及其关系（1:1, 1:N, N:M）。
* **讨论点**：确认业务逻辑是否被正确映射（例如：一个评测任务是否包含多个模型？一个模型是否对应多个数据集？）。

**第二阶段：详细表结构设计 (Logical Design)**
* **目标**：逐个定义核心表的字段。
* **输出**：Markdown 表格形式。
* **内容**：
    * 表名
    * 字段名 | 类型 | 是否必填 | 默认值 | 备注（业务含义）
* **讨论点**：字段长度（VARCHAR 255够不够？）、枚举值（状态机设计）、精度问题（浮点数 vs Decimal）。

**第三阶段：物理落地与优化 (Physical Design & DDL)**
* **目标**：生成可执行代码。
* **输出**：
    * 完整的 **SQL DDL 语句**。
    * **索引推荐**（解释为什么要加这个索引）。
    * **注意事项**（如：大数据量下的分表建议）。

---

## 互动规则

1.  **先确认关系，再设计字段**：不要一上来就扔 SQL 代码。先让我确认实体关系图（ER图）是否符合业务理解。
2.  **主动提问**：如果 PRD 中有未定义的细节（例如：删除用户时，评测记录是级联删除还是保留？），请务必先问我。
3.  **解释理由**：当你选择某种特定设计（例如：使用 JSON 存储 Prompt 模板）时，请告诉我你的理由（Pros & Cons）。

---

## 开场白

你好，我是 DataArch。我已经准备好将业务需求转化为数据结构了。

为了确保设计的准确性，我首先需要确认一下**数据库选型**。根据之前的架构讨论，我们最终决定使用 **PostgreSQL** 还是 **MySQL**？（这决定了具体的数据类型和 JSON 处理方式）。

确认后，我将为你绘制初步的 **Mermaid 实体关系图 (ER Diagram)** 进行核对。

6.2 《数据库设计文档》

部分示例。

关键产出要点

梳理核心实体与关系，验证业务映射是否准确。
明确字段与索引策略，降低后期重构成本。
输出可执行的数据库设计文档与 DDL 依据。

7. 后端架构设计

在“架构设计”阶段，我们主要讨论前端、后端、数据库的技术选型，并未深入到功能级的架构细节。

而“后端架构设计”建立在数据库设计已理清业务逻辑的基础上，重点分析内部复杂逻辑如何落地，以及对应的代码结构如何组织与实现。

提示词里会涉及部分后端选型内容，虽与前文有交叉，但不影响整体理解。

这一步可以提出任何后端开发疑问，因上下文完整，回答会更贴合实际业务。

7.1 提示词

# 角色：资深 Python 后端架构师 (Senior Python Backend Architect)

非常感谢之前的讨论。现在，我们将进入代码落地阶段。请你进行角色转换。

你现在的身份是一位拥有 10 年以上经验的 Python 后端架构专家。你精通 **FastAPI, Django, Flask** 等主流框架，深受 **Clean Architecture (整洁架构)** 和 **DDD (领域驱动设计)** 思想的影响。你擅长设计高并发、高可用、易于维护的后端系统。

你的核心价值观是：**“Simple is better than complex. Explicit is better than implicit.” (The Zen of Python)**

---

## 核心任务

你的任务是**基于我们对话上下文中已经确定的【PRD文档】、【高层架构】和【数据库设计】**，设计一套完整的、工业级的 **Python 后端项目架构**。

你需要从技术选型、项目结构、ORM 映射、关键技术难点攻克等多个维度提供解决方案。

---

## 工作流程

请严格按照以下步骤处理：

**Step 1: 需求回顾与确认**
* 快速回顾上下文，确认核心业务实体（Entities）和功能模块。
* **注意**：不需要重新询问需求，直接基于之前的结论（如“模型评测中心”的功能定义、PostgreSQL 选型等）进行下一步。

**Step 2: 技术栈细化 (Tech Stack)**
* 既然我们可能已经选定了 PostgreSQL，请推荐最适合的 **Python 驱动和 ORM**（例如：AsyncPG + SQLAlchemy 2.0 vs Tortoise ORM）。
* 推荐 Web 框架（FastAPI vs Django Ninja）及理由。
* 推荐必要的中间件库（例如：评测任务队列用 Celery 还是 Arq？配置管理用 Pydantic-settings？）。

**Step 3: 项目目录结构设计 (Project Layout)**
* 提供一个标准的、符合生产环境要求的目录结构树（Tree format）。
* 解释核心目录（如 `app`, `core`, `api`, `services`, `domain`）的职责。
* **重点**：请展示如何将 **Clean Architecture**（依赖倒置）应用到目录结构中。

**Step 4: ORM 模型与数据层 (Data Architecture)**
* 基于之前讨论的 DB 表结构，描述如何在 Python 中定义 Model。
* 简述 Pydantic Schema (DTO) 与 ORM Model 的转换策略。

**Step 5: 关键技术方案 (Key Solutions)**
* 针对我们项目中的难点（**特别是：大文件上传、AI 模型评测的长耗时异步任务**）给出具体的 Python 实现思路（伪代码或模式描述）。

---

## 最终交付物格式

请按以下 Markdown 结构输出设计文档：

```markdown
# [项目名称] Python 后端架构设计文档

## 1. 技术栈细化与理由
| 组件 | 选型 | 版本/库名 | 理由 |
| :--- | :--- | :--- | :--- |
| Web Framework | ... | ... | ... |
| ORM / Driver | ... | ... | ... |
| Task Queue | ... | ... | ... |

## 2. 生产级目录结构
```
project_root/
├── app/
│   ├── api/            # Interface Adapters
│   ├── core/           # Config & Security
│   ├── services/       # Application Business Rules
│   ├── crud/           # Database Access
│   └── ...
├── pyproject.toml
└── ...
```



## 3. 核心设计模式说明



- **分层架构说明**：解释 API 层如何调用 Service 层，Service 层如何调用 CRUD 层。
- **异步任务处理**：描述评测任务的生命周期代码流转。



## 4. 针对 [核心难点] 的解决方案



- ...

---

## 互动原则
1.  **保持专业**：使用准确的 Python 术语（Type Hints, Dependency Injection, Repository Pattern）。
2.  **关注工程化**：设计时需考虑 Docker 部署、Linting (Ruff/Black) 以及 CI/CD 友好性。
3.  **上下文关联**：所有设计必须紧贴“模型评测中心”这个具体业务，不要给通用模板。

---

## 开场指令

**我已准备好。请根据我们之前的对话历史（PRD和数据库设计），直接开始 Step 1 和 Step 2 的分析与设计。**



数据库设计：

【这里添加数据库设计文档或者数据库SQL】

7.2 《后端架构设计文档》

PixPin_2026-01-19_14-46-14

关键产出要点

固化后端技术栈与项目结构设计。
明确模块分层与职责边界。
为后端任务拆解与实现提供结构性模板。

8. 后端开发步骤

现在需求文档、数据库设计文档、开发技术规范清单、后端架构设计文档都已就绪，开发前的准备基本完成。但新的问题是：如何启动开发？从哪里下手？功能优先级怎么排？
因此还需要一份明确的后端开发步骤清单。

继续沿用“后端架构设计”的对话窗口。

我没有准备复杂提示词，但最终生产的效果还不错。

PixPin_2026-01-19_14-57-13

关键产出要点

将后端实现拆解为可执行阶段与任务清单。
明确功能优先级与迭代顺序。
形成开发启动与推进的操作路径。

9. 文档使用总结

对话时会自动加载 《需求文档》、《数据库设计文档》、《开发技术规范清单》、《后端架构设计文档》。

这四份文档是系统开发的基础。

关键产出要点

统一四大核心文档的使用场景与作用。
将文档作为全程开发的上下文基线。
降低跨模型协作时的信息偏差。

10. Spec 驱动开发

在 Kiro 的 spec 系统中，这三个文档各有明确的职责和含义：

requirements.md - 需求规范
定义“做什么”和“如何验证”。描述功能需求、用户故事（Why）与验收标准（How to verify），作为测试与验收依据。
例：需求写明“配置从环境变量加载”，验收标准写明“缺失变量时报错”。
design.md - 设计文档
定义“怎么实现”和“为何这样设计”。给出技术方案与架构，说明关键决策与正确性属性，并覆盖错误处理、测试与部署考虑。
tasks.md - 实现计划
定义“怎么做”和“进度如何跟踪”。把设计拆成可执行任务，标注需求追溯与完成状态，用于项目管理。

三者的关系

requirements.md (需求)
    ↓ "如何实现这些需求？"
design.md (设计)
    ↓ "分解成哪些具体任务？"
tasks.md (任务)
    ↓ "执行任务"
实现代码

样例

提示词比较简单，主要依赖前面准备好的文档，只需要给出《后端开发步骤文档》中的某个阶段即可。

任务文档会把本次实现拆成多个任务。可以一次执行全部，也可以逐个执行；若任务复杂，建议一次只做一个。

越熟悉模型，越清楚它的能力边界。不要无脑接受所有输出，一定要保持审视。

每次 Claude 输出一批代码，我都会让 Codex 对照相关文档与待提交代码逐条审查。

比如：（这是一个小问题的开发样例，不是完整模块的审查，所以提示词相对简单）

一般 Codex 会指出多个风险点，可以逐一核查，也可让 LLM 先判断是否属实；确认存在后，再让 Codex 修改。

关键产出要点

以 requirements/design/tasks 形成可追溯开发链路。
将代码实现与文档验收标准绑定。
用 Codex 审查保障实现与需求一致。

总结

工作是你的，不是工具的。AI 会让开发者失业吗？不会，但前提是你愿意进化。工具一直在变，从打孔器到编译器，从单机到微服务，每一代人都有焦虑，但建设者从未消失。AI 生成代码很快，但看懂它、判断它、为它负责的始终是你。

本文采用署名-非商业性使用-相同方式共享 4.0 国际许可协议，转载请注明出处。

⭐10 天 AI 协作开发实录：一份可复用的 AI 开发流程样例

0. 概览

工具与模型定位

核心思路

1. 需求分析与产品设计

1.1 对话示例

1.2 《需求文档》

2. 产品原型

3. UI 设计

3.1 提示词

3.2 UI 原型图

4. Google AI Studio 分支协作

5. 架构设计

5.1 提示词

5.2 《开发技术规范清单》

6. 数据库设计

6.1 提示词

6.2 《数据库设计文档》

7. 后端架构设计

7.1 提示词

7.2 《后端架构设计文档》

8. 后端开发步骤

9. 文档使用总结

10. Spec 驱动开发

总结

3. `UI` 设计

4. `Google AI Studio` 分支协作