1. 项目概述：当PRD遇上AI，我的效率革命

如果你和我一样，是个经常在飞书里写产品需求文档，然后转头就要去IDE里吭哧吭哧敲代码的开发者，那你一定懂那种“文档世界”和“代码世界”之间的割裂感。PRD写得再详细，逻辑再清晰，一旦开始编码，总感觉中间缺了点什么。是缺了设计稿吗？不完全是。是缺了技术方案吗？也不全是。我缺的是一个能把我从“自然语言描述”直接带到“可运行代码”的平滑过渡带。这就是我折腾出这套“从飞书PRD到代码实现”AI编程工作流的初衷。

简单说，这不是一个全自动的“PRD一键生成完整应用”的魔法（那还不现实），而是一个高度结构化的、人机协作的增效流程。它的核心是利用AI（比如基于Codex或类似技术的智能编程助手）作为“超级翻译官”和“初级执行者”，将飞书文档中结构化的需求描述，快速转化为可用的代码骨架、函数模块甚至基础测试用例。我管它叫“AI编程workflow”，因为它确实是一套连贯的动作组合拳，从需求解读、任务拆解、代码生成到初步验证，形成了一个闭环。这套方法让我在开发一些常规功能、工具脚本或者模块时，效率提升了不止一倍，更重要的是，它把我从大量重复、模板化的编码劳动中解放出来，能更专注于架构设计和核心逻辑。

2. 工作流核心设计：拆解“翻译”的艺术

为什么是飞书PRD？因为飞书文档（尤其是多维表格）在结构化信息呈现上有天然优势。一份好的PRD，其需求描述本身就应该具备一定的“可解析性”。我的工作流，本质上是在强化和利用这种“可解析性”。

2.1 输入侧：精心烹制“AI友好型”PRD

不是所有PRD都适合直接喂给AI。为了让AI更好地理解，我对PRD的撰写方式做了一些“微调”，这并不改变PRD的本质，只是让它更机器可读。

1. 结构化与原子化需求描述 我尽量避免大段的、散文式的需求描述。取而代之的是使用清晰的列表、表格和分级标题。

  • 用户故事格式 ：对于功能点，我会采用“作为[角色]，我希望[达成目标]，以便[实现价值]”的格式。这种格式本身就被很多AI训练过，易于识别角色、动作和目的。
  • 验收标准清单化 ：每个用户故事或功能点下，必须跟一个“验收标准”列表，用“Given-When-Then”或简单的条目式列出。这是AI生成测试代码的绝佳原料。

    例如，一个“用户登录”功能的验收标准可能写成：

    • 给定用户访问登录页面，当输入正确的用户名和密码并点击登录按钮，那么应跳转到首页。
    • 给定用户访问登录页面，当输入错误的密码，那么页面应提示“密码错误”。
    • 给定用户已登录，当访问登录页面，那么应自动跳转到首页。

2. 关键信息表格化 对于包含多个属性、状态或配置的实体，我会用飞书表格来明确。比如一个“订单”对象，我会列一个表格，包含字段名、类型、是否必填、描述、示例。

| 字段名 | 类型 | 必填 | 描述 | 示例 |
| :--- | :--- | :--- | :--- | :--- |
| order_id | string | 是 | 订单唯一标识 | “ORD20231027001” |
| status | enum | 是 | 订单状态：pending, paid, shipped, completed | “pending” |
| total_amount | float | 是 | 订单总金额，单位元 | 299.99 |

这种结构，AI几乎可以无脑地将其转换为一个类定义（Class）或者TypeScript接口（Interface）。

3. API设计先行 在PRD中，我会提前用类似OpenAPI的简约格式描述关键接口。不需要完整的YAML，但要有路径、方法、请求/响应体结构。

**接口：创建订单**
- **端点**：`POST /api/v1/orders`
- **请求体**：
  ```json
  {
    "product_id": "string",
    "quantity": "integer"
  }
  • 成功响应 (200)： 
    {
  "code": 0,
  "data": {
    "order_id": "string",
    "status": "pending"
  }
}

有了这个，让AI生成对应的控制器（Controller）路由、数据验证和序列化代码就非常直接。

**实操心得：** 撰写“AI友好型”PRD的额外好处是，它倒逼产品经理和开发者自己把需求想得更清楚、更结构化。模糊的需求在这种格式下会无处遁形，这本身就是一个巨大的质量提升。

### 2.2 处理引擎：选择合适的“翻译官”

目前，AI编程助手的选择很多，我的工作流主要围绕两类工具构建：

**1. 云端智能编程助手（如Cursor、GitHub Copilot）**
这类工具深度集成在IDE中，能根据上下文和注释实时建议代码。在我的工作流中，它们扮演“即时翻译”的角色。
*   **使用场景**：当我阅读PRD的某个具体段落时，我可以直接将其作为注释写在代码文件里，然后触发AI补全。例如，在Python文件中写下注释 `# 功能：验证用户密码，规则为长度8-20位，需包含大小写字母和数字`，然后回车，Copilot或Cursor很可能就生成一个 `validate_password` 函数。
*   **优势**：无缝、快捷，对代码上下文理解强。
*   **局限**：生成范围通常限于一个文件或一段代码，难以一次性根据长篇PRD生成多个关联文件。

**2. 大模型对话接口（结合Codex/GPT系列API）**
这是我工作流的核心“批处理”引擎。通过编程方式调用OpenAI API或类似服务，我可以将PRD的特定章节发送给模型，并给出精确的指令。
*   **使用场景**：当需要根据一个结构清晰的表格生成整个数据模型类，或者根据API描述生成一组完整的端点处理函数时。
*   **基本模式**：我通常会构造一个包含系统指令和用户消息的Prompt。系统指令定义AI的角色（如“你是一个经验丰富的Python后端工程师”），用户消息则包含PRD片段和具体任务（如“根据下面的表格，生成一个SQLAlchemy的Order模型类”）。
*   **关键技巧**：Prompt工程至关重要。直接扔过去大段文本效果不好。我需要先做“信息提取和整理”，把PRD中最精华、最结构化的部分提炼出来，再交给AI。

**工具选型背后的逻辑**：我选择Cursor+API调用的组合。Cursor用于日常开发中的碎片化代码生成和对话式调试，而针对PRD中那些明确的、模块化的部分，我会写一个小脚本调用API进行“批量翻译”。这样兼顾了灵活性和效率。

### 2.3 输出与整合：从代码块到可运行项目

AI生成的代码不是最终产品，它需要一个“着陆区”和“质检员”。

**1. 生成物的定位**
我始终将AI生成的代码视为 **“高级草稿”或“脚手架”** 。它的价值在于：
*   **快速搭建框架**：生成项目基础结构、模型类、API路由骨架。
*   **实现样板代码**：生成数据验证、序列化、简单的CRUD操作。
*   **编写基础测试**：根据验收标准生成单元测试的骨架和用例。

**2. 人工整合与精修**
这是不可或缺的一步。我的整合流程是：
*   **创建临时分支**：所有AI生成的代码先进入一个特性分支，如 `feat/ai-gen-order-module`。
*   **逐文件审查**：像做Code Review一样审查AI生成的代码。重点看：逻辑是否正确、是否符合项目规范（命名、风格）、是否有安全隐患（如SQL注入风险）、依赖是否合理。
*   **运行和调试**：将生成的代码放入项目环境，运行测试（如果是生成的测试）或尝试启动服务。AI生成的代码常常在导入路径、细微语法或业务逻辑边界条件上出错，需要手动修复。
*   **迭代优化**：如果生成的代码不理想，我不会直接重写，而是尝试**优化我的Prompt**，或者将PRD描述得更精确，然后让AI重新生成。这个过程本身也是打磨需求的过程。

**注意事项**：**绝对不要**将未经审查的AI生成代码直接合并到主分支。AI可能会产生看似正确实则荒谬的逻辑，或者引入不安全的代码模式。人工审查不仅是质量控制，更是加深对代码理解的过程。

## 3. 实操全流程：一个订单模块的诞生记

让我用一个具体的例子，展示这套工作流如何从一份飞书PRD开始，最终产出可运行的代码。假设我们要开发一个电商系统的“订单管理”模块。

### 3.1 阶段一：PRD分析与信息提取

我收到一份飞书PRD，里面用我推崇的格式描述了“订单”实体和“创建订单”、“查询订单列表”两个API。

我的第一步不是打开IDE，而是打开一个笔记工具或直接在一个Python脚本里，开始“信息萃取”。我会手动（或写简单脚本）从PRD中提取出关键信息，并格式化，为构造Prompt做准备。

例如，我可能会整理出如下纯文本：

【实体定义：订单】 字段：

  • order_id: string, 主键，格式‘ORD’+年月日+序列号
  • user_id: string, 用户ID
  • status: enum, 值包括：‘pending’（待支付）, ‘paid’（已支付）, ‘shipped’（已发货）, ‘completed’（已完成）, ‘cancelled’（已取消）
  • total_amount: float, 总金额
  • items: 数组，包含商品ID和数量
  • created_at: datetime, 创建时间
  • updated_at: datetime, 更新时间

【API 1: 创建订单】 端点：POST /api/v1/orders 请求体：{“items”: [{“product_id”: “str”, “quantity”: int}]} 响应体：{“code”: 0, “data”: {“order_id”: “str”, “status”: “pending”}} 逻辑：验证商品存在且库存充足，计算总价，生成订单号，状态初始化为pending。

【API 2: 查询订单列表】 端点：GET /api/v1/orders 查询参数：page (int), size (int), status (optional enum) 响应体：{“code”: 0, “data”: {“total”: int, “orders”: [订单对象列表]}} 逻辑：支持分页和按状态过滤。


### 3.2 阶段二：构造Prompt与调用AI

接下来，我会根据不同的目标，构造不同的Prompt，并调用AI API（这里以OpenAI格式为例）。

**任务1：生成SQLAlchemy数据模型和Pydantic模式**

我构造的Prompt可能长这样：

```python
system_prompt = “””
你是一个专业的Python后端工程师，精通FastAPI、SQLAlchemy和Pydantic。请根据用户提供的需求，生成符合Python最佳实践和PEP 8规范的代码。代码应包含必要的导入、类型注解和清晰的注释。
“””

user_prompt = “””
请为以下“订单”实体定义生成代码：
1. 一个SQLAlchemy的ORM模型类，名为`Order`。表名定为`orders`。字段信息如下：
   - order_id: 字符串，主键。业务格式要求是‘ORD’+年月日+序列号，但在数据库中是唯一字符串即可。
   - user_id: 字符串，非空。
   - status: 字符串，非空。只允许‘pending’, ‘paid’, ‘shipped’, ‘completed’, ‘cancelled’这几个值。
   - total_amount: 浮点数，非空。
   - items: JSON字段，用于存储商品列表，例如 [{"product_id": "prod_123", "quantity": 2}]。
   - created_at: 日期时间，默认为当前时间。
   - updated_at: 日期时间，默认为当前时间，并在更新时自动刷新。
2. 一个Pydantic的`OrderCreate`模式，用于创建订单的请求验证。
3. 一个Pydantic的`OrderResponse`模式，用于订单查询的响应序列化。

请将三个类的代码放在一个代码块中返回。
“””

然后，我通过脚本发送这个请求，获取AI返回的代码。生成的代码通常已经具备了很好的基础结构，可能只需要微调（比如调整JSON字段的具体类型，或添加一些自定义验证器）。

任务2：生成FastAPI路由和CRUD函数

基于上一个任务生成的模型，以及API描述，我可以发起第二个请求：

user_prompt_2 = “””
基于上面生成的SQLAlchemy `Order` 模型和Pydantic模式，请实现以下两个FastAPI端点：

1. `POST /orders/` 创建订单
   - 路径操作函数名为 `create_order`
   - 接收 `OrderCreate` 作为请求体
   - 核心逻辑：生成一个唯一的order_id（简单起见，可以用uuid），状态设为‘pending’，计算总价（这里假设有一个`calculate_total`函数，你只需调用它），将订单存入数据库。
   - 返回 `OrderResponse` 格式的数据。

2. `GET /orders/` 查询订单列表
   - 路径操作函数名为 `get_orders`
   - 支持查询参数：`skip` (int, 默认0), `limit` (int, 默认10), `status` (可选，字符串)
   - 核心逻辑：根据`status`参数过滤（如果提供），实现分页查询（使用`skip`和`limit`）。
   - 返回一个包含`total`（总数）和`items`（订单列表）的字典。`items`中的每个订单都是`OrderResponse`格式。

请将这两个端点实现在一个名为`order_router`的APIRouter中。包含必要的导入、数据库会话依赖注入（假设使用`Depends(get_db)`）。对于缺失的业务函数（如`calculate_total`），请用注释标出。
“””

实操心得： 在调用API时， 温度（temperature） 这个参数很重要。对于生成严谨的代码，我通常设置为0.1或0.2，以降低随机性，让输出更确定、更符合预期。对于需要一点创意或多种解决方案的场景，可以调高。

3.3 阶段三：代码落地与工程化整合

AI返回的代码我会保存到临时文件。然后开始手动整合：

  1. 创建文件 ：在项目的 models/ 目录下创建 order.py ，粘贴AI生成的模型类。
  2. 创建路由 ：在 api/ 目录下创建 endpoints/order.py ，粘贴AI生成的路由代码。
  3. 修复导入和依赖 ：检查并修正文件间的导入路径。补充AI用注释标出的缺失函数（如 calculate_total ），这些通常是需要连接其他服务或复杂计算的部分，AI无法凭空生成。
  4. 添加数据库迁移 ：如果AI生成的模型是新的，我需要手动创建Alembic迁移脚本（或使用命令生成），这步AI暂时还无法完美替代。
  5. 编写补充测试 ：虽然AI可能根据验收标准生成了一些测试骨架，但通常不够完整。我会基于PRD的验收标准，完善单元测试和集成测试。

整个过程中，我的IDE里开着Cursor。当我在整合代码，看到某个复杂逻辑时，我会把问题抛给Cursor的Chat功能。比如：“Cursor，我这里需要实现一个根据items数组计算总价的函数，需要查询商品表获取单价，请用Python写一个，假设有一个 get_product_price_by_id 的异步函数可用。” 这样，Cursor充当了我的即时编码助手。

4. 避坑指南与效能边界

这套工作流不是银弹，在近半年的实践中，我踩了不少坑，也摸清了它的能力边界。

4.1 常见问题与解决方案

问题现象 可能原因 解决方案
AI生成的代码无法运行，有语法错误或导入错误。 1. Prompt描述不够精确。2. AI的“知识截止日期”导致使用了过时或项目不用的库语法。 1. 将错误信息反馈给AI，让它修正。例如：“上面的代码有ImportError，请改用from sqlalchemy.orm import Mapped, mapped_column。” 2. 在Prompt中明确指定技术栈和版本，如“使用SQLAlchemy 2.0风格”。
生成的代码逻辑看似正确，但存在业务逻辑漏洞。 AI不理解深层次的业务规则和边界条件。 人工审查是关键 。必须对核心业务逻辑进行严格的人工测试和推敲。AI生成的代码是“第一稿”，你是“主编”。
对于复杂的、需要多个文件协作的功能，AI生成的内容支离破碎。 单次Prompt的上下文长度有限，且AI不擅长管理多文件项目结构。 分而治之 。不要试图让AI一次性生成整个模块。按“数据模型 -> API接口 -> 业务服务层 -> 工具函数”的顺序，逐个击破。用清晰的Prompt描述模块间的依赖。
生成的代码风格与项目现有规范不符。 AI没有你项目的代码风格上下文。 1. 在系统Prompt中定义代码风格（如“使用Black格式化，类型注解齐全”）。2. 将项目中的几个典型文件作为“示例”附在Prompt中（如果上下文允许）。3. 事后使用项目的lint工具（如ruff, isort）统一格式化。
API调用成本与响应速度问题。 使用GPT-4等大型模型生成长代码成本较高，且可能有速率限制。 1. 对于模板化强的代码（如CRUD），可以尝试更经济的模型（如Claude Haiku, GPT-3.5-Turbo）。2. 将多次零碎请求合并为一次结构化的请求，提高效率。3. 本地部署代码生成模型（如CodeLlama）是控制成本和延迟的终极方案，但对硬件有要求。

4.2 工作流的效能边界

经过实践，我总结了这套工作流在哪些方面是“超人”，在哪些方面仍需“人力主导”。

AI擅长的（效率提升明显）：

  • 数据模型生成 ：根据清晰的表格生成ORM类、Pydantic模式、TypeScript接口，准确率极高。
  • API骨架生成 ：根据路径、方法、请求/响应体描述生成路由函数骨架，包括参数解析和基本验证。
  • 样板代码填充 ：如简单的CRUD操作、DTO转换、基础的错误处理。
  • 单元测试骨架 ：根据Given-When-Then格式的验收标准生成测试用例和方法。
  • 工具函数/脚本 ：实现一个描述清晰的、独立的功能函数，如数据清洗、格式转换、简单的算法。

仍需人力主导的（AI作为辅助）：

  • 复杂业务逻辑 ：涉及多状态流转、分布式事务、复杂规则引擎的核心逻辑。AI可以提供思路或代码片段，但整体架构和细节必须由人把控。
  • 系统架构设计 ：如何划分微服务、数据库选型与分库分表策略、缓存设计、消息队列应用等。
  • 性能优化与安全 ：SQL查询优化、并发控制、防重放攻击、注入防护等。AI可能给出通用建议，但具体实施需结合场景深度优化。
  • 与现有系统集成 ：如何适配已有的用户认证体系、日志规范、监控报警平台。这需要人对现有系统非常了解。
  • 代码重构与调试 ：理解一段复杂遗留代码并重构，或者诊断一个生产环境下的诡异Bug。

个人体会是，这套工作流最大的价值，不是替代我思考，而是把我从“体力活”中解放出来。 我不再需要手动敲出十几个几乎一样的模型字段，不再需要反复查阅文档来写一个标准的分页查询参数解析。我把这些节省下来的时间，用于更深入地思考产品逻辑、设计更优雅的架构、编写更全面的测试用例。它让我从一个“代码打字员”，更像一个“解决方案设计师”和“质量守门员”。

最后，一个小技巧：建立一个你自己的“Prompt库”。把那些针对常见任务（生成FastAPI CRUD、生成React组件、生成单元测试）且效果很好的Prompt保存下来。下次遇到类似任务，稍作修改就能使用，这会让你和AI的协作越来越顺畅。这个工作流本身，也是一个需要不断迭代和优化的“产品”。

Logo
亚马逊云科技技术品牌专区

更多推荐

cover

别再只聊大模型！AI的下一场革命，藏在“身体”里

avatar 亚马逊云科技技术品牌专区
cover

别再只聊大模型！人工智能的下一场革命，藏在“身体”里

avatar 亚马逊云科技技术品牌专区
cover

别再只聊大模型！AI的下一场革命，藏在“身体”里

avatar 亚马逊云科技技术品牌专区