PRD 需求与 API 接口设计 Prompt

PRD 需求与 API 接口设计 Prompt

在独立开发中，许多新人喜欢直接让 AI “写一个小程序”，然后一步一步打补丁，最终导致项目逻辑混乱失控。高效的开发流是：开发前，让 DeepSeek 产出详细的需求文档 (PRD) 和 API JSON 接口定义。

这有两大核心价值：

1. 明确边界：通过 PRD 定义好 MVP 的全部页面和字段，防止开发过程中肆意加需求。
2. 给 AI 当蓝图：将 DeepSeek 设计好的 API JSON 接口和页面大纲，直接作为上下文发给 Trae，Trae 就能极其顺畅地一键把数据库、后端接口和前端页面结构完整拼出来，几乎不需要反复修改。

📝 选择题

💡 独立开发实战：高效的 AI 协作设计流 你想做一个“记账小程序”的账单列表页。为了让 Trae 一口气写出正确的前后端数据渲染逻辑，你会首先给它提供什么 Prompt/文档？

• A. “帮我写个账单列表页，后端随意，数据越真实越好。”
• B. 提供由 DeepSeek 设计好的账单 API 接口规范（包含 GET /api/bills 路由的 JSON 响应格式，包含 id, amount, category, date 字段定义），并让 Trae 按此格式渲染前端列表。
• C. “我也不太清楚具体需要什么字段，你随便帮我编造一个吧，最好看起来丰富一些。”

答案：B（提供由 DeepSeek 设计好的账单 API 接口规范（包含 GET /api/bills 路由的 JSON 响应格式，包含 id, amount, category, date 字段定义），并让 Trae 按此格式渲染前端列表。） 方案 B 能够通过明确的前后端 API 数据规范建立“数据契约”，使 Trae 前端渲染代码与后端服务 100% 契合，防止出现字段命名不一致（如前端用 amount，后端返 price）的问题。

以下是一个标准的 API 接口规范 Prompt 约束片段：

## API Specifications
Method: GET
Path: /api/v1/todos
Response Format:
{
  "code": 200,
  "data": [
    { "id": 1, "content": "Task 1", "done": false }
  ]
}

在开发前先让 DeepSeek 输出这段契约，并在后续开发中要求 AI 严格按此契约生成前后端，这就是 AI 时代的“契约式开发”。

✏️ 填空题

💡 独立开发实战：HTTP 动作语义约束 在给 DeepSeek 下达 API 路由设计指令时，为了符合 RESTful 标准规范：获取数据列表应用 GET 方法，而用户提交新表单记录则应声明为什么方法？

API Definition:
___ /api/v1/todos
Body: { "content": "New task" }

答案：POST POST 用于向服务器提交新资源。明确声明 POST 方法能指导 Trae 在前端编写正确的 wx.request({ method: ‘POST’ })。