阅读完本节后，你将会收获：
- 理解 PRD 与技术文档的明确分工
- 掌握技术文档的五大组成部分
- 学会将技术决策记录为文档
- 理解文档在 AI 开发中的价值
在 PRD 迭代到 5 稿、产品方案基本确定后，除了梳理业务逻辑，还需要记录具体的技术实现方案，也就是技术文档。
两者分工明确：PRD 回答"做什么"，技术文档回答"怎么做"。
| 内容 | 说明 |
|---|---|
| 目标用户 | 谁会使用这个产品 |
| 核心功能 | 产品需要实现哪些功能 |
| 用户交互 | 用户如何完成操作 |
| 边缘场景 | 异常情况如何处理 |
| 业务流程 | 完整的用户操作流程 |
| 内容 | 说明 |
|---|---|
| 数据模型 | 有哪些表、字段、关系 |
| API 设计 | 接口列表和职责分工 |
| 架构/流程图 | 系统组件关系和业务流程 |
| 第三方集成 | 外部服务和接入方式 |
| 技术决策 | 选型理由和关键权衡 |
graph LR
A[PRD<br/>做什么] --> B[技术文档<br/>怎么做]
B --> C[代码实现<br/>实际做]
style A fill:#e1f5fe
style B fill:#fff3e0
style C fill:#e8f5e9PRD 中的每个业务实体，都应该在数据模型中找到对应；PRD 中的每个功能点，都应该在 API 设计中找到对应接口。这种对应关系是检验技术文档完整性的标准。
在 AI 辅助开发的时代，技术文档的价值被放大了。过去，文档主要是给人看的——帮助团队成员理解系统，或是给自己留备忘。现在，它还多了一个重要读者：AI。
AI 需要上下文才能准确工作。当你告诉它"帮我写一个用户登录功能"时，如果没有文档说明用户表有哪些字段、登录接口的返回格式，AI 只能凭空猜测。猜测意味着试错，试错意味着时间浪费。
一份清晰的技术文档，相当于给 AI 提供了一份"系统说明书"。它知道数据结构，就能生成符合你架构的代码；它知道 API 规范，就能写出前后端能对接的接口。文档越清晰，AI 的猜测越少，开发效率越高。
技术文档提供了结构化的上下文，让 AI 知道"用什么技术"、"数据结构是什么"、"接口怎么定义"。没有文档，AI 只能从代码中反推，效率更低，错误更多。
对于个人或小团队，不必拘泥于形式，可以将 PRD 和技术文档合并为项目文档。但需要清楚区分哪些是产品层面的思考，哪些是技术层面的决策。
无论项目大小，以下五大组成部分不可省略：
| 组成部分 | 为什么不可省略 |
|---|---|
| 数据模型 | AI 需要知道存什么数据 |
| API 设计 | 前后端需要知道怎么通信 |
| 架构/流程图 | AI 需要理解系统结构和业务逻辑 |
| 第三方集成 | AI 需要知道外部依赖和配置 |
| 技术决策 | AI 需要理解选型理由，避免偏离方向 |
可以简化的：
简单的组织方式：
# 项目文档
## 1. 产品部分
### 1.1 需求背景
### 1.2 核心功能
### 1.3 用户故事
## 2. 技术部分
### 2.1 技术栈
### 2.2 数据模型
### 2.3 API 设计
### 2.4 架构图
### 2.5 第三方集成
### 2.6 部署方案理解了技术文档的作用和组成，接下来了解编程的基本构件。