prd-checklist

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

PRD Checklist - 需求文档防遗漏开发流程

PRD Checklist - Development Process for Preventing Requirement Document Omissions

为什么需要这个流程

Why This Process Is Needed

长需求文档（几百到几千行）包含大量功能细节：页面布局、交互行为、计算公式、数据字段、颜色规则、权限控制等。如果读完文档后直接开始写代码，注意力会从"需求细节"转移到"代码逻辑"，导致大量功能点被遗漏。文档越长，遗漏越严重。

这个流程的核心思路是：不依赖记忆力，而是创建一份结构化的外部检查清单，写代码时逐条对照打勾。

Long requirement documents (hundreds to thousands of lines) contain a large number of functional details: page layout, interaction behaviors, calculation formulas, data fields, color rules, permission control, etc. If you start writing code immediately after reading the document, your attention will shift from "requirement details" to "code logic", resulting in a large number of functional points being omitted. The longer the document, the more serious the omissions.

The core idea of this process is: Do not rely on memory, but create a structured external checklist, and check items one by one against it while writing code.

流程总览

Process Overview

读取完整文档 → 生成 Checklist 文件 → 用户确认无遗漏 → 逐模块实现 → 每完成一项勾选 → 模块完成后扫描未勾选项

严格按以下三个阶段执行，禁止跳过第一阶段直接写代码。

Read complete document → Generate Checklist file → User confirms no omissions → Implement module by module → Check off each item upon completion → Scan unchecked items after module completion

Strictly follow the following three phases, skipping the first phase to directly write code is prohibited.

第一阶段：读取文档 + 生成 Checklist

Phase 1: Read Document + Generate Checklist

1. 完整读取需求文档

1. Read the Requirement Document in Full

必须读完文档的每一行，不能只读前几百行就开始总结
如果文档超过 2000 行，分段读取，确保全部覆盖
读取过程中，在脑中构建文档的模块结构树

Must read every line of the document, cannot start summarizing after only reading the first few hundred lines
If the document exceeds 2000 lines, read in sections to ensure full coverage
During reading, build a module structure tree of the document in your mind

2. 生成 Checklist 文件

2. Generate Checklist File

在需求文档同目录下创建

<原文件名>-checklist.md

。

Checklist 的编写规则（这些规则直接决定了最终代码的完整性）：

粒度要求 — 一个 checkbox 对应一个可独立验证的实现点：

每个 UI 元素单独一条（一张卡片、一个按钮、一个图表）
每个交互行为单独一条（悬停提示、点击跳转、展开/折叠）
每个数据字段单独一条（表格的每一列、卡片的每个指标）
每个计算公式/业务规则单独一条
每个颜色/样式规则单独一条
每个权限控制点单独一条
每个非功能需求（性能、安全、兼容性）单独一条

结构要求：

严格按照原文档的章节层级组织（如 3.1 → 3.1.1 → 3.1.2）
每个章节标题与原文档保持一致，方便回溯
在每个子章节下，按 UI 区域分组（如"页面顶部"、"指标卡片区"、"图表区"）

内容要求：

每条 checkbox 必须包含足够的实现细节，不能只写模糊描述
- 差："显示指标卡片"
- 好："全校平均分卡片：全校学生总分加权平均值，数据来源 exam_scores，显示环比变化箭头(上/下)和变化数值"
如果原文档有计算公式，完整写入 checkbox（不要省略为"见文档"）
如果原文档有 ASCII 原型图，提取其中的每个 UI 元素为独立 checkbox

末尾统计：

在文件末尾添加一个统计表，列出每个模块的功能点数和总计

Create

<original-filename>-checklist.md

in the same directory as the requirement document.

Checklist writing rules (these rules directly determine the completeness of the final code):

Granularity Requirement — One checkbox corresponds to one independently verifiable implementation point:

Each UI element as a separate item (a card, a button, a chart)
Each interaction behavior as a separate item (hover prompt, click jump, expand/collapse)
Each data field as a separate item (each column of a table, each indicator of a card)
Each calculation formula/business rule as a separate item
Each color/style rule as a separate item
Each permission control point as a separate item
Each non-functional requirement (performance, security, compatibility) as a separate item

Structure Requirement:

Strictly organize according to the chapter hierarchy of the original document (e.g., 3.1 → 3.1.1 → 3.1.2)
Each chapter title is consistent with the original document for easy backtracking
Under each sub-chapter, group by UI area (e.g., "Page Top", "Indicator Card Area", "Chart Area")

Content Requirement:

Each checkbox must contain sufficient implementation details, cannot only use vague descriptions
- Poor: "Display indicator card"
- Good: "School average score card: Weighted average of total scores of all students, data source: exam_scores, display month-on-month change arrow (up/down) and change value"
If the original document contains calculation formulas, write them completely into the checkbox (do not omit as "see document")
If the original document has ASCII prototypes, extract each UI element as an independent checkbox

End Statistics:

Add a statistics table at the end of the file, listing the number of functional points for each module and the total

Checklist 模板

Checklist Template

markdown

undefined

markdown

undefined

[系统名称] 功能检查清单

[System Name] Functional Checklist

来源：[原文件名] ([行数]行) 生成目的：开发时逐条对照，防止功能遗漏使用方式：每实现一个功能点标记 [x]，最后核查无遗漏

Source: [Original Filename] ([Number of Lines] lines) Purpose: Check item by item during development to prevent function omissions Usage: Mark [x] for each implemented functional point, and verify no omissions at the end

[模块编号] [模块名称]

[Module Number] [Module Name]

[子模块编号] [子模块名称]

[Sub-module Number] [Sub-module Name]

[UI 区域名称]：

[具体功能点描述，含实现细节]
[具体功能点描述，含实现细节]

[另一个 UI 区域]：

[UI Area Name]:

[Specific functional point description with implementation details]
[Specific functional point description with implementation details]

[Another UI Area]:

统计

Statistics

模块	功能点数
[模块1]	[数量]
[模块2]	[数量]
总计	[总数]

undefined

Module	Number of Functional Points
[Module 1]	[Quantity]
[Module 2]	[Quantity]
Total	[Total Number]

undefined

3. 请用户确认

3. Ask User for Confirmation

生成 Checklist 后，告诉用户：

总共提取了多少个功能点
请用户对照原文档检查是否有遗漏
用户确认后才进入实现阶段

After generating the Checklist, inform the user:

Total number of functional points extracted
Please ask the user to check against the original document for any omissions
Only proceed to the implementation phase after user confirmation

第二阶段：逐模块实现

Phase 2: Implement Module by Module

1. 按模块顺序实现

1. Implement in Module Order

每次只实现一个模块（如 3.1 学校数据驾驶舱）
开始实现前，重新读取该模块对应的 Checklist 章节
也重新读取原始 PRD 文档中该模块的原文（Checklist 是摘要，原文有更多上下文）

Only implement one module at a time (e.g., 3.1 School Data Cockpit)
Before starting implementation, re-read the corresponding Checklist chapter for the module
Also re-read the original text of the module in the original PRD document (Checklist is a summary, the original text has more context)

2. 逐条勾选

2. Check Off Items One by One

每实现一个功能点，立即在 Checklist 文件中将
```
[ ]
```
改为
```
[x]
```
不要等到整个模块写完再批量勾选——边写边勾，这样能实时发现遗漏

Immediately change
```
[ ]
```
to
```
[x]
```
in the Checklist file after implementing a functional point
Do not wait until the entire module is written to check off in batches—check off while writing, so omissions can be detected in real time

3. 模块完成后扫描

3. Scan After Module Completion

一个模块的代码写完后：

重新读取该模块的 Checklist
逐条检查是否都已勾选
如果有未勾选的项，补充实现
全部勾选后才进入下一个模块

After writing the code for a module:

Re-read the Checklist for the module
Check item by item to ensure all are checked off
If there are unchecked items, supplement the implementation
Only proceed to the next module after all items are checked off

第三阶段：完成后全局核查

Phase 3: Global Verification After Completion

所有模块实现完毕后：

读取完整的 Checklist 文件
搜索所有未勾选的
```
[ ]
```
项
如果存在未勾选项，告知用户并询问是否需要补充实现
输出最终统计：总功能点数 / 已实现数 / 未实现数

After all modules are implemented:

Read the complete Checklist file
Search for all unchecked
```
[ ]
```
items
If there are unchecked items, inform the user and ask if supplementary implementation is needed
Output final statistics: Total functional points / Implemented count / Unimplemented count

特殊情况处理

Handling Special Cases

文档包含非前端需求（如后端、运维、安全）时：

仍然提取到 Checklist 中，但标注为
```
[非前端]
```
实现时跳过这些项，但在最终报告中列出

文档有"可选功能"标记时：

在 Checklist 中标注
```
[可选]
```
实现时询问用户是否需要实现

用户说"先只做某个模块"时：

仍然生成完整的 Checklist（因为模块间可能有依赖）
但只实现用户指定的模块

When the document contains non-frontend requirements (e.g., backend, operation and maintenance, security):

Still extract them into the Checklist, but mark as
```
[Non-frontend]
```
Skip these items during implementation, but list them in the final report

When the document has "optional function" marks:

Mark as
```
[Optional]
```
in the Checklist
Ask the user whether to implement them during implementation

When the user says "only implement a certain module first":

Still generate a complete Checklist (because there may be dependencies between modules)
But only implement the module specified by the user